After installing the .Net Framework 2.0 SDK, I noticed that there was a Microsoft Visual Studio 8 folder in my program files. Inside, I found a C++ compiler and linker and some standard C headers and libraries. There's no standard C++ headers, but I do know of the STLport project at sourceforge that should suffice. And installing the Platform SDK should get you going enough for basic Windows programming. Not to mention the DirectX SDK ;)
Now I'm not sure that this is the real deal compiler, so if someone knows and we're barking up the wrong tree, please let us know.
The following environment variables are required to run the tool chain. We'll set these from Managed Build automatically. We'll need to snoop at the registry to find the install locations.
set PATH=C:\Program Files\Microsoft Platform SDK\Bin;C:\Program Files\Microsoft Visual Studio 8\VC\bin;C:\Program Files\Microsoft Visual Studio 8\Common7\IDE;%PATH% set INCLUDE=C:\Program Files\Microsoft Platform SDK\Include;C:\Program Files\Microsoft Visual Studio 8\VC\include set LIB=C:\Program Files\Microsoft Platform SDK\Lib;C:\Program Files\Microsoft Visual Studio 8\VC\lib
PATH, of course, gives you the compiler and linker along with some handy tools out of the Platform SDK, such as nmake. INCLUDE and LIB give you the build-in include path and library path.
It would be easy to just assume that the user also has cygwin installed and use it's make and file utility commands (e.g. rm, mv, cp). But it should be possible to do all this by simply installing the Platform and .Net SDKs. That means using nmake and the Windows file utility commands (e.g. del, move, copy).
We'll create the standard project types for executable, static library, and DLL. Tools definitions will be provided for cl, link, and lib. We may also add some for rc (anyone use resources anymore?) and midl (that may not be necessary anymore either given #import). We'll also need to make sure ScannerInfo works, especially the include paths from the INCLUDE variable.
Support the import of build settings from VisualStudio. This would imply that the CDT settings should probably be the same as possible as defined in VisualStudio.
This is obviously the hardest part. Current thoughts are a non-CDI implementation interfacing to the dbgeng.dll from the Debugging Tools for Windows that comes with the Platform SDK to the new Debug APIs. This will help us decide what things are reusable in the CDI in the new world (because we would have ended up implementing them again for this integration).