GAT is VS Solution Centric
How would you suggest one approaches the following scenarios?:
1) A developer has created a non-GAT based solution. The developer requires an extra project to be created and added to their solution with via a GAT package. [the need for the project was not predicted at the time of the solution creation]
2) A developer requires a solution to contain 2 or more projects which are to be created from separate GAT packages.
The solution centric GAT seems to require the creation of a new VS solution for each package instance [see quote 1 below]. This is not scalable. Only small, single user solutions would be suited to this.
GAT packages need to be enabled and operate at the VS Project template level as well as the VS solution level.
Please tell me if I am wrong. Please rectify it if not.
Many thanks.
GAT Help, Quote 1
“Launching a Solution Template from the Add New Project Dialog Box
Solution templates that are part of a Guidance Package always start a new solution and enable their Guidance Package, regardless of whether an existing solution is already open.
Launching a Project Template from Within an Existing Solution
A project template never enables its Guidance Package, so it can be unfolded only if the package has been enabled using Guidance Package Manager, or if the solution is started from a solution template. In turn, this enables the Guidance Package. Project templates are shown in context menus and the Add-New Project dialog box only if the template is associated with a specific target (solution root or solution folder), by a bound or unbound template reference.”
[4775 byte] By [
GJB] at [2008-1-29]
You are wrong, you can activate a GAT package in an already existing solution.
1) Create a GAT package, create a binding recipe in that package, have the actions of the binding recipe create a new UnBoundTemplateReference.
The UnBouldTemplateRefrence will unfold the template that your want.
In the logic of the UnBoundTemplateReference.IsEnabledFor return true for the places where you want your template to appear.
When a developer with a non-gat solution wants to use your templates, then he just need to go to Tools|Guiadance Package Manager and enable your GAT package, in that moment the binding recipe will run and the template refertence will be created, now he will be able to unfold your template.
2) Same as 1, just use a multi project template instead.
Thanks for putting me right.
I see that it is possible to create a GAT based project, in a non-GAT solution.
However, from the developer’s perspective it seems unintuitive to have to go to Tools|Guidance Package Manager and to enable the GAT package.
Why should a developer care if the project they are creating is GAT based or a normal VS template based? If they want a new project, they will look in the ‘Add New Project’ dialog.
Project templates need to be capable of ‘enabling’ GAT packages. Would this be possible for a future GAT release? Thanks again.
GJB at 2007-9-9 >
In GAT, there are two kinds of templates:
- Starting point templates
- Regular templates
The first kind are those solution or project templates that can start a new solution. These must go to the Solutions template folder. These are available *alway* irrespective of whether the user enabled the package or not. Whenever you unfold any of those templates, the corresponding package will be enabled automatically.
The second kind are regular templates, and they are subject to the contextualization that is a core concept of GAT: guidance in *context*. This context means that nothing appears anywhere unless there is a reference (either a template reference or a recipe reference) pointing to it. This is required so that multiple guidance packages do not polute the developer experience, and also, so that only the relevant items are available at any given time. Enabling a package is an explicit action where the developer specifies that he's going to use the features of it, in an existing solution that was not created with a package template. The only other option we could have is to enable everything for every solution, which doesn't make for a good user experience, IMO.
At the point the package is enabled, the binding recipe kicks in and can turn on visibility on whichever templates it exposes on whatever locations it decides (either bound or unbound template references added).
I hope this clarifies the reason why we did it that way. Thanks for your feedback!
kzu at 2007-9-9 >
