First of all Congratulation to the GAT team this is a really good work.

I was trying to figure out how the build of a Guidance Package (GP) works.
I would like to know what is happening behind the scenes when you build a GP.
Who is creating and compiling the ctc definition, who is creating the resource dll for our package, how is registering the package in the registry hive, etc

When you build a GP (as well as when you install it from the MSI, with some minor differences), a post-build command (that you will need to see by opening the csproj file in notepad, sorry :( ) is issued against the RecipeFramework.dll assembly, that contains the core functionality of GAX. It's an InstallUtil call that will run an installer class in GAX.

When a host is first "bound" with GAX, a class implementing a given interface must be registered with GAX as the one responsible for registering a GP with that host. When the previous command is issued for your GP, the attribute Host in your GP (which defaults to VS) is used to determine which registration class to call to give the host a chance to setup its environment for the new GP. Hence, GAX is not necessarily tied exclusively to VS ;-).

GAX itself does little work at this point: it basically registers the GP in a manifest of installed packages (currently in c:\Documents and Settings\All Users\Application Data\Microsoft\Recipe Framework\RecipeFramework.xml). It then just calls the host registration class.

The class reponsible for all the ctc and resource dll generation lives in the Microsoft.Practices.RecipeFramework.VisualStudio.dll inside %IDE%\PublicAssemblies. The class called from GAX to register a GP in VS is Microsoft.Practices.RecipeFramework.VisualStudio.RecipeFrameworkInstallerl

The process itself is fairly complex, and involves processing custom RegistrationAttributes (from the new Microsoft.VisualStudio.Shell), several classes in the CTC namespace inside our assembly, etc.

And we don't use a registry hive for the new packages. They are registered in the root registry tree for VS, so that you can test it directly anything special.

HTH,

/kzu

Hi Gaston,

All the magic is happening at installation time, when you actually install your package.

A .CTC file will be created and compiled into a .CTO file (in case you're wondering, yes, GAT redist includes the ctc.exe compiler).

Then a new resource dll will be created (cloned actually, from GAT resource dll) and properly updated to contain your custom resources.

Finally, new registry entries will be added to make VS load the new resource dll.

Hope this helps,

--
Victor Garcia Aprea
Microsoft MVP | ASP.NET
Followers of the IHttpHandler
http://clariusconsulting.net/vga

When you build a GP (as well as when you install it from the MSI, with some minor differences), a post-build command (that you will need to see by opening the csproj file in notepad, sorry :( ) is issued against the RecipeFramework.dll assembly, that contains the core functionality of GAX. It's an InstallUtil call that will run an installer class in GAX.

When a host is first "bound" with GAX, a class implementing a given interface must be registered with GAX as the one responsible for registering a GP with that host. When the previous command is issued for your GP, the attribute Host in your GP (which defaults to VS) is used to determine which registration class to call to give the host a chance to setup its environment for the new GP. Hence, GAX is not necessarily tied exclusively to VS ;-).

GAX itself does little work at this point: it basically registers the GP in a manifest of installed packages (currently in c:\Documents and Settings\All Users\Application Data\Microsoft\Recipe Framework\RecipeFramework.xml). It then just calls the host registration class.

The class reponsible for all the ctc and resource dll generation lives in the Microsoft.Practices.RecipeFramework.VisualStudio.dll inside %IDE%\PublicAssemblies. The class called from GAX to register a GP in VS is Microsoft.Practices.RecipeFramework.VisualStudio.RecipeFrameworkInstallerl

The process itself is fairly complex, and involves processing custom RegistrationAttributes (from the new Microsoft.VisualStudio.Shell), several classes in the CTC namespace inside our assembly, etc.

And we don't use a registry hive for the new packages. They are registered in the root registry tree for VS, so that you can test it directly anything special.

HTH,

/kzu

Here you can find more information:

Dynamically add commands to your VSIP Package
http://blogs.artinsoft.net/ocalvo/articles/169.aspx

Regards.

Daniel Gómez
Technology Manager
Infocorp
http://www.infocorp.com.uy