.NET Programming Languages

Our readership survey is in!

The vast majority of SearchWinDevelopment.com readers are using modern tools, but a significant number of them are also interested in maintaining legacy applications, according to a readership survey conducted by the site.

A preliminary look at the survey reveals that 87% are using Visual Studio 2008 or 2005. About 65% of respondents use one of those versions as their primary IDE.

.NET languages are very popular; legacy code also important

Three quarters of all respondents reported using one of the two main .NET languages, C# and VB.NET; for half of respondents, one of those languages is what they do most of their coding in. C# is the more popular language by a significant (but not overwhelming) margin of 48% to 38%. Legacy code is still important, though. One fifth of readers use C++ and almost a third use VB6 or earlier, although only 15% of all respondents use those older languages as their main programming language.

Interestingly, the “use at all” to “use as primary” stats aren’t symmetric within .NET. As I noted above, 48% of readers use C# and 38% use VB.NET. But while 36% of readers use C# as their primary coding language, only 17% use VB.NET as their primary. That means that 75% of respondents who use C# do so for most of their programming (36 / 48 = .75), but only 45% of VB.NET coders use that language as their primary.

Web development is huge, but not quite cutting edge

Unsurprisingly, Web development is very popular. Just over half of all SearchWinDevelopment.com readers work with ASP.NET. For most of those, Web development is their main responsibility. But despite the Web 2.0 craze, Silverlight isn’t nearly as popular.

Ajax development is strong, but relatively diverse. That is probably due in part to Microsoft changing strategies: although it has its own Ajax framework, the company recently decided to officially back the popular library jQuery and incorporate it into IntelliSense. About 30% of ASP.NET developers use ASP.NET AJAX, 23% use jQuery and 15% use another framework.

What you’re doing, and how you’re doing it

In case you’re wondering how other Windows developers get things done, the top four most popular programming methodologies are waterfall, extreme programming (XP), Agile and Scrum. But about a quarter of you aren’t employing any methodology at all! That could be because almost a third of respondents work in an environment with fewer than five programmers, but it’s still a bit surprising.

And as for what you’re doing, the majority of our survey respondents said that improving performance one of their architectural challenges. That’s to be expected, but what stands out is that that’s the only architectural challenge that a majority of our readers are facing. Almost 60% of our readers listed performance as a challenge their company is facing; the next popular choice, implementing a workflow, weighed in at about 42%.

Those are topics we haven’t covered extremely closely, so that feedback is great to have.

Lastly, it’s clear that many of you are interested in learning new tools and technologies. We asked readers to rank their interest in nine topics, including software-as-a-service and open source software, which Microsoft is warming up to. Most of the topics trended toward “highly interested,” with only scripting languages and grid computing technology trending toward disinterest. That might not bode well for Microsoft’s latest push to promote PHP on Azure.

Look for a more in-depth analysis of the survey in the coming weeks. In the meanwhile, to all of our readers who took the survey, our deep thanks!

Open source cataloger adds CodePlex to its knowledgebase

A company that helps developers find, track and manage open source components has partnered with Microsoft to include projects from CodePlex, Microsoft’s open source portal.

Black Duck Software helps companies find reliable open source projects and comply with their various licenses. Although the source code for open source software (OSS) is free, various licenses have different restrictions, ranging from simple attribution to obliging developers to publish any improvements they make back to the OSS community.

It’s not easy to manage those licenses, and companies will sometimes try to find an alternative OSS project if the one they currently draw from has a relatively restrictive license, said Peter Vescuso, executive vice president of marketing and business development at Black Duck. Black Duck can also help companies gauge OSS projects’ quality by providing information about their developer community and version history, he said.

By bringing CodePlex projects into its KnowledgeBase, which catalogs open source projects, Black Duck is underscoring Microsoft’s relatively new push to embrace open source. Microsoft has made several overtures toward open source: it recently released ASP.NET MVC as open source; several of its Silverlight components are open source; it’s making sure its Azure cloud OS will work with PHP; and its CodePlex site provides a repository for open source projects. Most projects on CodePlex are Windows applications written in .NET, although that isn’t a requirement for putting a project on the site.

