VS11 Beta Changing Platform Target

Question

Hello,

I've installed VS11, but still have VS2010 installed.  It seems the action of switching my project targets over to x86 has somehow migrated over to VS2010, despite having never opened a project with VS11 aside from a quick starter project.  This is causing mayhem for builds that reference AnyCPU .dll files, and is throwing warnings all over the place - see below for an example.  In some cases, VS2010 has completely switched off a build, resulting in the same DLL being used despite the code being edited, which is a pretty bizarre phenomena in my opinion.

To clarify:  This is all happening in VS2010 with my old projects, despite never having opened these projects with VS11.  It appears to be a function of the new .NET framework install, even though I'm still targeting .NET 4.0 Client Profile.

Reading on the forums it seems like this was done for NEW projects so that x86 edit and continue in place debugging could be enabled by default.  But why is it changing things in VS2010 without asking me, and breaking my project builds?

Thanks,

Giawa

Example warning:

Warning 1 There was a mismatch between the processor architecture of the project being built "MSIL" and the processor architecture of the reference "VerilogParser.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. VerilogLanguagePackage

Answer 1

Another fun one - another old project loaded into VS2010...  Since the platform target seems to have been forcibly changed the build is completely broken with a BadImageFormatException, similar to the one below.

Could not load file or assembly 'Plotter, Version=1.4.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. An attempt was made to load a program with an incorrect format.

I am now going to try to uninstall VS11...  I'm hoping everything goes back to normal.

Answer 2

Hi Giawa,

I encounted the same warning. The warning ID is MSB3270, which indicates that it is a warning generated by MSBuild. MSBuild is part of .NET and when you install .NET 4.5 beta (implicit by installing VS 11 or just as the .NET 4.5 beta package) it will be updated.

In general this warning is a good thing as it tells you that your 'any-cpu' assembly references a x86 assembly: which will cause a crash on a x64 platform (the other around is not a problem).

It seems however that MSBuild cannot handle C++/CLR projects that are configured to compile in x86 mode and have managed references: it will generate false warnings in those cases. I solved it by adding the attribute <PlatformTarget>x86</PlatformTarget> to a couple of .vcxproj files (in the Configuration sections)

Answer 3

You may want to report this issue as a bug on MS Connect as well.

https://connect.microsoft.com/VisualStudio/Feedback 

You'll need to sign in with your Windows Live ID.

Answer 4

See also https://connect.microsoft.com/VisualStudio/feedback/details/728995/new-vs2010-project-compiler-warning-since-installing-dotnet4-5-vs2011-beta

Answer 5

Hi Giawa,

Do you mean that you changed VS 11 project target platform to x86, which results in VS 2010 project targets changing?

From the Connect, it seems like several people encountered this problem too. Please wait for the solution from Connect.

If you have any other problems, please feel free to let me know.

Best Regards,

---

Alexander Sun [MSFT]
MSDN Community Support | Feedback to us

Answer 6

I also get the same problem.  However I notice that if I leave the Platform for each of my projects as x86, which is what they were in VS 2010, then change the Active Solution Platform to Any CPU, compile, then set the Active Solution Platform back to x86 and compile again the error goes away.  This seems to happen whenever I go from VS11 back to VS2010 then back to VS11 for the same solution.  I am doing this because I work offsite using VS11 but onsite with VS2010, so I go back and forth with the solution, and that is when this problem crops up.  Once I do the above fix and stay in VS11 I don't have to problem, even if I open and close VS 11.

---

nlm