I have a VS2008 Professional solution that I tried to convert to VS2010 Professional (RTM from MSDN download) today and I am experiencing some problems with some unmanaged and managed C++ DLLs that are referenced by a C# application.
The C# application is set to target .NET 3.5 (as it was in the VS2008 version) but when I try and compile it I get a lot of warnings like:
The primary reference "xxxx.dll" could not be resolved because it had an indirect dependency on the .NET Framework assembly "(various assembly names)", Version 4.0.0.0 ... which has a higher version "4.0.0.0" than the version "3.5.0.0" in the current target framework
and ultimately I get a failure to build.
From this I understand that it is a mismatch in .Net framework version. So I look at the properties of the unmanaged C++ DLL project and under "Common Properties->Framework and References" I can see "Targeted framework: .NetFramework, Version=v4.0"
So I go WTF!?!?!?, why does a pure C++ DLL now target a .Net framework when it sure as hell didn't in the VS2008 version. I then added on to that exclamation as there appears to be no way to change this. I also look at the managed C++ and see the same thing: targeting .Net version=v4.0 and again no way to change this at all.
In the C++ General properties there is an entry for "Common language runtime support" and I have set this to "No common language run time support" but that hasn't seem to have done anything.
So I have two questions:
Why has my pure C++ DLL now been tagged as targeting a .Net framework?
How can I change/remove this targeting?
Solution
As per Hans' reply and the link he supplied I now see that I have 3 choices:
Stay at VS2008 and everything works
Keep both VS2008 SP1 and VS2010 installed so that I can have .Net 3.5 c# applications and c++ managed code as per the link supplied by Hans.
Move everything to VS2010 and move to a minimum of .Net 4.0 for all my c# apps
I am really annoyed to have to make that choice as MS has deliberately chosen to break functionality when moving from VS2008 to VS2010. This is not the sort of behavior I expected. I was expecting to convert the project and have it compile with no issues in the same manner that moving from VS2005 to VS2008 worked.
Fortunately I do have a need to go to .Net 4.0, but I just wasn't expecting to have to do it so soon.
Update
I decided to move to .Net 4 framework and encountered problems with referencing managed c++ projects from c# projects. I was getting errors like the following when trying to add the reference to the c++ managed code project
A reference to 'myproj' could not be added. An Assembly must have a 'dll' or 'exe' extension in order to be referenced.
Google lead me down the path to "cli c project cannot be referenced from c project allowing only assembly dll" which turned up that there was an extraneous "\" in the output path of the managed c++ project. The original VS2008 output path was specified as
$(SolutionDir)\$(ProjectName)\$(Configuration)\
But in the VS2010 project the SolutionDir macro has a trailing "\" (or the VS2008 version didn't care about it) giving a path like
c:\projects\thisproject\solution\\projectname\configuration\
And VS2010 barfed over that path when trying to add a reference to the managed c++ code. My solution was to change the output path to be
$(SolutionDir)$(ProjectName)\$(Configuration)\
And now I am (sort of) happy
Keep your eyes on the ball, the warning you get is for a managed C++ assembly. And the platform target setting for an unmanaged DLL is of no consequence, it won't use any .NET references while being built.
Yes, they could not make the platform target setting editable in the C++ IDE, the VS2008 tool chain is required to build C++/CLI assemblies for 3.5. This blog post explains the workaround. You can upvote this feedback article if you're unhappy with that.