Ok, after jumping through many hoops trying to get a recipe to execute dynamically using an IAssetReference, I finally had all the information I needed, and was ready to execute the reference.

I called the execute method on the IAssetReference, and recieved an exception that said I can't execute a new recipe while another recipe is running . I was very disappointed by this, even though I think I probably understand why this is not allowed.

But this leads me to wonder if it is possible to queue up recipes for later execution. The documentation seemed to give me the idea that I could spawn recipe's dynamically, and maybe this strictly means create them dynamically, if so I'm a little disappointed as I have spent quite a bit of time on this.

Please tell me there is a way to actually execute recipe's dynamically.

I basically created a main recipe that was gathering some project specific information that was supposed determine based on the input which recipes to execute on Solution Creation. I even created a base action class called ConditionalAction which executed either a OnTrue() or OnFalse() method depending on the result of a predicate expression which is evaluated using the evaluator service. But if I can't execute a recipe while another recipe is running then all I can do is run actions unless I create my own RecipeQueueingService.

If there is not a way to queue recipe's is their at least a post execution event I can watch for on a recipe, so that I can simulate queueing by delaying execution of a recipe until the post execution operation?

Am I possibly stretching the capabilities of the GAT?

What you're facing is not a limitation in the capabilities of GAT, but a design decision we made. Spawning recipes strictly means that a recipe places a recipe reference on an item that itself may have created, so that the developer can follow up the next step when he think it's necessary (if at all).

Executing a recipe in the middle of another is not a supported scenario. In your case, you should have multiple solution template each associated with different execution paths.

Alternativelly (don't tell anybody ;)), you could just spawn a new thread (i.e. via the ThreadPool), put it to sleep a couple seconds (so that the previous recipe can finish executing), and run at that time. It may work, but it's more of a hack than playing nice with the GAT architecture.

It may help you to think of the guidance you're creating as an automated expression of what the documentation for a product or feature would say. And only then you will realize that there's no documentation that has multiple (or even 1) branching points like "if you whant x, do the following 23 steps, otherwise, do these other 17". Each section in the documentation treats a particular developer use case (what we call a recipe), as a set of (mostly linear) steps that lead to one and only one result. You will never see in the documentation something like: "if you chose option1 you will see the following output, for option2 + suboption 1, the following, etc etc".

If you structure your package following that principle, instead of a template like "Create Cool Solution" that branches, you may end up with "Create Remoting Solution", "Create WSE Solution", "Create InProc Solution", etc.

Makes sense?

What you're facing is not a limitation in the capabilities of GAT, but a design decision we made. Spawning recipes strictly means that a recipe places a recipe reference on an item that itself may have created, so that the developer can follow up the next step when he think it's necessary (if at all).

Executing a recipe in the middle of another is not a supported scenario. In your case, you should have multiple solution template each associated with different execution paths.

Alternativelly (don't tell anybody ;)), you could just spawn a new thread (i.e. via the ThreadPool), put it to sleep a couple seconds (so that the previous recipe can finish executing), and run at that time. It may work, but it's more of a hack than playing nice with the GAT architecture.

It may help you to think of the guidance you're creating as an automated expression of what the documentation for a product or feature would say. And only then you will realize that there's no documentation that has multiple (or even 1) branching points like "if you whant x, do the following 23 steps, otherwise, do these other 17". Each section in the documentation treats a particular developer use case (what we call a recipe), as a set of (mostly linear) steps that lead to one and only one result. You will never see in the documentation something like: "if you chose option1 you will see the following output, for option2 + suboption 1, the following, etc etc".

If you structure your package following that principle, instead of a template like "Create Cool Solution" that branches, you may end up with "Create Remoting Solution", "Create WSE Solution", "Create InProc Solution", etc.

Makes sense?