The new Guidance Automation Framework GAX 2010 and GAT 2010 which is installed through the Extension Manager in Visual Studio 2010, provides a nicer usability experience compared to the Visual Studio 2008 predecessor. It is installed using the new vsix installer. A vsix install is much nicer than the old msi install since it integrates into Visual Studio. You can uninstall using the Extension Manager and if a new version comes out it should appear on the Updates tab of the extension manager.

Another nice thing is that a generated factory template solution now only consists of one project which itself results in a vsix file. So the installer of your own generated factories will also be vsix files. Nice…

But nicest of all is the fact that it is automatically integrated with the Visual Studio 2010 Experimental Instance (formerly known as Experimental Hive). Before you had to manually edit your recipes to get them to register in the Experimental Hive. But know you just press Ctrl+F5 and the Experimental Instance is automatically launched with your factory installed. It is now almost easy to debug your recipes. :)

But apparently there are few weird bugs in GAX/GAT 2010. One I run into all the time is this error:

Unable to read the project file 'Something.csproj'.

C:\Something\Something\Something.csproj(354,3): The imported project "C:\Microsoft.Practices.RecipeFramework.Build.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.

Which happens when I try to open a Guidance Automation solution.

For some reason the declaration of the variable RecipeFramework in the project file is not provided. This I deal with by editing the Project file by hand and adding a declaration to the end of the first PropertyGroup like this:

  <RecipeFrameworkPath>$(DevEnvDir)Extensions\Microsoft patterns and practices\GAX 2010\2.0.20406.0</RecipeFrameworkPath>

After applying this fix I can open the solution.

I have read somewhere that it is important to adhere to the following install order:

1. Visual Studio 2010 Ultimate or Professional (obviously)
2. The Visual Studio 2010 SDK
3. GAX 2010
4. GAT 2010

And this might be what I have screwed up on the particular machine where I get the error.

Anyway the above mentioned fix works. And overall I am very satisfied with the new improvements in GAX/GAT.

Imagine that you want to make an extension for Visual Studio 2010 that creates new custom right click menus for the Solution Explorer. Imagine that you could do it by just implementing a good old .NET interface like this:

public class MenuManager : IMenuManager

{

public IEnumerable<IMenuItem> GetMenus(ContextLevels menuForLevel)

{

var menuItems = new List<IMenuItem>();

var menuItem1 = new MenuItem("My Menu1");

menuItems.Add(menuItem1);

var menuItem2 = new MenuItem("My Menu2");

menuItems.Add(menuItem2);

return menuItems;

}


public string MainMenu()

{

return "My Main Menu";

}

}

Well it turns out you can. In MME I have helped you do exactly that. No more using the convoluted add-in model of Visual Studio to accomplish this goal. And it is also much simpler than using GAX/GAT (that can do so much more to be fair).

You can easily install MME, either by downloading directly from Codeplex or by installing directly from the Extension Manager in Visual Studio 2010 (you can find it under the Tools menu).

MME does not work for the Express editions of VS.

I also recommend installing the MME MenuManager template which you can also find in the Extension Manager.

At codeplex you can read more about implementing and deploying MME’s and also get further insight on the architecture.

Just released version 1.2 of SolZip my convenient tool for Zipping Visual Studio 2008 solutions

The major is a single install for SolZipMME, so you won't have to install ManagedMenuExtensions beforehand.

The release notes are here:

1. Bug Fix: when multiple projects where referering to the same file it was added to the archive multiple times.
2. SolZipMME uses SaveFileDialog instead of FolderBrowserDialog for Zip files.
3. A single file installer for SolZipMME.
4. Clipboard functionality now works on Vista / Windows Server 2008.
5. SolZipGuidance changed. The menu will no longer appear on projects that are not C# projects. SolZipMME not changed.
6. Support for $(SolutionDir) and $(ProjectDir) placeholders added
7. Now works on Windows Vista even if UAC is not turned off

Enjoy...

