VS 2005 App Building Diary Day 1: Whidbey Versus the VSCmdShell
Today kicks off the first of three “PM App Building” days on the VSCore team. As a tester I remember laughing at the concept since it was apparent there were PM’s that clearly hadn’t actually used the product they helped design in such a long time. It was always amusing watching them run into design issues and bugs you had been telling them about for the last few months once they actually tried to do anything with the product. Now I find myself on the other side of the fence.
I’ll be using this as a running log of my experience using VS to finish (hopefully) the VSCmdShell project. Not sure if I’ll include all the bugs I find, useful code snippets I write, or just my impressions. I’ve never tried keeping a log like this so it should be interesting.
9:19 I arrive. I live seven miles away and I think it just took 40 minutes to get here. I had checked E-mail before I left and arrived to find 20 more mails in my inbox.
9:40 E-mail done: Current e-mail fires have been extinguished so I felt better about turning on my OOF message that informs people they may not hear back from me until Friday or Saturday.
9:41 Install Complete: The RC build of the VS 2005 beta that I installed (starting last night) appears to have completed. I’m always a little frustrated that there is no obvious “one click” at the start of the install that will just select defaults and also install MSDN at the same time. I also got some red text that let me know I was missing important components if I wanted to use the Visual Studio Tools for Office. Since I’m not going to be using that stuff I decide to ignore the message. Now that VS launched, my oof is on, and my Ipod is playing the Chili Peppers I feel I can start working.
10:00 First Interruption and Bug #1: Mark just stopped by to ask for my help organizing some Beta 1 kickoff activities that may include an executive chat with MVPs. Seemed like a good stopping point. I really like the simple look of VS 2005 now compared to VS 2003. I choose the “General Development Profile” since I know it most mirrors the VS 2002/3 settings. This “profile” has been a mission of mine ever since I heard they were going to have startup profiles. You’d be surprised how hard it was to get this included and the fight different groups will put up against including such a profile.
Being paranoid about using an upgrade wizard and wondering what the new code generation looks like I decided to start a new add-in project and cut/paste the existing VSCmdShell code. My new add-in is created and immediately has two build errors that I didn’t write. Time to write a DND note for my door in addition to the e-mail OOF. Oh, I just found Craig’s post that explained the build errors I was getting. It is a MUST read if you are developing add-ins with the Beta.
10:18 Bug #2: Help search just failed asking me to find a directory where my hxs files might be located. Nothing I enter makes a difference and it seems I really don’t have the files it is asking for despite doing a “full” help install. Whenever I do a help search I get this repeated a few times. After clicking cancel I give up on help search and went for the TOC. The TOC led me to the “What’s new in Extending VS 2005” topic that has my favorite line… “DTE.Toolwindows.CreateToolWindow2 The new CreateToolWindow2 method creates a new tool window and hosts a user-defined control in it. A shim control is no longer required.”
Just changed the namespace to VSCmdShell and the refactoring pop-up just saved me five minutes. On problem… if you rename the namespace of an add-in you still might have to change the assembly name if you like those to map. You will also have to change the MyAddin.Addin file to point to your new namespace/class names.
11:05 Bug #3: I ran into problems with the registration of my command. Future registrations would outright fail. “Devenv /setup” would have previously cleaned up my “cmdui.prf” file and let me register my command. This apparently doesn’t work in the beta and you have to manually delete/rename your cmdui.prf file in your app data directory to reset your command state.
Oh, and don’t try and use a space in your command name. In V7 this passed when it shouldn’t have and would mostly work since we replaced the space with “_”. In VS 2005 we just throw an “Argument not within expected range exception”. Luckily Craig sits down the hall from me because you don’t really know which argument had the issue.
12:48 Stumbling: By now I assumed I would have my parity with my Everett version in Whidbey. For some reason I’m having problems with the following lines:
System.Reflection.Assembly asm = System.Reflection.Assembly.GetExecutingAssembly();
Windows2 windows = (Windows2 )applicationObject.Windows;
windowToolWindow = (Window2)windows.CreateToolWindow2(addInInstance, asm.Location , "VSCmdShell.CmdTextBox", "VSCmdShell", "{D1DE0220-67BE-48c4-8D88-19780F710A00}", ref windowControlObj);
For some reason there is a file load error when I use the running assembly. Well, at least I’ve had lunch now.
2:48 Needed Cookies after Bugs #3 and #4: Two hours and a bunch of over the shoulder debugging, assembly registering, and bug finding later I have a workaround. Something is going wrong when the assembly tries to load when under the debugger. My code works fine if I run outside the debugger and attach later.This was Bug #3. Along the way we happened upon Bug #4 where your command might mysteriously consider itself disabled and appear grayed out for no good reason. For good measure delete your cmdui.prf file, get some cookies to snack on, and start over. J Hopefully I’m suffering now so you won’t have to when we ship. Now I’m finally able to make progress.
3:36 Bug #5: I was seeing blank commands in my intellisense dropdown for listing VS commands. There shouldn’t be any. I had to add the > 1 string length check when looping through the DTE commands (shown below) to work around this in Whidbey.
foreach(Command cmd in dte.Commands)
{
//HACK: There might be blank command names in the beta. The > 1 should work around that
if (cmd.Name != null && cmd.Name.Length > 1)
{
//Add the command to the Command List in the dropdown
this.addOneToList (cmd.Name );
}
}
4:46 Bug #6: If I shutdown the instance of VS I’m debugging a blank toolwindow is orphaned and left loosly associated with the attatched debugger. I’m working in integrating with some of the DTE windowevent code so that I can close my intelisense window when the toolwindow closes. I also spent some time to verify that this ophaning happens in a less tainted environment than when I’m debugging window eventing.
5:13 Found Good IDE Event Code : If you are looking for sample code for hooking up to VS IDE events then you really need to check out the “EventWatcher” add-in. I wanted to know when the VSCmdShell window lost focus so used the following code in my connect.cs file.
private EnvDTE.DTEEvents dteEvents;
private EnvDTE.WindowEvents windowsEvents;
public void OnConnection(…)
{
…
applicationObject = (DTE2)application;
EnvDTE.Events events = applicationObject.Events;
windowsEvents = (EnvDTE.WindowEvents)events.get_WindowEvents(null);
windowsEvents.WindowActivated +=new _dispWindowEvents_WindowActivatedEventHandler(windowsEvents_WindowActivated);
…
}
void windowsEvents_WindowActivated(Window GotFocus, Window LostFocus)
{
//Here I compare the LostFocus caption to my known window
//caption. If it’s a match then I close any extra windows
//my add-in might have created that are not closed since VS
//never really destroys the window
//I could probably use the HWND property as well for a
//quicker check since this will be called often
}
5:25 Heading Home: I finally feel like I’m ramped up in Whidbey and making steady progress. I’m going to end on a good note for at least a couple of hours before kicking this back up again. More updates expected as the week goes on. It’s also a good time since my Chili Peppers playlist just ran out. I need to think of some good music to code to for tomorrow. I generally code by TV at night.