Visual Studio 2010 has brought the concept of extensions, a brand new set of tools to extend and adapt the software to the needs of each developer. This is great for Visual Studio users, for having a shiny new Gallery with lots of extensions, but also for addin developers as it makes the development process much easier.
But how about Guidance Automation (the way to go in extending Visual Studio 2005 and 2008)? To have all those guidance packages out there Microsoft released Guidance Automation Extensions and Guidance Automation Toolkit 2010, that allows to building and deploying existing projects as a VSIX package in Visual Studio 2010. But putting an existing guidance package to work in Visual Studio 2010 isn’t a seamless process and requires to migrate it manually, described thoroughly in this guide:
How to Update a Visual Studio 2008 Guidance Package to Visual Studio 2010
Although it’s aimed for Visual Studio 2008 guidance packages it also works for 2005, even if not out of the box. The main glitch is in step 4d while running the UpdateGuidancePackageToVSIX recipe: it won’t update the Version and PublicKeyToken of .vstemplate files because it expects a different version of the Microsoft.Practices.RecipeFramework.VisualStudio assembly, we must edit the WizardExtension element in all .vstemplate files manually (or replace in all files using a an editor like Notepad++) so in the end it each of them looks like this:
Your ads will be inserted here by
Please go to the plugin admin page to paste your ad code.
Microsoft.Practices.RecipeFramework.VisualStudio, Version=220.127.116.11, Culture=neutral, PublicKeyToken=31bf3856ad364e35
Along the process some other issues might happen that could make the migrate more complicated:
- The classes of namespace Microsoft.Practices.WizardFramework.Configuration exist in two assemblies (Microsoft.Practices.WizardFramework and Microsoft.Practices.RecipeFramework.VisualStudio) and if any of these classes is used we’ll have to use an extern alias to resolve the ambiguity,
- If “The “GenerateMenuResource” task failed unexpectedly (…)” happens double check that the properties of each .vstemplate file are set to Build Action=Content , Copy To Output Directory=Copy if newer, Include in VSIX=True and also that there aren’t any .vstemplate files not included in the project (either include or delete them).
Jelle Druyts has released a neat little tool for Visual Studio that allows to easily design and visualize the configuration for a .Net solution, without messing around with ConfigurationSection and ConfigurationElement source files, which is quite handy when things become a bit more complicated. It’s still is in an early stage, but it looks rather promising.
Configuration Section Designer
About a month ago I was having some doubts if the upgrade from Visual Studio 2008 Beta 2 to the final release would be a flawless task, fortunately Scott Guthrie came to the rescue.
Sometimes things go wrong during a build, after all Team Foundation isn’t bullet proof, and a build will remain in some intermediate state forever, which means you have stop the hard way. Fortunately, Team Foundation’s command line has a few more commands than Visual Studio’s interface, and stopping one of those builds is quite simple:
TfsBuild stop Server TeamProject BuildNumber
TfsBuild stop http://your-tfs-server-here YourTeamProject BuildName
Technorati Tags: team foundation, build, build server
The main .Net driven event in Portugal is up and running.
The main discussion at work some time ago was the definition of the versioning policy to be used. Being a large multi-layered service framework, which is going to be used by several external applications in the near future, it’s extremely important to clearly define version roadmaps and how new features and bug fixes will be included in each version: basically a full blown version control that goes beyond just saving all source files in a CVS-like repository.
One of the main obstacles I’ve found around here is the fear of creating a branch. Like those people who have an irrational fear of snakes or spiders, some developers seem to have a basic, almost primal, fear of branching in source control, although their previous tool (*cough*Visual SourceSafe*cough*) justifies such fear. The problem is not really towards the branch itself, but how things will work out later when changes must be merged into the main development: changes will be lost, builds will be broken, everything will go wrong, total chaos and things must solved by hand. It couldn’t be more wrong, modern version control systems, like Microsoft Team Foundation or Subversion, can handle automatic merging quite well, even allow selective changesets to be merged in the main branch and making the process much less painful than some people think it is.
Technorati Tags: version control, source control, cvs, subversion, team foundation, sourcesafe
Those of you that have been working with DSL tools or software factories lately have missed this piece of software from Clarius:
It works either with Visual Studio 2005 or 2008.