The partnership with Microsoft will give Black Duck access to projects’ metadata, letting it automate its information gathering process, Vescuso said. For Microsoft, the deal will help it get out the message that it’s a true, committed player in the open source world, he said.

Open source is often associated with Linux, but most developers in the last decade — including Windows developers — look to open source to help them as they write applications, Vescuso said. Those uses range from just copying a few lines to using whole components or tools.

Clarifications on Microsoft’s Oslo, M

When I complained last month that we haven’t seen enough of Microsoft’s Oslo to know what it is, Microsoft responded.

To recap: my gripe with Oslo — and specifically its programming language M, which is the most concrete part of Oslo we’ve seen so far — wasn’t that it isn’t useful. M lets developers build out domain-specific languages (DSLs) relatively easily, and that’s obviously handy. But a new language to define DSLs does not a SOA platform make, I argued.

Microsoft’s answer: Oslo isn’t about SOA; it’s about modeling (hence the “M”). SOA is one of the domains that Microsoft anticipates could be helped by Oslo, but the terms are not synonymous, said Burley Kawasaki, director of developer platform product management at Microsoft.

The problem with data modeling as it exists today is that everyone has their own way of doing it, which means nobody can talk to anybody else, Kawasaki said. Even within a given company, different groups may model data differently, which makes the handoff a pain point. Microsoft’s vision is to unify data modeling in the same way that XML unified markup.

For instance, frameworks like WPF and Spring are increasingly using metadata to build portions of applications, Kawasaki said. That means developers have “a whole bunch of mini Oslos,” each modeling and executing its own metadata; it’d be like each application writing its own XML-like specification and the tools to use parse and write it.

The biggest thing XML has going for it is that it’s a standard. If you’ve got an XML document, it’s trivial for me to read it, manipulate the data, and spit it back to you in a way you understand. That’s what Microsoft wants Oslo to do for modeling, and it wants M to be the workhorse behind the scenes.

Microsoft’s vision is to be able to actually compile and run the model, just as WPF compiles XAML and turns it into a program’s UI. That ensures that the model changes as the project goes forwards, instead of just being printed out and forgotten among a stack of papers. That’s what M and its compiler do.

But that gets us back to the original issue: we haven’t seen that kind of pervasiveness from Oslo yet. Microsoft has shown us how to use M to develop DSLs, but that’s a far cry from using it to build standardized, useful, easily transferable models.

That goal depends on three building blocks, said Kris Horrocks, senior product manager for Microsoft’s developer platform team:

• a common way to represent models
• a common way to store them; and
• a common way to display and manipulate them

M addresses the first of those steps, and the Oslo repository — currently SQL Server — addresses the second. The third will presumably be the role of Quadrant, the GUI model editing tool that Microsoft has announced but not yet demoed.

But beyond the technical building blocks, Horrocks said, is industry adoption. After all, you can’t address a lack of standardization just by throwing another contender in the ring. To that end, Microsoft has included M in its open specification promise, and it’s encouraging developers to get a head start by downloading M, playing around with it and possibly even contributing to the project.

Oslo may not be vaporware, but is it significant?

This is the week of Oslo over at SearchWinDevelopment.com. On Monday, Microsoft released a new CTP of its Oslo data modeling project just as we were rolling out a tip on how Oslo fits in with .NET. Oslo development seems to be coming along, with demos and CTPs aplenty — but I still can’t help feeling there’s a lot of commotion about something that feels very much like a sideshow.

I had the chance to sit in on an Oslo session at a DevCon recently, and I must say, I was not incredibly impressed. At the core, it looks like the M programming language lets developers define their own, simple input grammar and compile it into a series of SQL calls. The end result is that you can take an arbitrarily-defined input file, feed it through your M program, and end up with a filled database.

