We Keep Coding

Xamarin processor architecture build error

I updated my VS 2015 recently with the latest patch version and since then I get this error:
There was a mismatch between the processor architecture of the project being built "MSIL" and the processor architecture of the reference "C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\mscorlib.dll", "x86". This mismatch may cause runtime failures. Please consider changing the targeted processor architecture of your project through the Configuration Manager so as to align the processor architectures between your project and references, or take a dependency on references with a processor architecture that matches the targeted processor architecture of your project.
Output:
Restoring NuGet packages...
To prevent NuGet from restoring packages during build, open the Visual Studio Options dialog, click on the Package Manager node and uncheck 'Allow NuGet to download missing packages during build.'
1>------ Rebuild All started: Project: MoneyFox.Shared, Configuration: Debug Any CPU ------
1>C:\Users\nino\Documents\GitHub\MoneyFox.Windows\Src\MoneyFox.Shared\MoneyFox.Shared.csproj(333,3): warning MSB4011: "C:\Users\nino\Documents\GitHub\MoneyFox.Windows\Src\packages\Fody.1.29.4\build\portable-net+sl+win+wpa+wp\Fody.targets" cannot be imported again. It was already imported at "C:\Users\nino\Documents\GitHub\MoneyFox.Windows\Src\MoneyFox.Shared\MoneyFox.Shared.csproj (325,3)". This is most likely a build authoring error. This subsequent import will be ignored.
1>C:\Program Files (x86)\MSBuild\14.0\bin\Microsoft.Common.CurrentVersion.targets(1820,5): error MSB3270: There was a mismatch between the processor architecture of the project being built "MSIL" and the processor architecture of the reference "C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\\mscorlib.dll", "x86". This mismatch may cause runtime failures. Please consider changing the targeted processor architecture of your project through the Configuration Manager so as to align the processor architectures between your project and references, or take a dependency on references with a processor architecture that matches the targeted processor architecture of your project.
========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ==========
The only other entry is a warning who should be the reason.
Strange is, that the project who the error occurs doesn't have the mscorlib referenced.
The error occurs in the PCL Shared Library part who is referenced by the platform specific projects. Therefore these can't build aswell.
My current build configuration is as follows:
The shared project in special:
Repository: https://github.com/NPadrutt/MoneyFox.Windows/tree/AndroidBackgroundService
I tried to repair vs but that didn't change something, as does reinstall it completly.
Funny is, that I can build it on a windows 7 pc (but get runtime error instead).
Also I can't build my master branch anymore who was buildable some days ago.
What's wrong here!?
EDIT: I created a new portable class library and unloaded all other projects.. I get the same error, also when I create a new project with just a portable class library in it. So it seems there is something pretty wrong with my current installation...

I found a solution for the problem. It seems that some of the .net profile got corrupt. But they didn't get repaired with a reinstall or repair of VS. So, therefore I deleted the Files and folders under the path C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETPortable
Then I repaired VS and it worked again..

I wouldn't think that this has to do with applying the latest patch to Visual Studio 2015.
We see this warning when we have one project that is built for x86 referencing another build for AnyCPU. This can be fixed in the Project Property page (right-click the project and click Properties). In the Build tap you can set Platform target. I would suggest that you set the configuration combo box in the top of the property window to All configurations before updating this to get it set consistently.
You can also correct this by unloading the project and editing it manually. Look for the AnyCPU property and insure that it is set in a property group without conditions or in all property groups for each configuration condition.
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
<PlatformTarget>AnyCPU</PlatformTarget>
<OutputPath>bin\Debug\</OutputPath>
...
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
<PlatformTarget>AnyCPU</PlatformTarget>
<OutputPath>bin\Release\</OutputPath>
...
</PropertyGroup>

Visual Studio 2015 build class library portable error

I am rebuilding a class library (portable).
The Library --> Targeting is set to:
The errors list shows in the first position:
Severity Code Description Project File Line
Error CS0234
The type or namespace name 'Linq' does not exist in the namespace 'System' (are you missing an assembly reference?)
If a do a rebuild I get the error:
Severity Code Description Project File Line
Error There was a mismatch between the processor architecture of the project being built "MSIL" and the processor architecture of the reference "C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\mscorlib.dll", "x86". This mismatch may cause runtime failures. Please consider changing the targeted processor architecture of your project through the Configuration Manager so as to align the processor architectures between your project and references, or take a dependency on references with a processor architecture that matches the targeted processor architecture of your project.
NOTE If I change the targeting (but I don't want to do it, only for test!)
to NET Framework 4.0.3 the errors go away and all rebuilds fine!
I have tried to Clean/Rebuild the whole solution, close/reopen VS, restart Windows...
Yesterday I have updated all the VS2015 Extensions and Updates, that has updated also a lot things (Azure, VS restarted, ecc...)
The using statements:
Question:
1) What could have happened that has corrupted my VS installation?
2) What test could I do?
EDIT
In the file system, under *c:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETPortable*
I have these folders:
v4.0\
v4.5\
v4.6\
v5.0\
The project is a Class library that essentially contains .resx and only one .cs file.
All the .resx files shows errors, if I click on one of them I get:
Could not resolve mscorlib for target framework
'.NETPortable,Version=v4.0,Profile=Profile328'. This can happen if
the target framework is not installed or if the framework moniker is
incorrectly formatted.
EDIT2
In Configuration Manager if I set target to x86
the error mismatch goes aways
BUT
the other errors remains:
essentially that seems that
using System.--> points to a different location ??!!
Before System.Linq was found.
If I change Targeting-->Net 4.0.3 System.Linq is found
If I change Targeting-->Net 4.0 System.Linq is missing!
Where the hell is VS searching this System.Linq?

