Question

I have a build script (.bat) that invokes MSBUILD (C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\msbuild.exe) that used to work for a while but stopped working after I installed VS11 Developer Preview. Now, the build is not able to rebuild projects that include MSTest unit tests with private accessors.

I am getting

error CS0246: The type or namespace name ‘BaseViewModel_Accessor’
could not be found (are you missing a using directive or an assembly
reference?)

which pretty much means that MSBuild refuses to auto-generate the BaseViewModel_Accessor assembly. Of course, BaseViewModel is just an example – I am getting the error for every test class that requires accessors.

Those very same projects build just fine on the same machine from within Visual Studio 2010 (but not VS11).

I am aware of at least one answer to this question, but it is somewhat unsatisfactory, as VS is obviously installed on my machine, and I am not using NUnit but Microsoft’s very own unit testing framework.

I suspect that the observed behavior might have to do with the fact that VS11 is a “Developer Preview” (my VS10 is Ultimate), so it may be crippled and not able to generate the accessors. However, I am explicitly using .NET 4 MSBUILD.exe and so expecting it to be able to use whatever VS10 is using internally…

Anyway, if someone has any less invasive solutions than to remove both Visual Studio installations and .NET 4.5, and re-install everything from scratch, they would be much appreciated.

There’s got to be a way of fixing whatever got broken by installing VS11. Preferrably, I would like to keep VS11/.NET 4.5 installed, and not have to reinstall VS10 from scratch… However, I already tried “repairing” VS10 and it did not help.

Answer 1

To put this isse to rest, I did have to uninstall VS11, and .NET 4.5. I also had to re-install .NET 4.0, as it seemed to have been corrupted in the process.

This wasn’t a “production” machine, btw, but it sure would have been nice to separate concerns. .NET 4.5 and VS11 installation should not have – in principle – destroyed a working .NET 4.0/VS2010 combination.