I just released version 1.1 of SolZip which can be downloaded from the download page at the SolZip site.

The new action packed version contains one major improvement, one bug fix, and a few name changes:

1. Now Source Control bindings for TFS and SCC can be removed from sln and csproj files. The default for all 3 UI's is that the bindings are removed, but you can optionally choose not to remove them. Feel free to contact me if you need bindings from other source control vendors removed.
2. A bug fixed that made WinZip clients give a warning when unzipping certain archives made by SolZip. The warning was given when there was .. (2 dots) in a path in one of the zipped files.
3. The Name SunZip.exe for the commandline tool was changed to SolZip.exe. Because SunZip sounded too much like UnZip.
4. The Name SolutionZipper changed to SolZip everywhere. Except for SolutionZipper.dll which has been changed to SolZipBasis.dll

In the next version I will try to include ManagedMenuExtensions in the install so you won't have to run more than one setup to install SolZipMME.

Enjoy the new version :O)

I just released a new codeplex project SolutionZipper which makes it a breeze to zip compress your visual studio solutions and projects. "What's wrong with WinZip you might Ask". Well WinZip has no knowledge of Visual Studio Solutions, which means it will compress everything in the folder, including bin / obj folders and other random debris.

I accomplish the compression by using the following algorithm:

1. Iterate over all items and projects in the sln file and zip each of these.
2. Zip the sln file itself.
3. Iterate over all items in the csproj files and zip each of these. The iteration is done using Linq to Xml of course.
4. Zip the csproj file itself.

As you might have guessed SolutionZipper only works for C# projects, and is only tested with VS2008.

I offer three UI's for SolutionZipper

SunZip - A commandline tool.

SolZipMME - Providing Right click menus for Visual Studio 2008 using Managed Menu Extensions .

SolZipGuidance - Providing Right click menus for Visual Studio 2008 using Guidance Automation (GAX).

For the actual zipping I use the excellent open source framework SharpZipLib.

I was using my codeplex project ManagedMenuExtensions recently when I realized that it threw an Exception, when clicking on a menu attached to a C# project under a solution folder. The reason was that the object which normally contained an EnvDTE.Project when a project was clicked contained null, when this project was contained in a solution folder.

I normally use this code to get at the selected project (m_VSStudio is the DTE object of the current solution):

private UIHierarchyItem SelectedItem

{

get

{

UIHierarchy uiHierarchy = m_VSStudio.ToolWindows.SolutionExplorer;

if(uiHierarchy == null)

return null;


object[] items = uiHierarchy.SelectedItems as object[];

if(items == null || items.Length == 0)

return null;


return items[0] as UIHierarchyItem;

}

}

The SelectedItem.Object of type object now contains a EnvDTE.Solution object if the solution is selected in the solution explorer, and guess what :O) it contains an EnvDTE.Project if a project is selected. It is this SelectedItem.Object that contains null, if the project is contained in a solution folder.

I googled this problem and found others who had the same problem, but none with a solution, so I had to come up with my own. I don't know if this behaviour is by design from Microsoft, or if it is a bug.

My Solution

Normally I would test if a project is selected with this code:

var project = SelectedItem.Object as Project;

if (project != null)

{

//Do something with the project

}

Now I use this code instead:

Project project = GetProject(SelectedItem.Object);

if (project != null)

{

//Do something with the project

}

Where I implemented GetProject(...) as:

private Project GetProject(object selectedItemObject)

{

var project = selectedItemObject as Project;

if (project != null)

return project; 



var item = selectedItemObject as ProjectItem;

if (item == null)

return null; 



return item.SubProject;

}

Not exactly beautiful, but that is to be expected when playing with Visual Studios AddIn model, and the kind of thing I try to hide in ManagedMenuExtensions. I haven't had a chance to look at Visual Studio 2010 yet, one could hope that they have done a better job of hiding the ugly underlying COM stuff.

Anyway, I hope this helps the next person who tries to search for a workaround for this rather weird behaviour.