Question: 1) What could have happened that has corrupted my VS
installation?
Yesterday I have updated all the VS2015 Extensions and Updates, that has updated also a lot things (Azure, VS restarted, ecc...)
As you stated you have applied updates. This has somehow caused an assembly conflict . Based on the error message it appears you are trying to build a x64bit or any cpu configuration build and it is throwing an error . Try changing your build to target x86.
If it compiles as x86 then this means you have no choice in the matter unless you find the dependent x86 assemblies and compile it separately or update the code to 64 bit. Otherwise there is nothing you can do to run your process x64 and any cpu even if management says it's got to be. A 64 bit processor can run both 32 and 64. A 32 bit processor can run only 32 natively.
2) What test could I do?
The first thing you can do is a diff of your local workspace and what is in source control. Hopefully you are using source control and do not check in broken builds. See what has changed if anything. Possibly rollback .
If no code has changed from source then have a peer try and build it.
You could uncheck all targets in your picture and compile your solution. Adding back the targets after getting a successful build and narrowing down the target that is the root problem.
If all else falls uninstall your updates or restore your PC from a last know restore point.
When updating references it is always good to test and makes sure nothing breaks.

XNA reference error, changed workspace and can't run

Me and a couple of my friends were on an army network when we wrote the game (XNA 4.0 for VS10 32bit PCs),
and now we got it and it gives some error when we try to run the XNA part.
I try to run the server, whose main consists of Initialization of the server class and the start method.
The program throws a BadImageTypeException on the ctor of the server class instance initialization.
Since my windows is not in english I can't really give you the exception in gives but I do have a warning that says:
"Warning 1 There was a mismatch between the processor architecture of the project being built "MSIL" and the processor architecture of the reference "Microsoft.Xna.Framework, Version=4.0.0.0, Culture=neutral, PublicKeyToken=842cf8be1de50553, processorArchitecture=x86", "x86". This mismatch may cause runtime failures. Please consider changing the targeted processor architecture of your project through the Configuration Manager so as to align the processor architectures between your project and references, or take a dependency on references with a processor architecture that matches the targeted processor architecture of your project. Game_Of_Throws_Server"
Kinda been waiting for a long time for the game to go WWW and we wanna keep working on it,
but this is a small but annoying problem that keeps us from continuing the development of the game.
Tried removing the assembly reference from the assemblies list and adding it again (The Microsot.XNA.Framework reference) but it didn't change a thing. Windows is Win7 64bit, VS is VS13Community version.
If anyone would like to skype or something of that sort to see the problem more clearely, send me a pm.

You'll get errors like that if the assembly you reference has a different target platform to the assembly referencing it e.g. You have an 'Any CPU' project referencing an 'x86' assembly. Are you certain that the 'Platform target' setting of the project producing this error really is set to x86?
If you're referencing the x86 version of Microsoft.Xna.Framework, you should change the project referencing it to also be x86. If an x64 version of Microsoft.Xna.Framework is also available, you can get creative with your csproj file to ensure the right one is pulled in based on the build you're doing (native Visual Studio support for switching references based on the target platform of the build is not good).

Warnings MSB3270 architecture mismatch / AL1073 targets a different processor

I have projects with localized resources and x64 native dependencies. Is there any way to build them without warnings?
If I set the target platform to AnyCPU I get this warning because of the native references:
warning MSB3270: There was a mismatch between the processor architecture of the project being built "MSIL" and the processor architecture of the reference "Native64", "AMD64". This mismatch may cause runtime failures. Please consider changing the targeted processor architecture of your project through the Configuration Manager so as to align the processor architectures between your project and references, or take a dependency on references with a processor architecture that matches the targeted processor architecture of your project.
OK fair enough, but:
If I set the target platform to x64 I get this warning, because localized resources automatically create a satellite assembly with the wrong target architecture:
ALINK : warning AL1073: Referenced assembly 'mscorlib.dll' targets a different processor
Microsoft says it's a bug, but they wont fix it.
So now what?

