Julian Dominguez Blog

WARNING: This post is obsolete. Please visit the definite fix post here 

If you are using Web Client Software factory in your projects, you probably got an annoying exception that randomly occurs when using the Add View (with Presenter) recipe. The exception is shown below:

Microsoft.Practices.RecipeFramework.ValueProviderException: An exception occurred during the binding of reference or execution of recipe CreateView. Error was: An error happened while calling the value provider or evaluating the default value of argument ModuleInfos..
You can remove the reference to this recipe through the Guidance Package Manager. —> System.ArgumentException: Value Microsoft.Practices.CompositeWeb.Configuration.DependantModuleInfo[] specified for argument ModuleInfos can’t be converted to the argument type Microsoft.Practices.CompositeWeb.Configuration.DependantModuleInfo[].
at Microsoft.Practices.RecipeFramework.Services.DictionaryService.SetValue(Object key, Object value)

After spending a lot of time debugging to find out what the problem was, we (thanks to Matias Woloski for helping me) found a weird behavior. When the Add View (with Presenter) recipe is being executed, .NET is sort of mixing the loaded assemblies available for the guidance package, with those available to the destination solution; in particular Microsoft.Practices.CompositeWeb.dll is being referenced two times during the recipe runtime: one without a public token, because it’s linked directly to the WebClientFactoryPackage in the solution, and one with a public token, which is the one that comes with the Library, and the one that the destination solution references.

Then, depending of the destination solution, it was randomly (well, not random, but without a visible way to know exactly when) trying to receive an argument of a class type that belongs to either of those assemblies (for us it appear to be the same class, but this obviously not the case for .NET). Because this configuration is in XML, and read at runtime, it uses reflection to create an instance of this class).

<Argument Name=”ModuleInfos” Type=”Microsoft.Practices.CompositeWeb.Configuration.DependantModuleInfo[], Microsoft.Practices.CompositeWeb”>        <!– some configuration –></Argument>

What we should do to avoid this conflict, is remove the chance to let .NET randomly decide which assembly to use, and instead pin it to the assembly we know it’s there from the point of view of the Guidance Package: the one with a null public token.

All the technical stuff said, the way to solve this problem is:

Open the CreateWebClientFactoryView.xml file located at “%INSTALL_DIR%\WCSF Guidance Package\Recipes”.

Where it says: 

Type=“Microsoft.Practices.CompositeWeb.Configuration.DependantModuleInfo[], Microsoft.Practices.CompositeWeb”

Replace it with:

Type=“Microsoft.Practices.CompositeWeb.Configuration.DependantModuleInfo[], Microsoft.Practices.CompositeWeb, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null”

And where it says: 

Type=“Microsoft.Practices.CompositeWeb.Configuration.DependantModuleInfo, Microsoft.Practices.CompositeWeb”

Replace it with:

Type=“Microsoft.Practices.CompositeWeb.Configuration.DependantModuleInfo, Microsoft.Practices.CompositeWeb, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null”

Now (re)open Visual Studio, and you should now be able to work with this annoying bug.

Here is a modifed version of the file for your convenience: CreateWebClientFactoryView.xml