This connect bug describes an issue with creating certain types
of Silverlight projects in Visual Studio. If you're referencing
Silverlight 4 DLLs from a Silverlight 5 project, you may run into
code analysis/FXCop issue yourself if code analysis is part of
your process. The core of the problem is a versioning decision in
Silverlight 5 which results in compile-time violation due to
loading two different versions of mscorlib in the same project. It
manifests as the following error:
- Error 2 CA0055 : Could not unify the platforms (mscorlib,
Version=188.8.131.52, Culture=neutral, PublicKeyToken=7cec85d7bea7798e,
mscorlib, Version=184.108.40.206, Culture=neutral,
on CA0055 may be found on MSDN.
How to Reproduce the Issue … in theory
In theory, all you need to do to reproduce the issue is
reference a SL4-targeted DLL from an SL5 application. However, in
practice, there are other factors in play. For example, it may
matter which mscorlib version gets loaded first.
These steps won't repro the problem on my installation,
but I'm putting them out here in case they help you visualize the
issue (and also because I had already written them up when I
realized they don't repro here -- I don't want all these bits to go
Create a Silverlight 4 class library. Make sure you target
Silverlight 4. I named mine SL4ClassLibrary. The actual code is
unimportant, but I set it to the following:
public class Class1
public string Foo = "Bar";
Next, add a Silverlight 5 Application project. Make sure it
targets Silverlight 5. Here's what my solution looks like:
Build the solution.
Next, add a File Reference (not a project reference) from the
Silverlight 5 client app to the Silverlight 4 DLL.
If you build it now, everything works fine. The key step here is
to add code analysis. Many organizations have code analysis as a
required part of their build process, using the compiler
command-line arguments. If you don't, you can turn it on via the
Then check the "Enable Code Analysis on Build" checkbox.
Now build the solution. In theory, you'll get a CA0055 error,
but as I mentioned at the top, that doesn't happen on my install.
Most of the people who have reported this issue on the connect bug
have mentioned it in the context of the Business Application
Template or third party controls.
Remember, this is a code analysis compile/build issue,
not a runtime issue, so if you get past compiling your application,
This is already planned to be fixed in Visual Studio 11 RC.
However, we do have a manual workaround for this to help you
continue working if you're running into this scenario today. This
will unblock using FxCop in Visual Studio 2010.
A high level walkthrough of how this works from the command line
- We will tell FxCop which version of the runtime it will be
using by pointing it to Silverlight 5's installed mscorlib.dll
using the /platform argument
- Tell FxCop where to find all of the referenced assemblies using
/d (short for /directory) arguments: Use as many /d:<folder>
arguments as necessary for FxCop to find all of the referenced
- Use either /console to tell FxCop to output the results to the
console window, or /out:<file> to tell FxCop to write the
results to an .xml file
To run FxCop from the command line for a default Business
- Add the %Visual Studio Install Directory%\Team Tools\Static
Analysis\FxCop folder to PATH
- Run "fxcopcmd.exe /file:<SL Business Application binary>
/platform:<SL5 Reference Assemblies Directory\mscorlib.dll>
/d:<SL4 Reference Assemblies Directory> /d:<SL4 SDK Client
An example of what this looks like on an x64 operating system
with all of the default install directories is:
- SET PATH=%PATH%;C:\Program Files (x86)\Microsoft Visual Studio
10.0\Team Tools\Static Analysis Tools\FxCop
- fxcopcmd /file:BusinessApplication1.dll /platform:"C:\Program
/d:"C:\Program Files (x86)\Reference
Files (x86)\Microsoft SDKs\Silverlight\v4.0\Libraries\Client"
- NOTE: If you receive a CA0001 error: "The following error was
encountered while reading module 'XXXX.YYYYY' : Assembly reference
cannot be resolved…" this means that you need to find where that
assembly is installed to on your machine and add an additional
/d:<installed directory> argument pointing FxCop to where
those assemblies are installed.
My thanks to the Silverlight Team and to Andrew Hall for the
information on this workaround.
Of course, the easiest and best solution, if you can do it, is
to use libraries that specifically target Silverlight 5, and make
sure all references from your Silverlight 5 project are to
libraries targeting Silverlight 5. We know that's not
possible in all cases, including the specific reported business
application case, which is why we documented this workaround.