VS 2005 and .NET 2.0

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!

Anonymous Methods - Elegance or Kludge

According to Wikipedia, a kludge (or, alternatively, kluge) is a clumsy or inelegant solution to a problem or difficulty. In engineering, a kludge is a workaround, typically using unrelated parts cobbled together. Especially in computer programs, a kludge is often used to fix an unanticipated problem in an earlier kludge; this is essentially a kind of cruft.

When I first stumbled upon the concept of anonymous methods in C# 2.0 the first thing I thought of was …jeez it’s just another name for GOTO!  I’ve since changed my mind.  Have any of you ever used the Gosub…  Return programming construct from way back in the GW-Basic days?  I’m dating myself but in a former life I had the responsibility of maintaining a servo controller program that ran a servo motor (a DC motor that is capable of moving in programmed increments forward and backward) for a plant that made flour tortillas.  (yes - for Taco Bell no less!)  But I digress.  This particular brand of “Servo Basic” as it was called did not have the ability to address function calls.  It was all done with line numbers.  The program started at 10 and ended at the highest line number.  The only way to program a function in this version of basic was to use the Gosub… Return construct.  For instance “Gosub 100″ would jump to line 100 in the program and start executing code until a “Return” statement was hit then control would return to the line after the calling “Gosub” statement.  It was all very archaic but very versatile when it was all you had. 

Now I tell you that story so I can tell you this one:  I was happily coding one fine day when I encountered a problem that I needed to solve and it occurred to me that a Gosub… Return would be perfect here!  It was a function with lots of values passed in that needed to perform the same processing multiple times but I didn’t want to pass all that data around on the stack.  This, my friends, is the perfect case for an anonymous method.  You can define an anonymous method anywhere inside a function and when you call the method, it has the same scope as the code that defined the method.  The example here uses a SqlDataReader to populate an object.  The reader may or may not have some columns in it.  Since the only way to determine the columns in the reader is to use the GetSchemaTable() function and look at the results, I wrote an anonymous method to perform the search and was able to use the search to check for the existence of the questionable columns. 

Notice the placement of the definition within the function.  It is defined after the definition of the ReaderSchema DataTable.  The executing code in the function has scope at the point of definition and so it “knows” about the DataTable.  The syntax is a little funny but makes sense once you work through it.  The name of the anonymous method is “HasColumn” and can now be called from anywhere in the function after its definition.  It returns a boolean and accepts a string as designated by the delegate it is based upon.

Now I could have simply put the HasColum() in its own function and passed the table in to it along with the column name I’m searching for but then I wouldn’t have this totally cool use of an anonymous method, now would I?  However, the question remains:  elegance or kludge?

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.

Every time a bell rings…

If you have upgraded from Visual Studio 2003 to Visual Studio 2005, you have probably noticed one of the major annoyances: they took away the sounds.

With VS 2003, you could set things up so that your computer made a happy little sound at you when a build succeeds. This was great because I could turn away from the monitor for a moment, if only to rest my eyes, until the sound brought me back. Or I could check email, get another glass of cold caffeine, etc.

I’d even gone a step further by making my app play the sound of a bell ringing, when it had finished booting itself after a successful build in the dev environment. This extended the time I could gaze out my window at the tangle of weeds we call a lawn.

But in VS 2005, all you can do is hear a sound when you hit a breakpoint. Big deal. I want the cheerful news that everything is copasetic. So why did they take out the sounds? To save a few hundred milliseconds. That appears to be the official word.

And the official word, back in April 2006, was that they were working on fixing this “bug” for the next release. Well, the next release has come and gone. Still no sounds. In the meantime, they suggest, you can write an add-in.

In Service Pack 1, there is a new control called SoundPlayer, which appears to do the same thing a simple two-line function can do. Yes, without it you have to declare an API function, which means unmanaged code and wild-eyed people grabbing you by the collar to tell you what a mistake this is, but I’ve been using API calls very carefully since .NET appeared and have yet to suffer (I am knocking on my desk top with both fists). I guess it comes down to this: I’d rather have my sounds back than a relatively useless control.

I saved much more time when I had that happy sound than the hundreds of milliseconds they were worried about. At least my app still rings a bell when it’s up and running.

But they could have told me.

Getting Visual Studio 2005 add-ins to work with Visual Studio 2008

There are a lot of handy Visual Studio 2005 add-ins out there that, for a variety of perfectly legitimate reasons, have yet to be updated for Visual Studio 2008.

Before you go looking for replacement add-ins, though, you might want to check out a recent blog post by Mohamed Ahmed Meligy called Tip: Try this to make a VS 2005 add-in work with VS 2008. As the title implies, the author discovered a quick process for making sure that his Visual Studio 2005 add-ins would work on the newer version of the IDE.

