The Moth

With VS2008 Beta 2, we all get a chance to play with a feature that the product teams have been teasing us with by talking about it before it was available in public drops.

[Request to product teams]If your feature is not baked in public bits, please refrain from blogging about it; also please stop posting images of private bits.[end request]

The feature in question is Partial Methods. Wes has an excellent write up here from a C# perspective (that he followed with this) and Scott here from a VB perspective. I suggest you read both since at the conceptual level they are the same. Essentially it is an aid to code generation scenarios in the same way that partial classes are. Think of it as a combination of a more efficient version of private event handlers and the Conditional attribute. Read the previous links for the full story.

My take? I simply thought I'd see the feature in action so without referring to the posts or documentation I fired up Visual Studio to try it out from memory. How mistaken I was. Every time I tried something I was greeted with a compiler error pointing out my ignorance. I was going to post here the series of compiler errors I dealt with one by one until I managed to get the thing to compile, but instead I've tried to summarise a few of them with one line of code:

public partial bool GoGoGo(out int i); //produces the following Error List


What better way to learn than by the compiler teaching you... a bit like how kids learn that fire is hot... by touching it (well, that's the way I learnt anyway). If however you prefer reading a very long thorough post covering a feature (in addition to the 3 posts above by the product teams) and also prefer looking at things through ildasm, then head over to Bart's blog post on the topic.

I've shown before one example of VS2008 integrating nicely with UAC, but today I found another one:

The above dialog appeared after I tried creating a new SharePoint Workflow project. After selecting the "Restart" option, Visual Studio closed, I confirmed the UAC Consent dialog and VS then reopened elevated (with the title bar showing its mode) in the same state it was before.

If you find any other examples of actions that result in an elevation prompt in Visual Studio 2008, please drop me a line (other people collect stamps, I collect UAC screenshots).

Regular readers of my blog will know that a requirement (and more importantly good common sense) for your applications that will run on Vista is that they have an embedded manifest declaring their requested privilege for working better with UAC. With Beta 1 of VS2008 I showed how this has become a doddle for C# projects. At the time, there was no such easy option for VB projects.

With Beta 2, VB also gets an easy way to do this. If you find the GUI of the C# approach confusing, then you'll be pleased to find that the VB approach is a single button named View UAC Settings, as per the following screenshot:

Clicking on it adds a pre-populated manifest file to your project which you can optionally further tweak to your liking, of course.

Note that in C#, you can manually add Application Manifest Files yourself:

...and switch between them from the IDE. This does not seem possible from the GUI provided by the VB team.

Further note that this feature is obviously applicable for v2.0, v3.0 and v3.5 client project templates in both languages. My advice to you is to open all your client projects in VS2008 and embed the default manifest now with no further thought. Later you can determine if you need to tweak things...

My Beta 2 installation experience was fine and dandy, but yours may not be. If you do face any issues, Aaron shows you how to collect the setup log files for diagnosing.

If you are facing the error above with Beta 2, it is due to the changes I blogged about. Doug has a nice step-by-step investigation and the solution.

A few months ago I posted about Office as a development platform with VS2008. While most of the features are easy for you to explore given the screenshots I posted, on my point 6 I only mentioned VBA<->VSTO interop with no further info. If that feature floats your boat (and it certainly will if you have existing VBA investments and would like to extend them with managed code), then go watch this 8' screencast on channel9 (or this soapbox video here).

There is also a great MSDN mag article on VSTO: Extend Your VBA Code With VSTO. It talks about VSTO and VBA interop in this section, and it also touches on ClickOnce deployment in this section.

Finally, relevant to the above, I thought I'd share a new (to me) acronym that I picked up this month: OBA (Office Business Applications).

If you are interested in understanding the relationship of the new C#3 and VB9 features to LINQ, then watch my 20' screencast and let me know there if you have any questions (unlike other videos, I advise you not to speed it up, because I speak very fast as it is ;)).

System.Core.dll (one of the new 3.5 assemblies) has tons of types as you'll recall, so I thought I'd see if anything changed between Beta 1 and Beta 2.

First, do not panic when you open up System.Linq namespace and you do not see the Func delegates. They are still in the assembly but they moved to the System namespace and they also have new friend delegates with various overloads called Action, which are the equivalent of Func but with no return type (all of those changes make perfect sense if you ask me).

The System.Management namespace (with the 20 types inside it) has been renamed to System.Management.Instrumentation. Do not confuse this with the separate, same named assembly that is part of Fx 3.5.

There have also been some small changes to the System.Expressions namespace so revisit your code if you were using those (typically for writing your own LINQ provider).

Finally, the BigInteger is still marked as internal so I personally am giving up hope of seeing it make a come back...

With Visual Studio 2008 Beta 2 some (good) changes were made to the location and versions of the .NET 3.5 assemblies, which previously were quite inconsistent (two additions were also made and I updated the previous post with those).

The .NET folder under Windows (C:\Windows\Microsoft.NET\Framework\) does not include a build number in its name now, it is just "v3.5" (with Beta 1 it was "v3.5.20404"). If you had explicit references to that location (e.g. in code, config files etc) you will have to change them.

The file versions of the v3.5 assemblies is now 3.5 (that was not the case previously for all of them). They still differ slightly between them on the build number but at least most[1] of them are now in the same place and you can see that in the following partial screenshot of "c:\Program Files\Reference Assemblies\Microsoft\Framework\v3.5\"


Now with Beta 2, the assembly version numbers are more consistent with each other (and different to the file versions of course). You can see those using your favourite disassembler, or simply via the VS references dialog:


As a reminder, to understand what each one of these assemblies offers, see my blog entry on the green bits.

[1] In the 3rd paragraph above I wrote "mostly" because there is one assembly that is not in that same place: System.DirectoryServices.AccountManagement.dll is one level up in the folder hierarchy (!). So to reference this one you have to browse explicitly to that path from the VS references dialog. Its file version number is consistent with the rest (3.5.20706.1) and its assembly version is 3.5.0.0

In my demos you will never find superfluous using statements at the top of code files. When I am trying to explain some new API, I want it to be very clear what namespaces are being used. I have seen many other presenters that leave in there every namespace under the sun and it always annoys me. The other thing I try and do is remove references to assemblies that I am not using (for the same reasons). In fact, I used to do both of these even in real projects; even though there are zero performance implications for either, it just felt cleaner to me.

Now with VS2008 the manual process of removing namespaces is taken care for you. Simply right click in a code file and you see a new option as shown here:


Great! I am not so sure about sorting though. It sorts alphabetically and perhaps that is a good idea now that I think of it, but I am used to sorting my namespaces by length from shortest to longest so a nice triangle is visually formed (yes, I am weird, I know). More seriously, I usually just leave the last namespace I imported appear at the bottom of the list...

The sad thing is that this feature only takes care of using statements and NOT of assembly references as hinted in my opening paragraph. The ironic thing is that while this is a new C#-only feature, in VB (even with VS2005) you can indeed remove unused assembly references from the project properties. If only the two teams talked to each other and both decided to implement the other's complementary feature...