I finally made HoL work with June 2006 version of GAT (don't ask me how, it just happened). However, I observe the following issues with HoL and it's documentation:

1. The XML snippets are not exactly right. for instance, XML namespaces are wrong ("igt-wizards" instead of "gax-wizards", or "igt-template" instead of "gax-template");

2. "Exploring the GAT" document makes reference to ".t3" templates instead of ".t4";

3. The template syntax in the document is wrong (for example <#= connectionSettings.Name #/> does not exist and ending slash is wrong, apparently - old syntax);

4. Getting a warning for this entry in the Recipe definition:

<xi:include href="TypeAlias.xml" xmlns:xi="http://www.w3.org/2001/XInclude" xpointer="xmlns(gax=http://schemas.microsoft.com/pag/gax-core) xpointer(gax:Types/gax:TypeAlias)" />

Warning 1 The element 'Types' in namespace 'http://schemas.microsoft.com/pag/gax-core' has invalid child element 'include' in namespace 'http://www.w3.org/2001/XInclude'. List of possible elements expected: 'TypeAlias' in namespace 'http://schemas.microsoft.com/pag/gax-core'. 

5. Bound recipe references disappear from the generated data solution after few iterations of making changes to HoL package.

I am especially frustrated with the last issue because cannot figure out where these references are stored. Any help will be greatly appreciated.

Hi Spider,

The GAT HOL was written for the GAT December 2005 version and was never updated to work with GAT June 2006 version, that is the reason for the issues you're mention in 1 to 4. Clarius is working on release a Toolkit for better integrate GAT and DSL Tools during Novemeber and along the included samples there will be an updated GAT HOL.

Regarding 5, even without much info about what you did I can tell you that bound recipes will get lost if for example you re-enable a package on a solution or if the state file is deleted. This is one of the main reasons why unbound recipes are much preferred over bound ones.

HTH,
-Victor.

Thanks for your suggestion about the note, I'll see if we can get this added.

re: #5, the HOL package for example adds bound templates references using the <TemplateReference> element (in the .vstemplate for the solution), in order to convert these to unbound templates reference you will need to use the CreateUnboundReferenceAction action to do so (usually specified in the binding recipe). Most probably you will have to code your own reference type, i.e. one whose IsEnabledFor implementation checks the target to verify it is dealing with a folder item and the folder is named "BusinessEntities" for example). Yes, it is more work to use unbound references, but they have proven in practice to be more useful than bound ones.

HTH,
-Victor.

Hi Spider,

The GAT HOL was written for the GAT December 2005 version and was never updated to work with GAT June 2006 version, that is the reason for the issues you're mention in 1 to 4. Clarius is working on release a Toolkit for better integrate GAT and DSL Tools during Novemeber and along the included samples there will be an updated GAT HOL.

Regarding 5, even without much info about what you did I can tell you that bound recipes will get lost if for example you re-enable a package on a solution or if the state file is deleted. This is one of the main reasons why unbound recipes are much preferred over bound ones.

HTH,
-Victor.

Victor,

Thanks for clarification. It would be nice to post a note at the download site about the incompatibility so people don't get confused.

Regarding my #5, should we even bother creating bound recipes if they cause so much trouble in backward compatibility? With HoL package, what does it take to convert bound recipes to upbound without losing anything?

Thanks.

Thanks for your suggestion about the note, I'll see if we can get this added.

re: #5, the HOL package for example adds bound templates references using the <TemplateReference> element (in the .vstemplate for the solution), in order to convert these to unbound templates reference you will need to use the CreateUnboundReferenceAction action to do so (usually specified in the binding recipe). Most probably you will have to code your own reference type, i.e. one whose IsEnabledFor implementation checks the target to verify it is dealing with a folder item and the folder is named "BusinessEntities" for example). Yes, it is more work to use unbound references, but they have proven in practice to be more useful than bound ones.

HTH,
-Victor.