An Update on Whidbey/Yukon Release Dates

In case you missed it, in this article key microsoft executives are quoted as saying that Whidbey and Yukon are still slated to ship together but that won't be by end of June as earlier stated. They are now estimating that “summer” is a better statement of expected arrival. This may align itself nicely with the PDC 2005 September date. It sounds like both teams blame each other, but really, a lesson can be learned here for all of us: Cross product integration means longer delivery cycles. This is going to be a tough nut for our industry to crack moving forward, not just Microsoft. Is that what SOA promises?

Refactoring for VB.NET 2005 Going Away?

Well, not completely.  You have to read a little bit into this post, but it appears that the only support for refactoring in VB.NET Whidbey is the Rename Symbol function. To me, this means that one of the major differences between C# and VB.NET in Whidbey will be refactoring support, as C# Refactoring implements a few more functions. 

By the way, this shouldn't completely surprise anyone.  Check out the following post from a year ago.  It describes the refactoring features that C# Whidbey will support (subject to change, of course).  But in one of the comments from Scott Wiltamuth (a C# Product Unit Manager) it is suggested even then the VB.NET might not get much more than Rename Symbol. 

Very prescient.

A look inside the process

For the past few months, I have been working as part of a large team of developers working on the new release of a product.  By large, I mean that there are probably over 100 working on various pieces of the code.  Going through the process has given me a great deal of respect for the issues that must face any large team of developers. For some reason, the efforts that must be going on at Microsoft as they prep for Whidbey, Longhorn, et al came to mind. Check out the following post by Scott Guthrie about the process that the ASP.NET team is going through as they get ready for Whidbey Beta 2.  Quite enlightening.

Oshawa .NET: Building Mobile Applications

I'm doing a talk at the East of GTA .NET users group tonight in Oshawa. This is the same MSDN User Group tour event sweeping across Canada. I'll be talking about some of the limitations of the Compact Framework and SqlCE. Should be fun - hope to see you there.

Registration Links and slides (afterwards) can be found here.

VS.NET IDE Teaching an old Dog new Tricks

I love hanging out with new VS.NET developers. It's enlightening to hear the troubles the face and their new found energy to solve them. I have to blog more about these - but in general, there are often things that I do out of habit in the IDE or things that I live with because I'm too lazy (or tired or busy) to find a way around them.

Two new tricks were brought to my attention by an associate of mine.

“How do I find all of the references to a class or usages of a member?” or “When I right click on a class and select Go To Reference, it goes to the first one it finds. How do I go to the next one?”.

The best answer is CTRL+SHIFT+1 which will jump you to the next reference. CTRL+SHIFT+2 will take you to the next reference.

I couldn't find this short cut anywhere in the menu's. The complete list of short cuts can be found here.

Which begged another question. Can I put short cuts or favorites in the IDE? Indeed, under View>Other Windows there is a favorites window which is your machines favorites. This is great to have docked right next to your Dynamic Help (if you have it turned on).

A similar question was “How do I find all of the descendent's of a class or implementations of an interface?”. I always using the online help for that, which doesn't help for your own code. One of the solutions I found (and maybe there is a better one) is to use Find Symbol under the Find and Replace menu (ALT-F12).

 

VS Live Orlando: Building "Operations-Friendly" ASP.NET Applications with Instrumentation and Logging

Yes, it's the longest title of all VS Live Orlando presentations! It's a big topic and it deserves a big name.

I'm heading out Monday night to hurricane country to deliver this talk on Tuesday morning. I like this topic because when you get into it, it's like an onion. It doesn't look like something terribly sophisticated but as you get into you find there are more and more layers to peel back.

Building Mobile Applications, Metro Toronto .NET Users Group

Tomorrow night I'm presenting at the downtown Toronto .NET users group - topic Pocket PC development with the CE framework. I'll have a new HP 4700 device with a VGA resolution screen for folks to take a look at - courtesy of your friendly neighborhood HP rep. I'll also have my trusty 5650 with the old form factor for you to play around with. Hope to see you there.

Details: http://www.objectsharp.com/oNewsUpdate/ReadingFullStory.aspx?StoryNum=-28

It's Here - Visual Studio Team System Arrives

If you have been itching to get your hands onto VSTS, the time is at hand.  It can be downloaded from the Visual Studio 2005 web site here.  For the moment, you have to be an MSDN subscriber.  And as a word of warning, VSTS can only be installed on Windows Server 2003.  So if you don't have a spare 2003 server kicking around, it's time to start building one.  That's how I'm spending my evening.  While I'm waiting for the 3+GB download.

Shorthorn Longhorn

So this will cause a few blogs. I have just heard that....

  • Longhorn slated for 2006. Longhorn server 2007.
  • Winfx, and Avalon are coming to windows xp in 2006. Indigo as well - and on Windows 2003 as well. These are all part of WinFx that is going to be extremely important for .NET developers and companies wanting to take advantage of these improvements.
  • Winfs is leaving longhorn (post release). So that means ObjectSpaces and the Microsoft Business Framework too.

Wow. Never a dull moment. I'm attending a briefing with Jim Allchin in an hour so I might have more I can tell.

But will we also see a delay of ObjectSpaces or the Microsoft Business Framework until after the longhorn release. Those have been recently tied into WinFs - but no specific announcements about that - and I wouldn't be surprised if that changed soon. 

Assembly Signing Changes in VS2005

Just spending the evening playing with Visual Studio 2005 (which says a lot about my life, but that's another story). Actually, because a lot of my most recent has been with COM+, I've been poking and prodding in that area. As a result, I have been (by necessity) signing my assemblies and am happy to report an improvement in VS2005.

As a refresher, signing assemblies in VS2003 and earlier meant adding attributes to the AssemblyInfo file, something similar to the following.

[assembly: AssemblyKeyFile("..\\..\\ObjectSharp.snk")]
[assembly:
AssemblyDelaySign(false)]

But there are a couple of issues associated with these attributes.  First, the path to the key file is actually embedded in the assembly.  If you use a full path, it is possible that information about your machine (servers and directories, for example) can be easily extracted by using ildasm.  Not overtly dangerous, but not the best situation.

Also, providing a relative path to the key file is annoying.  I'm sure most of you have dealt with the trial and error of finding exactly where the .snk file is relative to the compilation directory. 

Finally, because compilation cleanliness is important to all of us, keeping the AssemblyKeyFile attribute in AssemblyInfo generates a warning message.  Not always critical, but annoying.

This is no longer necessary in VS2005.  Instead, the name of the .snk file is included as a property on the project.  Simply right-click on the project in the solution explorer and select Properties.  Then click on the Signing tab.  The path to the .snk file can be provided right there.  Providing this information updates the project file, which in turn is picked up by msbuild at compile time.