We Keep Coding

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.

FileNotFoundException - Could not load file or assembly 'System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'

I'm starting to work with the Windows Phone 8.1 SDK. I want to use it in conjunction with an external C# library (mtgdb.info). I installed mtgdb.info to my solution using the package manager and added appropriate using statements when I called methods from the library.
The solution builds without errors or warnings, but when I try to debug the code I get the error listed in the title on the first line that calls a method in the external library. Installing the mtgdb.info nuget package is the first change I've made to the solution after creating it.
The mtgdb.info.dll is referenced in every project of my solution as well as its dependent dll (newtonsoft.json)
Any thoughts on why the solution wouldn't be able to find the assembly at runtime? Are there any good resources on how assemblies are located for Windows Phone applications?

most of the time, this problem appears on x64 machines.
Go to Properties in your project, then go on "Build".
I Guess "platform target' is set on "Any CPU"
try to put x86 and see if you still have the problem.
Reason is that, when you let "any CPU" on a x64 machine, Runtime will try to find the x64 release of the dll
But if the dll has been compiled for x86 only, Runtime don't find it.
EDIT : my bad, i didn't saw first that it was regarding System assembly. Did you install Framework 4.5 ? if not do it, or In :
project => properties => Application => Target Framework : change to a lower value. Anyway i'm surprise you get that error !
PS : With "System" assembly, you can keep "ANY CPU", Microsoft compiled it for 64 & 86 machines of course ;)

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.

Could not load assembly error when changing to x64 platform

I have just created a new asp.net 3.5 web application. I went to the application property and changed the platform target to x64. I didn't write any code and i have not changed anything. Next i hit start debugging in Visual Studio. The following error occured:
Could not load file or assembly
"SOLUTION NAME", Version=1.0.0.0,
Culture=neutral, PublicKeyToken=null'
or one of its dependencies. An attempt
was made to load a program with an
incorrect format.
Any one have an idea how to solve this?
Thanks.
Edit:
I have these warnings:
Warning 1 Assembly generation --
Referenced assembly
'System.EnterpriseServices.dll'
targets a different processor
Warning 2 Assembly generation --
Referenced assembly 'mscorlib.dll'
targets a different processor
Warning 3 Assembly generation --
Referenced assembly 'System.Web.dll'
targets a different processor
Warning 4 Assembly generation --
Referenced assembly 'System.Data.dll'
targets a different processor
Configuration manager:

If you start your app just using F5 or Start button, and you debug on IIS, could be this:
Debug -> Options -> Projects and Solutions -> Web Projects. And select "Use the 64 bit version of IIS Express for web sites and projects".

I have found the problem.
It seems that Visual Studio and Cassini run as 32-bit applications. If i try to host my 64-bit ASP.NET application using Microsoft's Cassini, i will get an exception.
So i deployed my solution on IIS, changed it to 64-bit, debugged it and every thing is working perfectly.

Its likely to be a 32bit dll that is referenced.
If you are debugging on IIS, open the advanced settings of the application pool and make sure 'Enable 32 Bit Applications' is enabled. That has sorted the issue for a number of times.

In addition on what #winSharp93 says, have a look at the Application Pool Advanced Settings and ensure "Enable 32 Bit applications" is set to false.

Ensure that all dlls you compile are for 'any cpu' or are compiled for 'x64'. You can find this on the project settings window for each project.

Please check your references in the solution.Probably that is pointing to the old dlls.

VisualStudio C# x64, why AddReference option, .NET tab points to x86 DLL instead of x64?

I want to create an x64 application.
When I want to add a reference for example to system.data in window AddReference under tab .NET I see only x86 DLLs, and I need 64 bit versions.
I have Windows Server 2008 x64 with Visual Studio 2008.
I created a project and I set x64 under Configuration Manager.
What can I do to force Visual Studio to point to the
correct DLLs (from C:\WINDOWS\Microsoft.NET\Framework64 instead
of C:\WINDOWS\Microsoft.NET\Framework)?

Running into the same problem, and yes I also consider it a bug from MS. You'd think either the x64 or x86 sgen.exe could handle msil assemblies, especially when you have to reference framework assemblies.
I would prefer building msil assemblies myself, but have a native-built 3rd party assembly tossed into my mix. When the project tries to generate the serialization assemblies using the x86 sgen.exe, it complains that the 3rd party assembly is "the wrong format."
When I use the x64 sgen.exe, it complains that System.Data is "the wrong format". But I don't have the option of pointing at the Framework64 version in the .csproj file.

Short answer: Don't worry about that - just add the reference and .NET will load the correct assembly at runtime.
Long answer: Pure .NET assemblies (such as all the system ones) are not actually x86 or x64. They are in an intermediate language (MSIL), which gets compiled ("just in time") to native x86 or x64 code when run. The path you see in the Add References dialog is not actually added to the project (well, it might be, but only as a "hint"). The project actually refers to the strong name of the assembly - its name, version, culture and public key. At runtime .NET will use this information to locate the assembly and it may well be loaded from a different path than where you added the reference from. It's a bit counter-intuitive, but that's how it works.
You can check this for yourself if you watch the debug output window when you start the application: you will see something like:
Loaded 'C:\WINDOWS\assembly\GAC_64\System.Data\2.0.0.0__b77a5c561934e089\System.Data.dll', Skipped loading symbols.
... even though the reference path was probably something like c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.Data.dll

The compiler uses reference assemblies only to load type information. That comes from the assembly's metadata. The metadata for x64 specific assemblies is identical to that for x86 assemblies. So, it doesn't matter. The compiler does generate a warning for it, you can freely ignore it if you know the 64-bit version of the assembly is installed in the GAC. It will be when you've got the 64-bit version of the framework installed.
One thing you probably should not do is select x64 as the Platform Target for your project. This is only required if you must use unmanaged code that is only available in 64-bit machine code. COM servers, usually. That is very rare, the typical problem is only having the 32-bit version available. Leaving the target set to Any CPU is the better choice, your binary will run on either platform. And the compiler warning will disappear.

<Reference Include="32bit.dll" Condition="'$(Platform)'=='x86'"/>
<Reference Include="64bit.dll" Condition="'$(Platform)'=='x64'"/>
Look at this answer:
How to reference different version of dll with MSBuild