So far, sounds like something a simple script could do, right?  And as far as I’ve seen, that’s all that Oslo really has to offer in terms of concrete functionality.

And while M is just one component of Oslo, it’s probably the most significant one, if the demos we’ve seen are any indication. Quadrant, Oslo’s GUI modeling tool, isn’t in CTP yet, and we’ve heard precious little about how the whole package will eventually form the foundation of SOA applications.

Granted, there’s some benefit to being able to define input grammars at a high level. But tools like lex/yacc have given programmers this ability for decades. M is less generalized and simpler than lex/yacc, but if Oslo is — as it appears to be so far — essentially a set of user-friendly tools that combine high-level grammar definitions with SQL output functionality and a nice GUI front end, is that enough to justify the hype? From what we’ve seen so far, Oslo could well be useful in its own right. But I don’t consider that groundbreaking enough to call it a brand new modeling platform, let alone the backbone to a 10-year SOA strategy.

Microsoft is very careful to point out that Oslo is in pre-alpha; they’re just giving us a glimpse whlie they work out the tools.  But with the various books, conference sessions and interviews they’ve been giving, we should expect a bit more than something to replace simple parsing scripts.

MonoDevelop beta ups the ante for .NET development on Linux

It’s been a busy couple of weeks for Mono, the Novell-backed project that’s developing a port of .NET for Linux/Unix OSs. Last week saw the release of Moonlight 1.0, a Linux port of Silverlight 1.0 that has passed all of Microsoft’s regression tests. This week, the group released the first beta of MonoDevelop 2.0, its C# IDE for Linux.

For all its recent talk about interoperability, Microsoft has focused fairly exclusively on Windows as it’s built out its development platforms. Visual Studio is a Windows-only product, despite rumors to the contrary, as is Silverlight. (We should note that Microsoft has helped the Mono group, both with the development of Moonlight and with Mono, the open source implementation of the .NET runtime.)

Of course, interoperability isn’t easy or clean. As I noted on the blog for our sister site SearchSOA, even the communications protocols can raise challenges as you start talking between Linux and Windows computers.

But a truly interoperable world, where Linux and Windows servers work side by side harmoniously and cohesively, won’t be possible until programmers can unify their development efforts across platforms. That’s where MonoDevelop fits in.

The new beta introduces some much-needed basics, like a built-in debugger, but it’s also improving its ASP.NET support. The IDE is also more compatible with Visual Studio; for instance, it now uses msbuild-style project files.

Projects like MonoDevelop will be crucial if companies want to really mix and match Linux with Windows, but that’s a big “if.” For now, as far as I know, the vast majority of .NET development isn’t on Linux, and the vast majority of Linux development doesn’t use .NET. As laudable as Mono’s goals are in trying to tear down that wall, I have to wonder how much demand there is for that level of interop in the mainstream.

VC++ gets update, VB6 gets heave

Microsoft development honcho Soma Somasegar reports that a Visual C++ 2008 Feature pack has shipped. In January the pack came out in beta.

MFC components included in the pack allow developers to create applications with the look and feel of Microsoft Office, Visual Studio and Internet Explorer. The VC++ 2008 pack can be downloaded from Microsoft’s Download Center.

That’s the good news. The bad news is VB6 has reached end-of-life status in terms of Microsoft formal support. The company has recently created a webcast explaining what that means, and what avenues are open for application migration.

VB6 Programmers - What happened to Printer.Print?

This post goes out to all you VB geeks that are wondering what happened to Printer.Print in VB.  This may be a dated topic but I have a feeling there are a few out there longing for those VB6 days when the printer was always sitting there loyal and waiting.  The VB6 programmer’s best friend.  Well, when you needed to print something anyway.   Once upon a time you could just write a few lines of code and *poof* you created a page of information for your users.  Now you have this PrintDocument thing and PrintDialogs and PrintPreviewDialogs and Graphics objects and the list just goes on and on.

