October 27, 2005
Visual Studio 2005 emerges from the oven
According to Soma, the turkey timer has popped, and it's ready for carving. Initial reviews indicate that it's golden brown and very juicy.
October 25, 2005
VB6 to VB.NET Migration: A Conversation with Jay Roxe
I recently interviewed Jay Roxe of Microsoft regarding VB6 to VB.NET migration. I think there's great stuff in this interview, and Dr. Dobbs has been gracious enough to publish it.
October 14, 2005
Creating Add-Ins in Visual Studio 2005
(a.k.a. If you've ever made an add-in in VS2003, you'll find the VS 2005 experience rocks.)
I'll walk through the very basics here.
First, create a new add-in project. This is under Extensibility projects in the New Project dialog:
This launches the Add-In Wizard, which will ask you a number of questions so that it can create the add-in the way you want.
The first question is, what programming language do you want to use to write your add-in:
Next, you're asked what hosts you want your add-in to work within.
You're then prompted to enter a name and description for your Add-In.
Another thing that the wizard can do is automatically add your menu to the Visual Studio menus. By default, your add-in will show up under the Tools menu, but you can easily modify it to appear under any menu you want.
You can also provide About box information for you add-in:
At that point, the wizard has all the information it needs to generate the add-in:
Code is generated that implements the IDTExtensibility2 interface. This interface has three important methods. The OnConnection method wires your add-in into the Visual Studio IDE. This code, by default, makes your add-in appear under the tools menu. The QueryStatus method lets you control when your add-in is enabled and disabled. For example, you might only want your add-in enabled when the user is working in a code file. Finally the Exec method is called when the user invokes your add-in. This method is where you hook in the meat of your add-in functionality.
When you press F5, magic happens. A test instance of Visual Studio is launched that contains your add-in. This lets you set breakpoints, and gives you a great debugging experience for your add-in.
Deploying the add-in requires a few manual steps, which are detailed well here.
October 05, 2005
Applications through the Telescope (a.k.a. has "migration" outlived its usefulness?)
When it comes to Windows Forms and Avalon, Microsoft is taking an interesting approach. After sitting through PDC session PRS321, and reading Mike Henderlight's most excellent blog, it's apparent that the focus is on interoperability, not migration. In fact, Mike makes it explicit by saying:
"We are currently NOT planning a strategy whereby we ship a migration wizard that will take your Windows Forms application and magically spit a WPF application out the back."
Instead, the WPF team seems to be investing heavily in making interop just work. You can host windows forms in WFP apps, and WFP forms in Windows forms apps; mix WFP and Windows Forms controls within either form technology; and even host ActiveX controls on WFP.
With technology changing as fast as it is, I wonder if the notion of "application migration" is outliving its usefulness as a concept. Imagine that you had an application that's hundreds of thousands of lines of code, and contains 50 to 100 forms. This app was either VB6 COM, or MFC. Maybe a year ago, you decided to migrate this app, in its entirety, to .NET. So you spent your personyear(s) getting it all .NET-ified. Now you're looking down the road at Avalon.
That's a lot of shiny new forms to throw away and rebuild. And, what's coming next that might rock your world? LINQ? WinFS? The message around migration is always, "Just do it this once, and you won't have to do it again for a long time." But, what if the rate of change really is accelerating? What if there's always one more thing coming that's so much better than what we have today? Isn't that a good assumption?
What percentage of your development resources do you simply write off to constant migration?
What if you never migrated again?
Maybe, the technology pressures are going to force a new kind of application (or actually, just an acceptance of an old taboo). Within an application, imagine extreme interop.
When you look through a telescope, you see some very bright shiny new stars up close, but the deeper you look, the farther back in time you see, and in the background there are some very big, old, things. Maybe this is the new application paradigm. I can see, five years from now, applications that contain COM, Windows Forms, WPF (Avalon), Indigo, and a few thing they haven't told us about yet. I see this as being OK.
What if there was a vendor out there who told you "To the best of our ability, your stuff will always run. Oh, we're going to keep shipping new and better things, but when you take advantage of those is up to you, not us, and you won't have to rewrite the whole app to use any new things." I think the industry is hungry for that kind of assurance. It would sure as hell be one less thing to worry about.
Will that vendor be Microsoft? They're doing it with Avalon, but that's one decision made within one little team. Every product team gets to decide if they are going to favor migration or interop. Any team that goes the migration route, if they can't migrate you 100%, is creating a chasm for you to cross. If you can make the jump, they'll be very nice to you.
Like I said, the idea of interop within an application is nothing new. We all have apps that are carrying COM/ActiveX components. We've just always been made to feel that that's bad; that it's not optimal; that it's a compromise. I think it's the new world order. I'm not going to run just to stand still. Application features are more important than the internal technologies used. Does infusing your app with Avalon let you ship sooner, with more features, and a better experience for your users? Infuse away. But getting a good ROI for a full migration isn't easy. There's a reason for that.
October 03, 2005
Native PDF Support in Office 12
In Office 12, you'll be able to save as PDF from Word, Excel, PowerPoint, Access, Publisher, OneNote, Visio, and InfoPath.