Instead of running FxCop from the command line, we added the following two lines to the <PropertyGroup> section of our project files:

    <CodeAnalysisAdditionalOptions>/directory:"$(ProgramFiles)\Reference Assemblies\Microsoft\Framework\Silverlight\v4.0" /directory:"$(ProgramFiles)\Microsoft SDKs\Silverlight\v4.0\Libraries\Client" /directory:"$(ProgramFiles)\Microsoft SDKs\Silverlight\v5.0\Libraries\Client" /directory:"$(ProgramFiles)\Microsoft SDKs\RIA Services\v1.0\Libraries\Silverlight"</CodeAnalysisAdditionalOptions>
    <CodeAnalysisPlatformPath>$(ProgramFiles)\Reference Assemblies\Microsoft\Framework\Silverlight\v5.0\mscorlib.dll</CodeAnalysisPlatformPath>

Code Analysis now runs within Visual Studio for us. This is similar to one of the comments in the Workarounds tab, except we didn't need to change any shared files.

We are also facing the same issue. I don't see our team running every single time FxCop as a command line (even in the "Build event"), as we have already too many quality tools and rules. Moveover, this would mean changing manually 300 csproj, and test for non regression...

Therefore, we stick so far to SL4, but it presents some other major side effects, such as new components on SL4 does no behave the same way in SL4.
We might just end-up disabling all CA and use third-party tool.

The workaround to use the FxCop command line isn't enough. We have too many build definitions & projects using the integrated code analysis to manually go change the all the build processes. Please reconsider issuing a fix for VS2010.

Closed as fixed? You must be kidding.
This issue is a major showstopper for our upgrade to Silverlight 5 because we are using RIA services client DLLs which are available targeting SL4 only. There is no way we could get them targeted to SL5 and that's why we are getting references to two versions of mscorlib and other DLLs.
We are using the GUI version of FxCop (10.0) and that one does not accept any of the parameters described in earlier posts. And there is no way to set it in the GUI or manually in project file.

@DuffC, this bug is specifically referring to an issue with FxCop which is completely unrelated to the Service Reference proxy generation tool. If you are having issues with that tool, please file a new connect bug for that.

Thanks,
Visual Studio Code Analysis Team

Hello,

We understand that this bug is causing significant difficulties for developers, and after some research there is a way to work around the error by running FxCop from the command line. While not ideal, this will unblock using FxCop in Visual Studio 2010 on Silverlight 5 Business Applications.

A high level walkthrough of how this works from the command line is:
•    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 assemblies.
•    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 Application:
•    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 Libraries Directory>”

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 Files (x86)\Reference Assemblies\Microsoft\Framework\Silverlight\v5.0\mscorlib.dll" /d:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\Silverlight\v4.0" /d:"C:\Program Files (x86)\Microsoft SDKs\Silverlight\v4.0\Libraries\Client" /out:results.xml
•    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.

Best Regards,
Visual Studio Code Analysis Team

I believe the impact of this goes further than code analysis. It's also stopping me using the Service Reference proxy generation tool built into VS2010. I have a DLL that I need to reuse types from, but that DLL references another DLL that references System.Xml version 2.0.5.0. When I try to update my service reference it fails with the following errors:

"Custom tool error: Failed to generate code for the service reference 'Service'. Please check other error and warning messages for details."

"Custom tool warning: Could not load file or assembly 'System.Xml, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e' or one of its dependencies. The system cannot find the file specified."

We need a pre-VS11 workaround for this as it's a huge issue for those of us trying to develop Silverlight 5 apps with VS2010.

As one of the many ISVs who ship Silverlight libraries (PostSharp in our case), I would like to urge you to reconsider your decision to postpone the solution of this issue to Visual Studio 11.

As a result of your decision, customers are turning to ISVs to deliver a new version of products linked to Silverlight 5, even if there is no other technical reason than working around the current issue. I think this is not fair from the Visual Studio team to claim insufficient resources and push the responsibility to other vendors, who have even smaller resources, to implement workarounds.

