Hi,

I just had the following weird behaviour: I startet with my first sample solution (first steps in GAT) and tried to follow the Item template logic. I played a bit and made obviously one or the other mistake. Eventually (the GAT solution was OK by then) the Item templates (provided by the GAT solution and until then available in the test solution, context menu "Add") were gone. De/registering, rebuilding, and un/loading didn't help.

The weird part:

• the context menu showed no item templates (beyond the VS standard)
• In guidance package manager/enable packages two of the original six item templates reappeared
• In guidance package manager/enable packages/explore selected package all templates were shown (come to think of it: my own test template may have been the third one in this list)

But it gets better: I finally tried to create a fresh GAT solution to get a working version and to look for the differences. Using this new version I also created a new test solution. It worked. But then I tried to open the old test solution and I got some error messages about unknown properties. Which finally lead me to the realization that the GuidancePackage1Solution1.gpState file is crucial for the GAT package to work. Delete it and the item templates disappear, copy a save file back and the templates are back as well.

Now, *.gpState files are AFAIK used by the installer to keep track of information to be used for uninstall. It seems that the GAT package installer is run with every opening of the test solution (not just during register). And since the file is allways written back, any error in the GAT package will cause this information to be lost forever.

Questions for MS:

1. are my observations correct?
2. can I recreate this information without creating a new GAT solution every time?
3. Is this going to change?

Regards,
Alexander

Hi Alexander and Spider,

I would like to better understand the scenario you both are facing. From what I getting from your description, i.e. you're disabling and re-enabling packages and you're "upgrading" the package adding new recipes and expecting a solution using the previous version of the package to still work; these two will cause bound recipes to get lost. The first scenario (re-enabling packages) casues the state for the GP to be 'reset' to blank and re-created, which usually means bound recipes being lost (I can explain this in more detail if you want :-)) and for the second scenario you're actually modifying the package (which most probably will cause different state bits to be serialized) and then trying to use this modified package in a solution with previous state associated (for the package previous to modification), this may work or not depending on several factors, but as a rule of thumb you shouldn't assume a newer version of a package will work in a solution where an older version of it was already activated.

Let me know if you have questions regarding this,

HTH,
-Victor.

I was referring mostly to bound recipes and the fact that is very easy in a scenario like yours (re-enabling packages, continuos upgrading of the package, etc) to get their state lost. The cases I can think of are all related to bound recipes. I recommend you that you stick with unbound recipes only and you should be safe.

You can make manual changes to the generated solution and then continue to use a newer version of your package. Of course, nothing "automagically" will happen, and if for example your package includes an newer version of an item template, already unfolded instnaces of this template will not get automatically updated to the new version (only newly created ones will contain the new version). This means you may need to direct developers to upgrade "by hand" parts of the already existing solution or better yet you could provide a recipe to do so :-) In practice this works well when the changes are not major, but when for example you completely rewrote the generated solution structure this may requiere quite a bit of work from the developers of the product (again, you could always provide 'upgrade' recipes).

And you scenario of pararell development is totally valid, sometimes you can't afford to take the time to develop the entire factory before product developers start working on the product, and these two types of development must happen in pararell, this is just okay. Moreover, this is also a good thing, because factory developers should take feedback from product developers and use that to improve the factory.

Let me know if this answer your questions,

thanks,
-Victor.

Hi Alexander,

The .gpState file is not usedat all for installing. This file contains the information for which guidance packages are binded to the solution and some state like references state is stored there. What may have hit you is that bound references are lost when you re-enable a package (by your description I guess you used a TemplateReference to get your item template to show). This is one of the reasons why unbound references are much preferred today over bound ones.

Another thing you should keep in mind, is that there is a known bug when .gpState is under source control, you need to make sure it is writable (by setting its readonly flag to off or by checking out the file) before closing the solution you're working with.

HTH,
-Victor.

Hi Victor,

thanks for the reply.

I understand the concept of bound and unbound references, yet I haven't been exploring the sample solution in such detail. And the documentation (yes, I found it ;-)states that it contains quite a bit more information, e.g. initial state of unbound references, and about the various packages used by the solution. So the .gpState is even shared among all packages, meaning that one misbehaving package will affect all other packages as well?!

Anyway, this only explains the cause, not the diagnosis or the cure.

Diagnosis: If my templates are gone, how can I find the root cause? Since my template was the third in line and in guidance package manager/enable packages I (think I) saw two items I can only guess there was a problem with my template. However I didn't get any form of warning (not in the output, nor in DbgView). How should I know (especially in a project on which more people are working simultaniously) which file is the culprit? Is there a way to check the validity of the package or perhaps to enable more detailed feedback during registration?

Cure: Once I have tracked the problem down I still face the problem that my .gpState is lost. Will it be recreated ifI solved the problem? If not, how do I bind the references again (not to mention the other information in the .gpState)?

And as an add-on question: A collegue just had a similar problem with a solution template. Where is this information stored (since there is not yet a solution)?

Regards,
Alexander

I face exactly the same problem. I make small updates to my guidance package (derived from HoL) and reload my data solution project originally generated by the first working version of the package. After few iterations of registering/unregistering new package, I lost all the references to the recipes except an unbound one. However, when I choose to explore the package, it shows all recipes available. Disabling and re-enabling the package does not help.

