PDC Monday

I have not been making as many posts lately as I should, so I will be making a few posts today combined into one…

I got into LA late Sunday night. I waited in long lines at the ticket counter and (because I forgot my keys in my pocket) I spent a lot of time being searched by security, but I was lucky. Because of the fires many people had trouble getting here, and I know of a few who drove from Seattle to LA. One woman in the VS group, whose plane had been delayed over and over, finally got an alternate plane out. Unfortunately her luggage was on a different plane. The PDC Expo came to the rescue, though. Almost every booth was handing out T-Shirts, so she now has enough to wear until her luggage arrives. I did see the fires from the plane, I want to almost say they looked “cool”, but people have been loosing their homes and even their lives, so I don’t think that is the right way to describe it.

The wireless setup has been very convenient. Wi-Fi is setup at the conference (for free) allowing access anywhere you go. And even the hotel has Wi-Fi (again, free). I have been sitting in the bar at the hotel restaurant at night browsing the web, reading and responding to mail, and preparing this blog entry. At PDC 2001 the hotel I was staying at had wired broadband, but they were charging $30 a day. A lot has changed in just a few years.

I spent much of my time yesterday meeting with people at the Expo booth. Many of the questions we got were the standard ones about the automation model and VSIP, which means that we really need to work on that FAQ that we have been planning. I did go to a talk about MSBuild, it is some really cool technology making building software much easier both within and outside of VS.

Earlier this week we switched back to standard time. That makes it a bit easier for taking the telescope out in the back yard since it is darker earlier and I don’t need to stay up as late to see the planets. Unfortunately, this also means that not too long from now it will be dark around 4:30PM. I hate going to work in the morning when it is dark, and driving home from work in the dark.

There has not been too much here lately about new features in the next version of Visual Studio, code named Whidbey. Since more info is being given about the next version I will try to pick up the pace of descriptions about what we are doing. This time I would like to talk about the new way that VS will find and load Add-ins. VB5 would look for an .INI file, open and read its contents, then load the Add-ins it described. This was not the best way to create Add-ins since you had to write some special code, or even hand-modify, the .INI file when the Add-in is installed. Then in VS 6 we would look to the registry, enumerating the list of Add-in ProgIDs and do the appropriate loading of the defined Add-ins. This type of registry-based Add-in loading was good for VC/ATL written Add-ins because it was easy to modify .rgs files to register the Add-in, less optimal for VB6 Add-ins but still workable if you used the Add-in Designer because it would automatically generate the registry keys when it was registered. Then there was the requirement that the DLL be registered. This worked for COM Add-ins, but was a real pain to the .NET developer.

To make it easier for the .NET developer, and to fit into the xcopy deployment, non-registration spirit of .NET, we now have a way of loading Add-ins from XML files. The extension of this XML file is .Addin, and has a format such as the following:

Microsoft Visual Studio
8.0

Decsription of the Add-in
Short name of the Add-in
C:\foo.dll
ClassNamespace.ClassName 0
1

The tag can contain either a full path to an assembly, a path relative from the .Addin file to the assembly, or the full name of an assembly within the GAC. You can even give a UNC or URL to an Add-in.

So now when you create an Add-in, you generate an XML file that looks like that above, write a class that implements the IDTExtensibility interface, and put it in a specific directory on your hard disk. After doing this VS will find, load, and (depending on how you declare your Add-in within the .Addin file) run the Add-in.

There is also now a page within the Tools | Options dialog box that will allow you to select which folders on disk to look for .Addin files. Not only that but options are also available on this dialog box for completely enabling and disabling running both Add-ins and macros, for security reasons.

I will not be talking about it today (I need something for the next time I post), but you can add additional entries in the .Addin XML file to control other features of extensibility. More on those later