We have a large C++ COM-based project we will migrate (slowly) to .NET.
We have several basic libraries we need to wrap with C++ managed wrapper
libraries. Having C++ runtime Debug/Release mixed with managed code seems to
make problems for project setup.
The document: Team Development with Visual Studio .NET and Visual SourceSafe
http://msdn.microsoft.com/library/de...l/tdlg_ch5.asp
contains recommendations for large project setup.
It seems to be difficult to avoid loading in all the modules into
a solution.
The above document says for file reference projects: link to the Release
version.
If I have a solution with a C# main program linked to another managed C++
project linking unmanaged C++ with C++ runtime the Debug C++ runtime will be
loaded. If I also add a file reference to the release version of another
managed C++ module I get a second (release) version of C++
runtime -> crash.
How should this be done?
Our developers are used to pull in the COM/DLL projects they want to
change/debug and compile just those. A lot less flexible in .NET?
The project reference system in .NET seems very inflexible. C# ide only have
specific paths while the C++ property pages allow paths with macros (at least
in 2005 version). Why the difference?
Why is the deference not configuration specific, i.e. sep. paths for
Debug/Release?
If I have a file path and load in the owning project I might want to
automatically switch to project ref?
Cheers
Ditlef
