"Targets a different processor than the application" warning, issues with "Publish"

[dpstark]

Hello,

I've run into this problem for a while now, and it's finally really become an issue. Here are the steps I took to isolate and recreate the problem in a separate, simple project. I have Visual Studio 2012 and Measurement Studio 2012.

I created a new C# windows form application and dropped a waveform graph and a meter on it and compiled it. Then I changed the configuration to x64. When I first compiled it, all was well. Then I tried to "publish" the application. I told the publish utility to include all the NI dll's that it needs, which it correctly identified. Shortly after this, I got the following warning: 

Warning 1 Referenced assembly 'C:\Program Files (x86)\National

Instruments\MeasurementStudioVS2010\DotNET\Assemblies\Current\NationalInstruments.UI.Styles3D.dll' targets a different processor than the application. C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets 3075 5 NITest

After a clean and rebuild, I got a second warning:

Warning 2 Referenced assembly 'C:\Windows\Microsoft.Net\assembly\GAC_64\NationalInstruments.Common.Native\v4.0_12.0.40.253__dc6ad606294fc298\NationalInstruments.Common.Native.dll' targets a different processor than the application. C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets 3075 5 NITest

A few minutes later, after going to "Release," the second error disappeared. I literally did nothing else. 

Now, on their own- I could really care less. The program runs fine because the run time finds the right libraries. However, the "publish" function also finds the wrong versions (32-bit DLLs) and then the program doesn't run.

This has really become an issue because I can't "publish" my actual application under x64- and yes, I do need x64 in my actual application. I've searched around for days and not seen exactly this situation, so I'm hoping someone can help. I am attaching my build log in the hopes someone can explain it.

Not to complicate things too much, but I can add that for some reason, the default references you get when you add an NI control to the form use NationalInstruments.Common 12.0.40.253 instead of 258. And for some reason, some DLLs are found in the GAC, some are not. Those that are not found in the GAC never seem to search the non-GAC 64-bit folders. I have tried forcing version 258 in the project file and listing all the references explicitly- this works, until the setup utility runs- it then pukes on not finding version 253 to install. I've also forced the architecture to x64 in the project file, but this breaks the 32-bit version.

Am I missing something? This all started with compiling for x64. Any help would be appreciated.

Thanks,

Doug

[Daniel-E]

Hey Doug,

I've been looking into this issue, and it looks like it might be an issue with Visual Studio itself--generally, it seems to happen when the target CPU in the Project Properties is set to Any CPU. More specifically, the issue seems to be related to using 32-bit DLLs on a 64-bit build, and looking at your Warning 1, it looks like it is referencing the 32-bit version of that DLL (notice the x86 in the file path). It might be necessary to change the references to explicitly include the 64-bit DLLs. Here's a listing of the NI DLLs that support 64-bit: http://zone.ni.com/reference/en-XX/help/372636F-01/mstudiowebhelp/html/64bitsupport/   That link also contains some information about how to include the 64-bit assemblies in your application.

Another possible contributing factor is compatibility between Visual Studio 2012 and Measurement Studio 2012--currently, Visual Studio 2012 is not officially supported, and here is a collection of some known issues with it: http://forums.ni.com/t5/Measurement-Studio-for-NET/Visual-Studio-2012-Support/td-p/2125480

Do you have access to a copy of Visual Studio 2010 that you could try? Another possible troubleshooting step would be to make a completely separate project for the x64 version. It could reference the same source files, but would include references to the 64-bit DLLs instead of the 32-bit ones.

I hope this helps a bit, and please let us know if you need any more assistance with this issue.

[dpstark]

Thank you for the reply. I really appreciate the information. However, I don't know that it addresses the issue. In the project, the CPU type is set to x64. I know that the build process finds the x86/AnyCPU DLLs- my question is why this happens. The default references in the project include NationalInstruments.Common and .UI.Windows as MSIL architecture, and .UI as no architecture. Removing the archictecture reference doesn't help, and forcing it to x64 breaks the 32-bit build. There are no other separate DLLs referenced other than the defaults provided by Microsoft. Without MeasurementStudio, everything works fine- although that's hardly a solution.

