Recipe Framework Error

Topics: CAB & Smart Client Software Factory
May 8, 2007 at 9:58 PM
Our company has decided to use SCSF but wants to adhere to our own naming conventions for namespaces and such. As a result they want the Infrastructure project namespaces changed to something like OurCompany.GroupName.SmartClient.Infrastructure... with all the default projects from SCSF under here such as Interfaces, Modules, Library and Shell.

This works fine when I manually change the namespaces for existing code but now I face the problem of having the recipe framework fail when adding a new business module.

I get the following error:

Microsoft.Practices.RecipeFramework.ValueProviderException: An exception occurred during the binding of reference or execution of recipe CreateBusinessModule. Error was: An error happened while calling the value provider or evaluating the default value of argument ShellProject..
You can remove the reference to this recipe through the Guidance Package Manager. ---> System.NullReferenceException: Object reference not set to an instance of an object.
at Microsoft.Practices.GuidanceAutomation.SmartClient.ValueProviders.GetProjectFromGuidProvider.OnBeginRecipe(Object currentValue, Object& newValue) in c:\Dev\scbat\GuidanceAutomation\SmartClientDevelopment\ValueProviders\GetProjectFromGuidProvider.cs:line 37
at Microsoft.Practices.RecipeFramework.Recipe.CallProviders(IDictionary providers, IDictionaryService readonlyArguments, IDictionaryService arguments, Boolean isBefore)
--- End of inner exception stack trace ---
at Microsoft.Practices.RecipeFramework.Recipe.CallProviders(IDictionary providers, IDictionaryService readonlyArguments, IDictionaryService arguments, Boolean isBefore)
at Microsoft.Practices.RecipeFramework.Recipe.Execute(Boolean allowSuspend)
at Microsoft.Practices.RecipeFramework.GuidancePackage.Execute(String recipe, IAssetReference reference, IDictionary arguments)
at Microsoft.Practices.RecipeFramework.GuidancePackage.ExecuteFromTemplate(String recipe, IDictionary arguments)
at Microsoft.Practices.RecipeFramework.VisualStudio.Templates.UnfoldTemplate.ExecuteRecipe(Boolean executeActions)
at Microsoft.Practices.RecipeFramework.VisualStudio.Templates.UnfoldTemplate.RunStarted(Object automationObject, Dictionary`2 replacementsDictionary, WizardRunKind runKind, Object[] customParams)

Any pointers on what I would have to do to make our nameing policies work correctly? Also - will I run into other problems here for recipes besides business modules?

Any pointers on how to solve these problems would be greatly appreciated. I am a bit new to SCSF so bear with me.

May 9, 2007 at 4:09 PM
If you've changed the name of the output assembly of Infrasture.Interface then most recipes will break or vanish. Just rename the output for the assembly, rebuild, and you should be able to run your recipe. The namespaces are not relevant but the name of the assembly the project outputs is.
May 29, 2007 at 5:02 PM
Is there a work around for this? Preferably not touching Guidance Package solution source? May be a configuration change?
Oct 1, 2007 at 4:24 PM
Edited Oct 1, 2007 at 4:28 PM
Yes, there is a work around we've stumbled upon. It appears the SCSF looks at what project is declared as the "Common" project inside the solution's meta data and then looks to see if that project's project name and output assembly name match. If they match, the recipes will show themselves and operate. If not, they disappear. For example, by default SCSF designates the Infrastructure.Interface as the common project thus both its project name and assembly name must match.

To work around this you can do one of the following which we've found workable:
  • Rename the Infrastructure.Interface project name to match the output assembly name. For example, CompanyName.GroupName.SmartClientFramework.Infrastructure.Interface would be both the project name and assembly name. The draw back to this is you alter the SCSF project names and you'll probably want to rename all the infrastructure projects to match the newly named Infrastructure.Interface project. This makes for a lot of projects with extremely long names.
  • Or create a new, empty project which all projects will reference for recipe dependencies and change the solution's "Common" project. The benefit of having a separate project is you do not have to alter the SCSF project name and since this new project will not be for development purposes, you can place it in it's own solution folder, separate from all other projects. The new project's name would be something like CompanyName.GroupName.SmartClientFramework.Recipes with the output assembly of the same name. Then within the solution metadata under the ExtensibilitySection, change the CommonProjectGuid value to match the guid of the newly added recipe dependency project. Now you can change all the Infrastructure.XXXX project's output assembly names to the naming convention your company wishes to use, without losing recipe access and without changing the project's name. Be sure and reference the new recipe project in all projects that need recipe use.