VS2010 Client Profile - Namespace Reference Invalid After Build

So this is the scenario, in a project, add a reference to an assembly, then declare a variable of a type from the newly referenced assembly. Then type in the declaration, and you get the usual blue squiggly line. If you right-click then you get the option to add a 'using' reference to my assembly, and then bobs-your-uncle, all is good...

Until, you try to build the project, then for some ungodly reason VS no longer regards the namepace inclusion as valid, and spits out a

Error 377
The type or namespace name 'xx' could not be found (are you missing a using directive or an assembly reference?)

error, referring to exactly the same assembly ref that it just suggested be included.

This is, apparently, a dotNET 4 Client Profile Issue.

http://www.go4answers.com/Example/lost-references-while-building-project-143531.aspx
http://msdn.microsoft.com/en-us/library/cc668079.aspx

unable to copy file to the process cannot access because in use another process visual studio

ISSUE

vs2010 build error: unable to copy file to the process cannot access because in use another process visual studio

FIX

add following lines of code to the pre-build event command line of your project.

if exist "$(TargetPath).locked" del "$(TargetPath).locked"
if exist "$(TargetPath)" if not exist "$(TargetPath).locked" move "$(TargetPath)" "$(TargetPath).locked"

Debugging Managed Code Called from an UnManaged External EXE

MSDN Bug Report with Problem Description:

Cannot debug .NET 2.0/3.0/3.5 code using F5 in mixed mode from native c++ projects or c# project with 'start external program' set to native .exe.

For pure native c++ projects, when mixed mode debugging is selected in the properties of the startup project and the user presses 'F5', VS 2010 starts debugging for native and .NET 4.0 code - this assumption is not justified, since the user may want to debug native and .NET 2.0 code.

MSDN Fix:

There are two scenarios however that people have been encountering since Visual Studio 2010 released where Visual Studio cannot correctly determine which engine to attach with, and therefore uses the default of 4.0 leaving 2.0/3.0/3.5 applications “un-debuggable”; (1) developing a class library plug-in for a third party application (Excel, Work, AutoCAD, etc), and (2) interop debugging when launching a native .exe project. In both cases the symptoms will be the same, you will be unable to hit breakpoints in your managed code (they will be hollow with a message that “No symbols have been loaded for this document”) as well as being unable to step into the managed code.

As I explained above, the cause of this is the managed application is 3.5 or previous, and the debugger is attached with the 4.0 engine. The best workaround is to add a tag to your application’s *.exe.config file. For example, if I am debugging the application foo.exe I would edit (or create if necessary) the foo.exe.config file in the same directory as foo.exe. I would then add the tag with the correct version of the .NET runtime in the section as shown in the example below. This will let Visual Studio know which version of the .NET runtime you will be running (so if you are developing a class library plug-in for Excel, you would add the tag to the excel.exe.config file).

<!-- sample foo.exe.config -->
<?xml version ="1.0"?>
<configuration>
<startup>
<supportedRuntime version="v2.0.[version on your machine]" />
</startup>
</configuration>

To determine the correct [version on your machine] look in the “C:\Windows\Microsoft.NET\Framework” directory for the most recent “v2.0.xxxxx” folder.