I understand there may be incompatibilities between VS2012 and MS2012, and if that's the answer, then I guess I need to find a workaround for the time being- assuming someone can assure this will be addressed in the next cycle. Unfortunately, I cannot go back to VS2010 because only 2012 is officially supported and licensed in my workplace. 

I have implemented a rather convoluted workaround that may help someone, so here it is. I hope someone can comment on whether this is a good approach or not. 

I added a custom variable to my project file under each configuration that points to either the 64-bit directory or the other:

<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Release|x64'">
<OutputPath>bin\x64\Release\</OutputPath>
<DefineConstants>TRACE</DefineConstants>
<Optimize>true</Optimize>
<DebugType>pdbonly</DebugType>
<PlatformTarget>x64</PlatformTarget>
<ErrorReport>prompt</ErrorReport>
<CodeAnalysisRuleSet>MinimumRecommendedRules.ruleset</CodeAnalysisRuleSet>
<Prefer32Bit>true</Prefer32Bit>
<NIPath>C:\Program Files (x86)\National Instruments\MeasurementStudioVS2010\DotNET\Assemblies (64-bit)\Current</NIPath>
</PropertyGroup>

... or ...

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
<PlatformTarget>AnyCPU</PlatformTarget>
<DebugType>pdbonly</DebugType>
<Optimize>true</Optimize>
<OutputPath>bin\Release\</OutputPath>
<DefineConstants>TRACE</DefineConstants>
<ErrorReport>prompt</ErrorReport>
<WarningLevel>4</WarningLevel>
<NIPath>C:\Program Files (x86)\National Instruments\MeasurementStudioVS2010\DotNET\Assemblies\Current</NIPath>
</PropertyGroup>

Then I added <HintPath> to each reference and explicitly referenced all the dlls. For example:

<Reference Include="NationalInstruments.Common, Version=12.0.40.253, Culture=neutral, PublicKeyToken=dc6ad606294fc298">
<SpecificVersion>False</SpecificVersion>
<HintPath>$(NIPath)\NationalInstruments.Common.dll</HintPath>
</Reference>

This forces the build process to check the $(NIPath) before any others. In the case of x64 builds, it resolves to x64 DLLs. x86 also works, but AnyCPU still generates warnings because it finds x86 DLLs (as appropriate) instead of MSIL DLLs. This behavior is correct, but it still generates warnings that can be ignored.

I also added binding redirections from the policy files to the app.config file:

<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="NationalInstruments.Common" publicKeyToken="dc6ad606294fc298"
culture="neutral" />

...
<bindingRedirect oldVersion="12.0.40.100-12.0.40.257"
newVersion="12.0.40.258" />
</dependentAssembly>

...

</dependentAssembly>
</assemblyBinding>
</runtime>

This procedure correctly identifies and packages the DLLs required for publishing in either configuration. However, I am still having issues with installing the program that I can't identify. NationalInstruments.UI seems to throw a "FileNotFoundException" on the target machine (not my development machine) and the program exits. I'm attaching the source as it is for anyone to try.

Thanks again,
Doug

[dpstark]

The "FileNotFound" issue is unrelated- the test computer did not have the right run time libraries installed. The approach I took seems to have worked, even if it's not very simple.

[Daniel-E]

Doug,

It seems that your solution is one workaround to fix the problem--another thought would be to create separate projects for the 32 and 64-bit builds. Either option should resolve your build issues.

We generally see this happen when a project set as AnyCPU is built on a 32-bit machine--in that case, Visual Studio will generally include the 32-bit version of the DLLs, which causes problems on an x64 machine.

I'm glad you found a way to get things working! Let us know if you need any more assistance.