The caveat here, of which Meligy is quite aware, is that this process may not work with all Visual Studio 2005 add-ins. Nonetheless, it certainly can’t hurt to try it out, especially if you have come to rely on a particular add-in so much that you think it’s part of the IDE itself.

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

They could have told me

(Editor’s note: This is the first blog post by Chris Madsen, who will be writing on the .NET Developments blog from time to time. Madsen is a consultant who programs in Visual Basic and Visual Studio 2005. Her first few posts will cover the ups and downs of migrating from VS 2003 to VS 2005; she’ll also write about some of the Visual Studio 2005 features that surprised her. Welcome aboard, Chris!)

The other day I got the latest edition of Visual Studio magazine in the mail. Along with it came a glossy, full-color pirate’s map. Evidently, that’s how Microsoft thinks of Visual Studio 2008 — “made for the likes of developers, and other scoundrels.”

I know the calendar says 2008, but in the real world of developers, it’s barely 2005. And I’m more a captain of a leaky little fishing boat than I am a pirate. It takes everything I have to get my work out the door on time. I upgrade my tools (such as Visual Studio) when I can’t live without a new feature, not when I get glossy maps in the mail.

I’m not alone: I still see plaintive questions begging for help with VB 6 apps, and with upgrading to VB .NET. I’ll leave it to others to reveal all the cool new stuff in VS 2008. I’m going to concentrate on Visual Studio 2005, including the woes of upgrading from VS 2003.

Whenever I run across a juicy bit, I’ll let you know. These are the things they never tell you, the information that’s written between the lines in the documentation, the stuff they leave out. It’s the stuff you find after opening a hundred Google links, buried in the answer to the answer to the answer to a question on some obscure site.

Who is this “they” who never tells me stuff? I’ll leave it up to you to decide.

I program mostly in Visual Basic .NET, so that’s what I’ll be talking about. I work almost exclusively with WinForms, and I’ve done a lot of work using Access, Word, and Excel in .NET apps. I love to write macros to make my life easier. I am a consultant with clients in Florida, Massachusetts and Maine. Just to keep things interesting, I live across country from all of them, in Washington State. So I might throw in some tidbits about telecommuting and consulting. Let me know if you are interested.

I’m sure I’ll write about some things you already know. Maybe they’ll make you smack your head and exclaim, “What sort of idiot is she?” But I figure if it wasn’t obvious to me, it wasn’t obvious to someone else, and that’s who the tidbit is for. I’m glad you have a better grasp of some things than I do.

But they could have told me.

What’s obsolete in .NET Framework 2.0

The jump from .NET 1.1 to .NET 2.0 was a pretty significant one, as it involved changes such as new APIs and a new version of the CLR.

Why bring this up now? One, we know there are a lot of .NET 1.1 applications out there, so any programmers looking to migrate those applications will want to know which APIs made it into .NET 2.0 and which did not. Two, .NET 3.0 and 3.5 use the same APIs and the same CLR — remember, those upgrades focus primarily on new libraries and new programming language features like LINQ.

To that end Indian blogger cabhilash recently pointed folks to two rather helpful MSDN documents covering that which is obsolete in the .NET Framework 2.0.

The documents are .NET Framework V2.0 Obsolete Type/Member List (By Assembly) and .NET Framework V2.0 Obsolete Type/Member List (By Namespace). For each member or type, Microsoft provides a sentence or two explaining why it should not be used. There tend to be two general reasons for obsolescence — depreciation in Visual Studio 2005 or, simply, a better way of doing things in VS 2005. Either way, the lists are worth a look-see.

.NET Framework 3.5 re-released to include .NET 2.0 SP1 and .NET 3.0 SP1

Forgive our gratuitous use of .NET in the headline there, but Microsoft has re-released its download of.NET 3.5 so that it now includes the Service Pack releases of .NET 2.0 and 3.0.

Here’s the latest .NET Framework 3.5 download, date-stamped yesterday,  and here’s the readme document for .NET 3.5.

These next two Knowledge Base documents outline what is in the older .NET Service Pack releases that have been bundled into the new .NET 3.5 release.

• Problems that are fixed in the .NET Framework 2.0 Service Pack 1
• Problems that are fixed in the .NET Framework 3.0 Service Pack 1

Finally, if you have separate implementations of .NET 2.0 or 3.0 running somewhere out there, the links to those Service Pack releases are below. All contain “prerequisite feature support” for .NET 3.5; in the case of the .NET 2.0 SP1, said support also covers .NET 3.0.

• Microsoft .NET Framework 2.0 Service Pack 1 (x64)
• Microsoft .NET Framework 2.0 Service Pack 1 (x86)
• Microsoft .NET Framework 3.0 Service Pack 1

Happy downloading.