Let me re-introduce you to printing in .NET.  Once you get through the slight grade of the learning curve, you’ll be convinced that .Net printing is better than anything you did with the printer object in VB6.

The task - print a smiley face on a piece of paper.  Lines of code in VB6 - about 6.  Lines of code the .net way - about 22 (but you could consolidate…).

That doesn’t sound like a good trade off.  It seems its easier in VB6.  However - what if you wanted to create a bitmap of the smiley face and then use that bitmap in various places as well as print it here and there?  How many line of code do you need now?

 In VB6 - I have no idea.  You would need to drop down to the API level and call graphics functions against a Device Independent Bitmap device context making sure you clean up after yourself in those places where cleanup is necessary.  Then you would need to save that bitmap to a file and/or have an image control somewhere that you could set using the memory bitmap (again using API calls).  Then perhaps you could print the smiley here and there using some similar printing code.

In .NET - its the same 22 lines of code and you can run those lines of code against any “Device Context” (using API terminology) by simply passing a Graphics object to the code that actually creates the smiley.  You could even create a bitmap object and simply use that bitmap throughout your program without ever getting close to the windows API.
Here are my CreateSmiley functions:

private void DrawSmiley(Graphics g, int Width)
{
  Pen p=new Pen(Color.Black);
  SolidBrush b = new SolidBrush(Color.Black);
  SolidBrush YellowBrush = new SolidBrush(Color.Yellow);
  Point Origin = new Point(0, 0);
  Size HeadSize=new Size(Width,Width);
  Rectangle Container=new Rectangle(Origin, HeadSize);
  Point LeftEye=Origin;
  Point RightEye=Origin;
  Point SmileTopLeft = Origin;
  LeftEye.Offset((int)(HeadSize.Width*.25), (int)(HeadSize.Width*.20));
  RightEye.Offset((int)(HeadSize.Width*.65), (int)(HeadSize.Width*.20));
  SmileTopLeft.Offset((int)(HeadSize.Width *.20), (int)(HeadSize.Width * .40));
  Size SmileSize = new Size((int)(HeadSize.Width*.60), (int)(HeadSize.Width*.40));
  Size EyeSize=new Size((int)(HeadSize.Width * .10),(int)(HeadSize.Width * .10));
  g.FillEllipse(YellowBrush, Container);
  g.DrawEllipse(p, Container);
  g.FillEllipse(b, new Rectangle(LeftEye, EyeSize));
  g.FillEllipse(b, new Rectangle(RightEye, EyeSize));
  g.DrawArc(p, new Rectangle(SmileTopLeft, SmileSize), 180, -180);
  b.Dispose();
  YellowBrush.Dispose();
  p.Dispose();
}

private Bitmap CreateSmiley(int Width)
{
  Bitmap Smiley = new Bitmap(Width, Width);
  Graphics g=Graphics.FromImage(Smiley);
  DrawSmiley(g, Smiley.Width);
  g.Dispose();
  return Smiley;
}

Pretty basic stuff and different than you did in VB6. You have access to all the API stuff without dropping down the the API level. Now as far as printing goes - there are a few objects that need your attention. The PrintDocument, PrintDialog, and PrintPreviewDialog objects. The PrintDocument object is the container for all your drawing methods. It handles paging and rendering of the stuff you are printing. The PrintDialog and PrintPreviewDialog objects manage the actual device you are printing to. The PrintDialog as you may have guessed will print to a printer while the PrintPreviewDialog prints to a preview window.

Here is some code that uses a PrintPreviewDialog and calls the printing methods above:

private void button1_Click(object sender, EventArgs e)
{
  PrintDocument pdoc = new PrintDocument();
  // hook up the event handler for the printpage event
  pdoc.PrintPage += new PrintPageEventHandler(pdoc_PrintPage);
  PrintPreviewDialog pdialog = new PrintPreviewDialog();
  pdialog.Document = pdoc;
  pdialog.ClientSize = new Size(640, 480);
  pdialog.Show();
}
void pdoc_PrintPage(object sender, PrintPageEventArgs e)
{
  Bitmap smiley=CreateSmiley(300);
  e.Graphics.DrawImage(smiley, new Point(150, 150));
  e.HasMorePages = false;
}