Here is a workaround:
The issue can be avoided by using the AL.EXE that matches the platform (or bitness) you are attempting to build. That is, you'll see that when you are building x64, that it is trying to use AL.EXE at a path similar to
C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6 Tools
If you can get it to use the x64 version of AL.exe, the issue will go away. That is, use the AL.EXE at a path similar to:
C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6 Tools\x64
Msbuild finds this path by using its TargetFrameworkSDKToolsDirectory. Thus, using the assumption that this directory is the correct directory when building x86, the workaround below essentially appends the x64 sub directory on to the path when building x64 and leaves it as is otherwise:
Create an MsBuildAL1073WarningWorkaround.targets file (name doesn't matter) and add it to the project. It has the following contents:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<TargetFrameworkSDKToolsDirectory Condition=" '$(PlatformTarget)' == 'x64'">$(TargetFrameworkSDKToolsDirectory)$(PlatformTarget)\</TargetFrameworkSDKToolsDirectory>
</PropertyGroup>
</Project>
Edit the .csproj file to import this file near the end of the file (where you'll see the comment that says "To modify your build process...":
<Import Project="MsBuildAL1073WarningWorkaround.targets" />
<!-- To modify your build process... -->

Visual Studio 2012 adds reference to wrong DLL

I was having trouble getting Visual Studio to build my project in release mode... it gives me errors about assemblies being the wrong format. Turns out some x86 assemblies were being referenced instead of x64 assemblies. Assemblies like PresentationCore, System.Data and so on.
Things I've tried:
Debug mode, any CPU builds fine.
Debug mode, x64 builds fine.
Release mode, any CPU fails
Release mode, x64 fails (this is the combination I'd LIKE to build my project in)
The issue comes when I try to remove the x86 reference and switch it to a x64 reference. Visual studio just adds the old x86 reference instead of the x64 reference. For example:
I remove the System.Data reference which is in C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Data.dll
I browse to and add C:\Windows\Microsoft.NET\Framework64\v2.0.50727\System.Data.dll, but when I click on that System.Data reference, the path is CLEARLY still to the old dll and causes the same error to occur. This is happening with several other DLLs as well.
Does anyone know of a solution to this issue?

Assemblies like PresentationCore, System.Data and so on.
I hate to answer a question without seeing the error message. But this secondary evidence is enough to answer the question. First off, this is not an error, it is a warning. It looks like this:
warning CS1607: Assembly generation -- Referenced assembly 'System.Data.dll' targets a different processor
You'll also see one for mscorlib.dll. And PresentationCore.dll in a WPF project. What goes on here is that these assemblies are special, they are mixed-mode assemblies. In other words, they contain both native code and managed code. The native code is the trouble-maker, such an assembly can only be used in a project that targets the right processor flavor. If you mix it up then you get a BadImageFormatException at runtime.
This is not a real problem with .NET assemblies, your machine actually has two versions of these DLLs stored in the GAC. One that will be used if your program runs in 32-bit mode and another that is used in 64-bit mode. The CLR automatically picks the right one.
However, there is only one version of the reference assembly, the one that's stored in c:\windows\microsoft.net and that you pass to the compiler to read the metadata from. It is always the x86 version, there's no other one so don't bother looking for it. Again, this is not a problem, only the metadata of a reference assembly is used by the compiler, it doesn't execute any of its code. And the metadata does not depend on the bit-ness of the assembly.
Nevertheless, this all might be a problem if you create your own mixed-mode assembly. You can easily overlook the need to provide two versions. So what the compiler is fretting about is that it sees that you asked for an AnyCPU or x64 build of your project. But detects that the reference assembly can only work when you target x86. So it squeaks at you a bit, just a gentle reminder that there's some evidence that you're getting it wrong and that your program might fall over on a BadImageFormatException when you run it. It doesn't otherwise treat a framework reference assembly any different from your own reference assembly.
So, feature, not a bug. Just a warning that doesn't otherwise prevents your program from building. You can safely ignore the warning since you know that .NET has the right assembly available in the GAC at runtime. Notable is that .NET 4.0 doesn't have this problem, it uses very different reference assemblies that don't have the ILONLY metadata flag turned off.

Odd behavior. Turning "Generate serialization assembly" off under Build in project properties makes the project build just fine in release mode. Looking at this link reveals that this setting has to do with XML Serialization, which we don't even use in our entire solution.
Very weird. Still looking for an explanation for this question and behavior here.

Check out what your build configuration looks like. Sometimes this error happens because certain project on a solution is configured to be built in one build configuration, and not in another.
To do this:
Go to "Compile > Configuration administration..."
On "Active solutions configuration" select "Release" which is the configuration that is giving you problems.
On "Platform of active solutions" check "Any CPU". If "x64" is defined, you might be able to choose it too.
Look at the list of build projects. All projects needed for the solution must be marked with the correct values in "Configuration", "Platform" and have a "Compile" check.
In my case I have a sandcastle project that I uncheck most of the times, at least in debug mode, because it takes ages to compile. Sometimes it happens that one project does not have a configuration for the "Release" configuration and thus, when the build process tries to get its results, these don't exists (there is no DLL) and it throws an exception. In other situations, it might be that a project is forced to compile for x86 (or x64) and the rest is not, and so an error is thrown when trying to link other referencing projects to the proper version of the referenced DLLs.

Which version of .NET are you compiling for? If you can change the project to a later version of the .NET framework, that might help.

My VS2010 web project was generating these warnings too, and IIS was throwing a BadImageException. The Build/Configuration/Platform settings looked ok, but the Output window was showing that the dll was built in x64 folder for Any CPU configuration. Deleted all folders under bin and rebuilt. The warnings were gone and the BadImageException was gone.