Post a Comment On: the urban canuk, eh

As per my previous post, this exercise would probably be much easier if I used the Guidance Automation Toolkit, but in the spirit of Twelve Days of Code, I promised to boldly venture into areas I normally don't go. I decided that I wanted to try out a WizardExtension so that I could compare the experience with the Guidance Automation Toolkit. So I created a new project and added the following references: EnvDTE ENvDTE80 Microsoft.VisualStudio.TemplateWizardInterface System.Windows.Forms The Visual Studio Template documentation says you need to sign your assembly and install it into the GAC, but that's crazy. Rather than jumping through hoops, I found a handy forum post that describes that the Visual Studio follows the standard assembly probing sequence, so the assembly needs to be in a place that the devenv.exe process can find it. Signing and installing into the GAC is simply a security measure. I didn't want to dump my custom assembly into Visual Studio's assemblies (where I would forget about it) so I created a custom folder in %program files%\Microsoft Visual Studio 8\Common7\IDE and added this to the probingPath of the devenv.exe.config. To enable debugging for my custom wizard-extension, I use two Visual Studio instances. One for my wizard-extension, the other for testing the template. Here are the steps involved: Add the assembly and class name to your ProjectGroup.vstemplate file: <wizardextension> <assembly>Experiments.TemplateWizard</assembly> <fullclassname>Experiments.TemplateWizard.CustomizeProjectNameWizard</fullclassname> </wizardextension> Zip up the updated template and copy it into the appropriate Visual Studio Templates folder. Compile the wizard-extension assembly and copy it and its pdb to a path where visual studio can find it Launch a new instance of Visual Studio Switch back to the other visual studio instance, attach to the "devenv" process (the one that says it's at the start page) and set your break-points Switch back to the new instance of Visual Studio and start the template that contains your wizard extension debugging goodness!! Well, at least I saved myself the effort of signing, etc. This exercise showed that very little is actually done at the ProjectGroup level of a Multi-Project template: the RunStarted is called, followed by ProjectFinishedGenerating method. The biggest disappointment is that the project parameter in the ProjectFinishedGenerating is null. This is probably because the item being created is a Solution, not a project. The last ditch (seriously, ditch!) is to cast the automationObject passed into RunStarted to _DTE, and the work through COM interop to manage the Solution. That sounds romantic.