As the dominant vendor, you have a greater responsibility and, in my opinion, you should assume it.

Thank you for your understanding.

Hello,

Thank you for taking the time to report this. This issue was caused by a versioning decision made by the Silverlight team for the Silverlight 5 runtime. Unfortunately since Silverlight 5 was shipped after the Visual Studio 2010 service pack, we do not have the resources to release an additional fix to Visual Studio 2010 to address this issue at this time. This issue will however be fixed in the RC version of Visual Studio 11.

We apologize for any inconvenience this may cause.

Best Regards,
Visual Studio Code Analysis Team

Dear Moderators, Could someone please shed some light on to what's the status on this issue? We had also been waiting for the last few months like everyone. Thanks a lot in advance!

As mentioned by the other folks, this is stopping us from upgrading to SL 5. It's applicable to all SL 5 projects, not only Business Application Projects. Please get a fix out for this.

Is this being looked into? Has anyone found a workaround for this yet?

Met with the same problem after conversion from SL4 to SL5.
(as one of 3rd-party components we are used created for previous version of silverlight)

Also tried to avoid it by adding <CodeAnalysisPlatformPath>C:\Program Files (x86)\Microsoft Silverlight\5.0.61118.0\</CodeAnalysisPlatformPath> into project file, but it doesn't help.

Like Adil Zaheer and Aquariusquintini, this is also a big blocker for us to adopt Silverlight 5.

Has their been any progression with this issue yet? Like Aquariusquintini it is a big blocker for us to. Stopping us from fully converting to Silverlight 5.

This issue is not only applicable to the Business Application project. We also experienced the same error when converting our existing Silverlight 4 applications to Silverlight 4.
Two kinds of errors were popping up:

Error    1    CA0052 : No targets were selected.

Error    2    CA0055 : Could not unify the platforms (mscorlib, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e, mscorlib, Version=5.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e) for 'MyProject.Silverlight\obj\Debug\MyProject.dll'.

Hopefully a solution to this problem is found quickly, since it is a big blocker for us right now.        

Thank you for reporting the issue.
We are routing this issue to the appropriate group within the Visual Studio Product Team for triage and resolution.These specialized experts will follow-up with your issue.

Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)

As a workaround we modified the file Microsoft.CodeAnalysis.Targets a bit, for our Silverlight projects. Furthermore, we modified the csproj files, so it includes the customized CodeAnalysis targets. The customized target file (Microsoft.CodeAnalysis.Customized.Targets) has been attached to this bug.

What was changed from the original?
* Within the Target element (line 144-146) we added an additional option for codeanalysis:
        <PropertyGroup>
         <CodeAnalysisAdditionalOptions>/directory:"$(ProgramFiles)\Reference Assemblies\Microsoft\Framework\Silverlight\v4.0"</CodeAnalysisAdditionalOptions>
        </PropertyGroup>
* On line 171: Override of the platform path, like this:
         PlatformPath="$(ProgramFiles)\Reference Assemblies\Microsoft\Framework\Silverlight\v5.0\mscorlib.dll"

* And in the .csproj add the following line:
<Import Project="c:\[PathToDir]\Microsoft.CodeAnalysis.Customized.Targets" />

This solution has worked for us, it is far from optimal, since we have to modify all our Silverlight projects, so we still waiting for the definitive fix from Microsoft. However, with this workaround we hope that people can continue to work on their SL5 projects in the meantime.

This problem only exists when you are mixing versions. The work around is to make sure ALL of the references you are using in the SL 5 application are built against SL 5. This includes any in-house assemblies as well as third-party libraries.

Since most third-party control suite developers are only now beginning to release libraries built against SL 5, the temporary solution is to disable Code Analysis. However, as soon as you have all of the assemblies running against SL 5, you may re-enable.

(Btw, the reason this error occurs is because the assemblies built against SL 4 are compiled with internal references to the 2.0.5.0 versions of the framework assemblies.)