The VB.Net code is virtually the same. Just change the declaration variables around, change the curly braces to Sub/End Sub, remove the semi-colons and your 80% done.
This method of printing is easy to hook up and offers a great deal of flexibility but if you want real reporting power - there is no substitute for a good reporting engine such as SQL Server Reporting Services or Business Objects’ Crystal Reports. There are others.  I’m a convert.  I was a Crystal Reports bigot but if you’re using a SQL Server database - you get reporting services for free and I must admit after running SQL RS through its paces - I like it better than Crystal Reports.  That, of course, is my opinion.

Hello F# world!

Are you ready for the Functional? Matthew Podwysocki has blogged about F#, a functional programming language. He provides, in fact, a nifty introduction. His initial ‘F# 101′ post warns: You must first understand the differences between imperative and functional programming, in order to work with F#.

F# arose from MS Research. It runs on Microsoft’s Common Language Runtime and the .NET Framework. Check out the SearchWinDevelopment.com F# Programming Fast Guide for more background on the language.

Also noteworthy on Podwysocki’s site is a post informing that the second Alt.NET conference opened for registration. The event is set for April in Seattle. Oops, the set is open to a limited number of registrants - a subsequent Podwysocki post informs that registration has closed. Must be a lot of fans of Alt in Seattle.

The elusive project properties

So I put together my setup project using the in-grown version of MSI (don’t get me started on how cumbersome it is to add files!) and then built it. Looked good.

But when I tested it, the suggested path was “C:\Program Files\Default Company Name”. Whaaa? Where was it getting that from? And how could I get it to show the correct name? I figured I needed to modify some properties somewhere.

I right-clicked on the project in Solution Explorer, and then chose Properties. That brought up the configuration properties, not the project properties. Next I clicked on Project | Properties. That brought up the configuration properties again. So did View | Property Pages.

Then light dawned on Marblehead, as they say in New England. In Solution Explorer, I clicked on the name of the project. Then I clicked View on the menu bar and found the entry for Properties Window and clicked that. There it was—the manufacturer was set to Default Company Name. (Maybe I should buy that domain name….) At least it was an easy fix, once I found the right place.

I also noticed that I could choose an icon for my app’s entry in the Add/Remove Programs applet, as well as pre- and post-build events. I got all excited for a minute, thinking these were pre- and post-install events, but no such luck. Now wouldn’t that be nice!

The Deployment Project Properties window (as it is officially called) is very much like the properties windows for controls such as listboxes and buttons. Controls are objects, and so are projects, so I suppose it makes sense that you’d get to their properties the same way.

But they could have told me.

TFS to the rescue — almost

(Editor’s note: This is the first blog post by Christopher Yager, who will be writing on the .NET Developments blog from time to time. Yager is chief software architect at GLD Solutions Inc. and is currently using .NET 2.0 for his new development projects. Here he will blog about topics such as Windows Communication Foundation, Team Foundation Server and SQL Server. Welcome aboard, Chris!)

Before I get into this — welcome to my blog.  I’ll be posting mainly about my adventures in .NET programming — feedback is welcome.  I’m no guru but I did stay at a Holiday Inn Express last night.  (Actually as I write I’m still at said Holiday Inn… )

So TFS (Team Foundation Server), Microsoft’s answer to the software lifecycle management problem, really is a great product.  My team uses most features on a daily basis.  My headline is somewhat misleading but allow me some latitude while I state my case.  I run a software development company.  We produce software products and we have customers that use them.  (Go figure.)  We have a QA staff.  We test our products.  TFS has no way to capture the guts of a user defined test against a product that tests a particular requirement.  Specifically we needed to save metrics of test runs with success and failure rates, reasons for failure, environments tested, and lot of other neat stuff.  I didn’t expect TFS to have all this rich user testing goo so I expected we’d roll our own.  This article is about how we connected our hand-rolled testing metrics program with our Team Foundation Server.

