Home Dashboard Directory Help
Search

There was a mismatch between the processor architecture of the project being built "MSIL" and the processor architecture of the reference x86 by DEGT


Status: 

Closed
 as Won't Fix Help for as Won't Fix


2
0
Sign in
to vote
Type: Bug
ID: 777587
Opened: 1/26/2013 12:46:44 PM
Access Restriction: Public
0
Workaround(s)
view
1
User(s) can reproduce this bug

Description

I am using Visual Studio Ultimate 2012 SP1/Update 1 under Windows 7 Ultimate 64-bits. I am creating a solution that works with FSUIPC to connect to Microsoft Flight Simulator X.

For that I must use a third party (binary only) .NET library called FSUIPCDotNetClient which is a DLL named "FSUIPCClient.dll" Since MFSS is a 32-bit application the FSUIPCCLient is also a x86 library and so is the underlying FSUIPC.dll (from Peter Dowson).

FSUIPCClient, Version=2.3.4765.4, Culture=neutral, PublicKeyToken=null

For this external assembly (the only one) CORFLAGS.EXE confirms that it is okay (Version: 4.0.30319, CLR HEader: 2.5, CorFlags: 0x3, ILONLY: 1, 32BITREQ: 1, 32BITPREF: 0, PE: PE32)

I was having this issue in another project and couldn't get rid of it. I had the developer of the FSUIPCClient.dll custom build me a version of his library targetting .NET 4.0 and he has it set o x86. I currently have TFS Express 2012 but the problem also surfaced BEFORE I installed TFS 2012,
Details
Sign in to post a comment.
Posted by Microsoft on 4/23/2013 at 6:06 PM
There are several workarounds available to consider. The 1st option to consider is to use Team Build (a feature of Team Foundation Server) to perform your layer validations on check-in (a common practice). The 2nd option to consider is to use the /nowarn compiler flag which can suppress these warnings.
Posted by Microsoft on 4/23/2013 at 6:06 PM
There are several workarounds available to consider. The first option to consider is to use Team Build (a feature of Team Foundation Server) to perform your layer validations on check-in (a common practice). The second option to consider is to use the /nowarn compiler flag which can suppress these warnings.
Posted by Microsoft on 4/23/2013 at 6:05 PM
There are several workarounds available to consider. The first option to consider is to use Team Build (a feature of Team Foundation Server) to perform your layer validations on check-in (a common practice). The second option to consider is to use the /nowarn compiler flag which can suppress these warnings.
Posted by jmandic on 4/10/2013 at 10:11 AM
My team and I have the same compiler warnings. They are all associated with the Modeling Project (and they go away if we choose not to build the Modeling Project). The issue is that we'd like to build the project by default to do layer diagram validation.

Our solution is x86 but the Modeling Project can only be Any CPU. I suspect allowing us to change the target platform on the Modelling Project would make these warnings go away.

We're using VS2010 (Ultimate and Premium) and TFS2010, but we'll be migrating to 2012 for both soon and I see that this issue exists there as well. Please let me know if you'd like further details.
Posted by DEGT on 1/29/2013 at 8:04 AM
As summary (plus extra information). When compiling the entire solution these warnings about processor architecture mismatch are ALL originating at the Modelling project (which is always Any CPU and cannot be set in the Configuration Manager to any other architecture such as x86 (as I must).

Then at RUNTIME a BadImageFormatException is ALWAYS raised by the ServiceHost window indicating it could not load one of the assemblies or its dependencies (related to architecture mismatch). No matter how many WCF applications I make, I always put the server-side services in an assembly/project named MyNamespace.Services.dll and this BadImageFormatException ALWAYS says (RUNTIME) it is MyNamespace.Services.dll.

Now as you can see one of the issues is a compile warning, the other is a runtime exception (but the service executes nevertheless but it is annoying and gives bad image to see such service host exception).

Out of curiosity I examined my MyNamespace.Services.dll (contains my WCF services) with Depends4Net and noticed that it has a bunch of MSIL assemblies (instead of x86), all from the .NET Framework which I presume are dependencies injected by the Windows Service Host. Here is the listing I have attached a partial listing in an image (Depends4Net doesn't export as text)
Posted by Microsoft on 1/28/2013 at 12:59 AM
Thanks for your feedback.

We are rerouting 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.
Posted by DEGT on 1/26/2013 at 1:14 PM
Also noticed that ALL warnings come from the MODELING project which contains no code, just a Layer diagram and a file named ModelingServer.uml that is there but that I can't open and don't know if I can delete it.

The error indicates"
    Project: ModelingAvionics
    File     : Microsoft.Common.targets Line #1578
Posted by Microsoft on 1/26/2013 at 12:51 PM
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)
Sign in to post a workaround.
File Name Submitted By Submitted On File Size  
FSUIPCClient.zip (restricted) 1/26/2013 -
XXX-Depends4Net.jpg 1/29/2013 311 KB