So much to write about
OK, I have been really bad in updating this blog over the past few months – the last time was mid-November. So what has been going on? Lots and lots of work. Mostly we have been preparing to ship VS by fixing bugs, smoothing out the wrinkles, making it more user-friendly, run faster, writing samples and power toys, etc. I have much to write about, and I will be filling in more details over the next couple weeks, but here is a quick laundry list of some of what I have been working on, as well as some tips and tricks:
Visual Studio Beta 2
Yes, Beta 2 has been out for a while now. If you are trying to develop Add-ins, you may get an error when you compile a newly generated Add-in using the wizard. This is caused by a bug in how MSI installs type libraries, and causes PIAs (the .NET wrapper around COM objects) to no longer work as they should. You can fix this by issuing a few command line commands. In a console window, cd into the C:\Program Files\Common Files\Microsoft Shared\MSEnv\PublicAssemblies directory, then run these commands:
Regasm /codebase EnvDTE.dll
Regasm /codebase EnvDTE80.dll
Regasm /codebase Extensibility.dll
Regasm /codebase Microsoft.VisualStudio.CommandBars.dll
Regasm /codebase VSLangProj.dll
Regasm /codebase VSLangProj2.dll
Regasm /codebase VSLangProj80.dll
This will fix the registration for the PIAs. This has been fixed for the final version of VS.
Cleaned up rebuilding Add-in commands
If you have developed Add-ins with commands, you are probably familiar with devenv /setup to rebuild Add-in commands. The problem with it is that it will also reset your command bar customizations. After beta 2, we changed this. No longer will you use the /setup switch, but you will be able to use a new switch, named /resetaddin. If you call devenv /resetaddin Namespace.ClassName (where Namespace.ClassName is the full name of the class implementing your Add-in), we will walk all the commands, find those created by the Add-in specified, and delete the commands and their UI. You can also pass * as the Add-in name, and we will delete all commands and UI for all Add-ins.
If you delete the .addin file for your Add-in at that time, then restart VS the command will no longer be there, so this makes uninstalling an Add-in very easy. If you leave the .addin file on disk, if the .addin file has the CommandPreload tag in the XML set to 1, then when you restart the command will be recreated.
We have added this command line switch to the project when you generate it using the wizard. This will allow you to debug your command creation code, and to make modifications to the commands in a way that is much easier than in previous versions of VS.
New Add-in command types
Also something new after Beta 2 is the ability to add new command types. You will be able to create Buttons, ComboBoxes (two different styles), and MRU lists (like the File | Recent Files menu) using commands. You will also be able to control how the UI element appears for a command. In past versions of VS, any UI for a command showed both a bitmap picture and text. With the new mechanism, you can show just a bitmap, just text, or both (and this works in Beta 2).
Better Handling of Custom Command Bitmaps
At one time, I was saying that if you created an Add-in using a language such as C#, J#, or VB, and you wanted a custom bitmap to appear next to your command, you needed to create an unmanaged (VC) resource DLL and you would not be able to use a .NET Satellite DLL to store the custom image. Well, plans change, and after frequent requests to change this behavior, with builds after Beta 2 we made this possible. You can now retrieve bitmaps from managed Satellite DLLs. Just create a DLL containing resources for your Add-in like you would for any other .NET application, and put a 16x16 bitmap (you can also use high colors now) in the resources. When we try to load the command for the first time, we will notice the Satellite DLL and extract the custom image from it.
Changes to the CommandBars Object Model
You may have noticed that there was a small change to the Command Bar object model in VS Beta 2. We now return System.Object when you call DTE.CommandBars. This was required for some performance changes internal to VS.
Content Installer Power Toys
I have been putting together a comprehensive list of tools for the content installer, and these will be shipped in as a power toys pack. These tools include uninstallers, starter kits for creating your own custom installers, ways for you to easily share .vssettings files, debugger visualizers, help files, samples, and code libraries, and even a wizard that lets you easily build VSI files for the content installer. Look for this to be available in the next few weeks.
PDC 2005
Yes, I will be attending PDC 2005 this year. I will be participating in two separate talks, and working at two hands on labs (not to mention meet the experts, etc), so stop by, say hello, and if you have any questions, I will be happy to help. More details about these sessions a little later.
Book
Now some news on the next version of our book. One of the reasons I have not written here for a while is because I have been busy writing for the past couple months. Yes, there will be a next version. The version in the box will be an updated 2003 version. We have cut a couple chapters and added a few new ones. No VSIP chapters just yet, but we may have some plans for that later, stay tuned for more information. But even better, the current plan is that there will be a copy of the book in each VS box!
Visual IL progress
I have not had too much time to work with my Visual IL project (http://workspaces.gotdotnet.com/visualil), but I have made some progress. The time bomb had long expired, so a couple months ago I uploaded a version without a time bomb.
I have also been working on a code model for IL. I tried using the Gold parser generator to generate the parser. When I was able to parse some test IL code, I started to write the code to generate a symbol table using the output from the parser - but then I ran into some snags. I have used tools such as Bison and Flex in the past to generate compilers, and Bison allowed you to embed code directly within the grammar to build up the symbol table, but Gold is intended to be language neutral, so you cannot do this. Therefore you need to write another parser to parse the output from Gold (at least that is my understanding and experience in how it works).
So I started looking around for a new parser generator, when I started thinking about Bison and Flex. I realized that the .NET Framework SDK already contains a .y file describing the grammar. A little cleanup, a lexer, and I have code up and running, parsing out IL files. Currently the code is compiling using managed C++, so I will need to evaluate if I want to convert it to C# or use it as is.
Once I have the parser complete, I will be able to create a CodeModel and then integrate into the object browser. I have also been playing around with an expression evaluator (or EE). An EE allows communication between the debugger (such as the watch window) and the programming language. This means you can use the watch window when debugging IL code. Finally, I have been working on refactoring the code. The goal is to have a library that you can use to easily create a language service with coloring and statement completion with as little code as possible.
I also have been working on converting the code into a starter kit. Imagine selecting a template from the new project dialog, and you have all the code necessary for a project. Just plug in the code specific to your project type to perform a build, and you have a project ready to go.
Macro tips
Now some useful tips for you VS macro users. After talking with a few people, I discovered that not everyone knows how to use the Macros IDE to make developing, debugging, and running macros as easy as possible. A couple weeks ago I received mail from somebody in the VB group asking about how they can best run and debug their macros. Because of some of the questions this person was asking, I did a quick usability test by asking a few people who rarely run macros to perform some tests. First, I asked them to write a simple macro (display a message box displaying the version of VS, or MsgBox(DTE.Version)). They started by typing in the macro, and then they switched back to VS, opened the Macro Explorer, found the macro they wanted to run, right clicked on the macro and then selected Run. Next, I asked them to debug the macro. They placed a breakpoint in the code, switched back to VS, right clicked on the macro, and selected Run. Finally, I asked them to create an event handler, and to debug that event handler. They created the event handler OK (a handler to capture the double click on a task item), but they could not figure out how to debug it.
There are much easier ways to do this. First, rather than switching back and forth to VS and running in the Macros Explorer, you can run directly within the Macros IDE. Simply place the caret within the macro to run, and press F5. The Macros IDE will look at where the caret is, find the macro in which the caret is located, and start running that macro within the debugger. Because the macro is run within the debugger, any breakpoints that are found will cause execution to stop at that breakpoint.
Debugging an event handler is just as easy. First, place a breakpoint in the event handler that you wish to debug. Then, within the Macros IDE, place the caret outside of the body of a macro, for example, put the caret on the imports statement of the EnvironmentEvents module. Then press the F5 key. This will set the Macros IDE into debug mode. Next, switch to VS and perform some action that will cause your event handler to be triggered. Because the Macros IDE is in debug mode, when the event handler is called and the line where your breakpoint is located runs, execution will stop, letting you debug the event handler.
Something else that does not seem to be well known about macros: suppose you write a macro that modifies the currently active text document. If you do use the Macro Explorer to run the macro, then focus switches away from the document window to the Macro Explorer window. But the Macro Explorer is smart, it remembers the window that last had focus, and switches back to that window so if your macro uses the ActiveWindow property, the window returned will be the window active before the Macro Explorer.
Turn off System Restore
Recently I was forwarded mail letting us know that creating a simple Add-in was using up gigabytes of HD space, and they were trying to figure out why. After some investigation we found that System Restore was turned on, and every time you built the Add-in DLL, the OS would backup the DLL. We always turn off System Restore because we are building multi-MB files (like msenv.dll, the main DLL for VS), and this would very quickly fill a restore point. This is not the official MS line, to turn off this feature of the OS, but if you have a dedicated computer for development and if something ever goes wrong you can quickly reinstall the OS, then you may want to consider turning off System Restore. This does not apply to just Add-in developers, but all developers.
Media Centers and Portable Media Centers
For a while I was trying to build a custom Media Center, everything except for the TV part worked fine. Eventually I found out that there was a problem with the chipset on the motherboard that I was using. So, rather than trying to start over I just bought an MC from Dell. I am happy with it except the case is a full tower (the custom one I was trying to build was very small and fit in well). Also, there is a problem with the computer blue screening every once in a while because of a memory parity error, so I am going to need to call Dell’s tech support. But it has been working well, I also bought a Portable Media Center. I heard that copying TV onto the PMC would take hours, but I found that it was not too bad at all. Now if I there was a program to convert DVDs to PMC, I would be happy.
Well, that is the quick details for right now. I will be posting some more details within the next few days and weeks about a few of the things I wrote here, plus there are some other things I want to write about, so check back soon for more!