The problem:  A scenario test fails; a bug is created against a product/task/whatever and needs to be linked to the test that caused the problem.

The Solution:  The TFS API!

Team Foundation Server has a plethora of components that you can leverage allowing seamless integration with the back end of your TFS implementation.  These components are found in the following path normally: 

[Program Files Root]\Microsoft Visual Studio 8\Common7\IDE\PrivateAssemblies

**Client requirement: On any system you install your custom TFS linked software, Team Explorer must be installed.  An obvious server requirement is that you have a Team Foundation Server installed somewhere in your network or available via the Web.  If you’re interested in getting TFS running (and why wouldn’t you be?!) you can download a trial from Microsoft.

Our general requirement for this task was to view a list of active bugs for a team project and allow selection of one. 

OK — some meat for you code monkeys. 

Create a windows forms project in your favorite language.  Mine is C# but any .NET language will do.

Add references to the following assemblies.  You’ll need to browse for them since they are not in the GAC or otherwise registered for easy VS reference adding.  The image shows them all together but this is a doctored image to save space.

Put a tab control on the form and set it to dock-fill (leave the 2 tab pages alone), size the form to 800X600 (this just saves us some time and coding).

We’re basically going to create two functions that perform the guts of the scenario.  The GetWorkItems function which utilizes the DomainProjectPicker dialog class to allow the user to select the team project they wish to examine and the PickWorkItemsControl user control which allows searching of the TFS work item store. 

                   

private void GetWorkItems()
{
    DomainProjectPicker dpp = new DomainProjectPicker();
    DialogResult dr = dpp.ShowDialog(this);
    if (dr == DialogResult.OK)
    {
        tfs = dpp.SelectedServer;
        tfsProject = dpp.SelectedProjects[0];
        this.Text = "My Team Foundation Link - " + tfsProject.Name;
        Store = (WorkItemStore)tfs.GetService(typeof(WorkItemStore));
        TeamProject = Store.Projects tfsProject.Name];
        pw = new PickWorkItemsControl(Store);
        pw.Dock = DockStyle.Fill;
        pw.PortfolioDisplayName = TeamProject.Name;
        this.tabPage1.Controls.Add(pw);
        pw.PickWorkItemsListViewDoubleClicked +=
            new PickWorkItemsListViewDoubleClickedEventHandler(
            pw_PickWorkItemsListViewDoubleClicked);
    }
}

The InitWorkItemControl function allows the user to view the details of a selected work item and utilizes the WorkItemFormControl control.

private void InitWorkItemControl()
{
    this.WorkItemControl = new WorkItemFormControl();
    this.WorkItemControl.Dock = System.Windows.Forms.DockStyle.Fill;
    this.WorkItemControl.FormDefinition = null;
    this.WorkItemControl.Item = null;
    this.WorkItemControl.LayoutTargetName = "WinForms";
    this.WorkItemControl.Name = "WorkItemControl";
    this.WorkItemControl.Size = new System.Drawing.Size(683, 428);
    this.WorkItemControl.TabIndex = 0;
    this.tabPage2.Controls.Add(this.WorkItemControl);
} 

We’ll tie this all together in the constructor for the form:

public Form1()
{
    InitializeComponent();
    InitWorkItemControl();
    GetWorkItems();
}

Here is what the finished product looks like: (This is an out-of-the-box dialog,  I didn’t write any of it.)

The search control on this form does not have any of my code in it.  I only provided the tab control for it to live in.

The dialogs and controls exposed by the TFS API take care of the majority of the user interface, we just need to hook the stuff together with a little glue.  You can download the sample solution which has both C# and VB .NET versions of the program. 

Special thanks to Brian Randell who taught me this stuff through an article on MSDN Magazine.

 Download the source code here