0

Still not knowing too much about .NET, I am tasked with converting a rather big .NET solution from VS2008 to VS2010. Part of it are a set of C++ projects (/clr), which I migrated to VS2010. I set their target framework to 2.0, because they are used in projects that are not to be converted right now.

After a lot of hassle I am at the point where the whole solution builds in VS2010, but for automated builds and tests I need to have the thing built using MSBuild, too, and that fails. The problem is that somewhere the /d1clr:nostdlib switch gets appended to the compiler command line, leading to a nasty error message:
error MSB6001: Invalid command line switch for "CL.exe". Illegal characters in path. [C:\blah\foo.vcxproj]
When I look at the command line emitted by MSBuild the only odd thing I see is that it ends with said switch: ...foo.cpp bar.cpp baz.cpp /d1clr:nostdlib

  1. I suppose this switch fails because the older compiler invoked for .NET 2.0 stuff doesn't know how to deal with it?
  2. Where would I start to look for where this switch gets appended? I don't see it on the project's property page's C/C++/Command Line option.
2
  • You mention the C++ projects remaining on .NET 2.0. Are all projects targetting 2.0, or just the C++ ones? Commented Sep 13, 2011 at 15:44
  • @RMartinho: Several projects, which are shared, will have to keep targeting 2.0. All C++ projects are among these. Commented Sep 13, 2011 at 20:49

1 Answer 1

3

Are you sure you need to set the target framework to 2.0?

Can't a 2.0 project reference a 4.0 project (or whatever the converted project is)?

From poking around the MSBuild files, the command seems to be added because of these lines in Microsoft.CppBuild.targets (on my machine, located under C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0:

 <ClCompile Condition="'@(ClCompile)' != '' and '$(CLRSupport)' != 'false' and '$(CLRSupport)' != ''"> <AdditionalUsingDirectories>$(TargetFrameworkDirectory);%(ClCompile.AdditionalUsingDirectories)</AdditionalUsingDirectories> <AdditionalOptions Condition="('$(TargetFrameworkVersion)' == 'v3.5' or '$(TargetFrameworkVersion)' == 'v3.0' or '$(TargetFrameworkVersion)' == 'v2.0')">/d1clr:nostdlib %(ClCompile.AdditionalOptions)</AdditionalOptions> <AdditionalOptions Condition="'$(TargetFrameworkVersion)' == 'v4.0'">/clr:nostdlib %(ClCompile.AdditionalOptions)</AdditionalOptions> </ClCompile> 

In other words, it is added simply because you set the target framework version to something other than 4.0. (If it had been set to 4.0, it would instead add the /clr:nostdlib flag)

I have no idea why it wouldn't work when invoked directly via MSBuild, though. Perhaps it uses a different compiler version (PATH or some other environment variable not set up correctly, perhaps?)

When building via Visual Studio, it also invokes MSBuild, so really, it shouldn't make any difference that you call MSBuild "directly", unless some part of the environment is set up differently. (or you're calling MSBuild with the wrong flags)

Of course there's nothing "magical" about these MSBuild files, so you can modify them, or edit your project to reference separate versions of them instead (which you've modified to not insert the flag). It is, if you ignore the XML clutter, just a general-purpose build system. It doesn't have any "built-in" understanding of VC++ projects, beyond what is specified in these XML files.

Sign up to request clarification or add additional context in comments.

2 Comments

I'm not sure we need the 2.0 target, but since TPTB are, this is moot. I have no idea about the rest of what you wrote, but I'll poke further into it and report back.
Damn, your hint about funny flags MSBuild might be invoked with was right on spot. For reasons I cannot fathom (and hidden in some build script), there was a "/property:FrameworkDir=%FrameworkDir%" parameter passed to MSBuild. Removing that fixed the problem. Thanks a lot!

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.