I am not looking for an explanation or diagnosis, only a cure. After all, the project has been created by an original version of the package. In the Guidance Package Manager window I can only see an option of executing a recipe or deleting it, not adding it back.

Do you have a solution to this problem?

Hi Alexander and Spider,

I would like to better understand the scenario you both are facing. From what I getting from your description, i.e. you're disabling and re-enabling packages and you're "upgrading" the package adding new recipes and expecting a solution using the previous version of the package to still work; these two will cause bound recipes to get lost. The first scenario (re-enabling packages) casues the state for the GP to be 'reset' to blank and re-created, which usually means bound recipes being lost (I can explain this in more detail if you want :-)) and for the second scenario you're actually modifying the package (which most probably will cause different state bits to be serialized) and then trying to use this modified package in a solution with previous state associated (for the package previous to modification), this may work or not depending on several factors, but as a rule of thumb you shouldn't assume a newer version of a package will work in a solution where an older version of it was already activated.

Let me know if you have questions regarding this,

HTH,
-Victor.

Victor,

Thanks for quick response. My scenario was very simple - to install HoL package and apply changes to it according to HoL documentation (I stayed within suggested examples only, like changes to connection strings and their synchronization). I realize that "we shouldn't assume a newer version of a package will work in a solution where an older version of it was already activated" as you said, but that is exactly whatis causing all the questions:

• Since you are not stating unconditionally that "the new version WILL NOT WORK with an older solution", whatare the conditions of making it work?
• What types of changes to packages cause this effect and what changes do not?
• Does this effect mean that for certain changes in the package we need to entirely re-generate solutions based on it?
• Does this effect mean that making manual changes to the generated solution is not recommended if the package still requires some changes as well?

The last question has very serious implications. We are working on creating an application framework, which we are planning to deliver to developers so they can build their applications according to the firm's standards. we realize that both development of the guidance package and application development are long processes and we would like to conduct them in parallel as much as we can. That said, we obviously cannot afford to let developers to re-generate their entire solution every time we extend or fix our guidance package. We wanted them just to install a new version of a package and let them continue their development with new recipes added to IDE or existing recipes working better. Of course, we don't expect updated recipes to fix previously generated code, these types of defects developers would need to do manually.

Please let me know if you have any questions.

Thanks

I was referring mostly to bound recipes and the fact that is very easy in a scenario like yours (re-enabling packages, continuos upgrading of the package, etc) to get their state lost. The cases I can think of are all related to bound recipes. I recommend you that you stick with unbound recipes only and you should be safe.

You can make manual changes to the generated solution and then continue to use a newer version of your package. Of course, nothing "automagically" will happen, and if for example your package includes an newer version of an item template, already unfolded instnaces of this template will not get automatically updated to the new version (only newly created ones will contain the new version). This means you may need to direct developers to upgrade "by hand" parts of the already existing solution or better yet you could provide a recipe to do so :-) In practice this works well when the changes are not major, but when for example you completely rewrote the generated solution structure this may requiere quite a bit of work from the developers of the product (again, you could always provide 'upgrade' recipes).

And you scenario of pararell development is totally valid, sometimes you can't afford to take the time to develop the entire factory before product developers start working on the product, and these two types of development must happen in pararell, this is just okay. Moreover, this is also a good thing, because factory developers should take feedback from product developers and use that to improve the factory.

Let me know if this answer your questions,

thanks,
-Victor.

Hi,

I guess it boils down to one question: How can I automatically (re)bind my bound recipes.

When the package is being run for the first time, all bound recipes are being set up, upon de/registration this does not happen. This is why the workaround with fresh solutions works.

What I still don't know is, when are the bound recipes being bound, and what triggers will cause this binding?

Regards,
Alexander

Hi,

after having worked with GAT for some time and implemented (and shipped) two non-trivial packages (not me allone of course), I thought I could share my experience with this particular topic:

After Victors feedback ("I recommend you that you stick with unbound recipes only and you should be safe.") we did just that, not knowing however whether this would result in some tradeoffs. After all, bound recipes had a purpose, hadn't they?

It turned out that with reference classes we could solve every demand we had on context aware recipes. Actually in retrospect I would say that this approach is the better one, even if bound recipes had worked without problem. But given those problems (and also in conceptual terms) I now wonder what bound recipes are good for and whether they are needed at all (and should be dropped?).

I hope this may clarify the topic for people not knowing what to do about bound recipes. HIH.

Regards,
Alexander

Hi Alexander,

I'm glad you could work this out and that you have working guidance packages out there, I'm just curious to what they're about! :-)

Bound recipes were meant to be used when you already knew the target element (which doesn't happen with Unbound references where you have to write code to determine this) and also because GAX does some "magic" (auto updating of bound references) that really allowed a reference to be tied to a given item meaning for example if you create a bound reference to a folder named "foo" and then this folder is renamed "bar" by the user GAX will notice this and will keep the bound reference working for "bar".

But then, the persistence model didn't work out that well with bound recipes making them a less interesting choice over unbound ones most of the time.

thanks,
-Victor.