x64 C# warning – Referenced assembly ‘System.Data.dll’ targets a different processor

Using Visual Studio 2010 C# to compile .NET project for Target Platform x64, the following two warnings appears:

------ Rebuild All started: Project: TestProject-64-bit, Configuration: Debug x64 ------
warning CS1607: Assembly generation -- Referenced assembly 'System.Data.dll' targets a different processor
warning CS1607: Assembly generation -- Referenced assembly 'mscorlib.dll' targets a different processor

Compile complete -- 0 errors, 2 warnings
Manager -> P:\Project Files\TestProject-64-bit\Test-x64.exe
========== Rebuild All: 1 succeeded, 0 failed, 0 skipped ==========

It is a bug in Visual Studio 2010, and warnings can be safely ignored. There are some bugs already filled in MS Connect. Suggestion is:
Edit the project file directly. Replace the references that are having this problem with explicit paths to the 64 bit ones, eg.,:
<Reference Include="$(Windir)\Microsoft.NET\Framework64\v2.0.50727\system.data.dll" />
<Reference Include="$(Windir)\Microsoft.NET\Framework64\v2.0.50727\mscorlib.dll"/>

Great suggestion, but it won’t work if you need to compile / build both for x86 and x64 platforms. And that is what I need.

MSDN Forum post suggests to disable warning:
Parameters Tab - Advanced - MSBuild Arguments, type /p:NoWarn=1607

It seems, that it is for Team Edition, it does not make sense for me, so I use:
Properties - Build - Suppress warnings: 1607

Currently must live with this hack, if you need to target both 32 and 64-bit platforms. Hope the fix will be released so we can remove warning suppression.

2 replies on “x64 C# warning – Referenced assembly ‘System.Data.dll’ targets a different processor”

  1. In the project file, you can define a custom variable in the PropertyGroup section for each build configuration. Just add a tag such as C:\Windows\Microsoft.NET\Framework64 and then use the macro to define the reference path:
    You can define MyCustomPath to a different location for different build configurations (platform and/or debug/release). The problem would not exist if MS would support this in the VS UI, but until then this will work. I use this technique to reference different versions of the same assemblies in my debug & release builds. Works great!

Comments are closed.