msvc9 solution repairer

[swight]

I took a look at the solution files auto-generated by ROS-BE using the "make msvc9" command and found out all the paths for the various projects were wrong. So when Visual Studio tried to load the solution it couldn't find anything thus rendering the solution file useless.

To fix this problem I coded up a quick utility in my favorite language VB.Net that would fix the solution file by searching all the sub-directories and plugging in the correct file path in the solution file. The result is a very usable solution file with a few errors on load(less than 5 and they don't stop VS from loading everything else). The errors say something like "some file has already been loaded" and seem to happen only with projects that had a period in the name, these errors seem to be slightly deeper than the solution file.

Here is the utility binary
http://dl.dropbox.com/u/3383291/Solutio ... eactOS.exe

and here is the source code
http://dl.dropbox.com/u/3383291/Solutio ... eactOS.zip

The utility requires the .Net framework 2.0 to run. It is designed to be run on the command line. The path to the main sln file generated by ROS-BE in the reactos directory(named "ReactOS_auto.sln") should be passed in as a parameter.
The program will place it's output in a file called "ReacOSmsvc9.sln".

Hopefully this can help with the problem til the fix can be applied to the build system.

[b4dc0d3r]

I did not look at the source - does it update absolute path names to new absolute paths? Or does it use relative paths instead? I often have problems with absolute paths in MSVS, and so every project with a subproject uses relative paths. that way it can be moved around and still work - so I was curious about how your solution works.

[swight]

It uses paths relative to the directory the sln file is in so there should be no issues like that. The important thing is that all the other projects(.vcproj files) are somewhere in the sub-folders of the folder containing the sln file(which shouldn't be a problem unless you are moving folders with-in the area that you imported from the svn). The system is semi-robust and the paths are not hard-coded into the system to account for some future changes.

[Smiley]

Hi swight,
Thanks for testing msvc9 projects. I'll try to fix rbuild to generate a correct solution file. Could you show an example of the changes that are needed to fix the sln/vcproj files?

[swight]

using the first project as an example

old version:
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "3dtext", ".\3dtext", "EBDC815F-7E56-46b1-AAE5-FA2824A9569B"
EndProject


new version:
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "3dtext", "base\applications\screensavers\3dtext\3dtext_vc9_auto.vcproj", "EBDC815F-7E56-46b1-AAE5-FA2824A9569B"
EndProject

This one was a simple case as I just had to search for "3dtext" + "_vc9_auto.vcproj" to find the file.

But..... there were some complications.

Some of the projects had identical file names but where at different locations. In this case most cases were resolved by looking at the parent directory name and comparing it to "3dtext"(using example) to determine which project went where.

There were also some confusing scenarios concerning periods like this example(from corrected version):

Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "msacm32.drv", "dll\win32\msacm32\msacm32.drv\msacm32_vc9_auto.vcproj", "F27D7611-2B2F-40b2-8040-54C14767B40E"
EndProject

In this example "msacm32.drv" does not match the beginning of the project file name. Rather it matches the parent directory(like mentioned earlier). But when there are periods involved there is the additional consideration that the ".vcproj" file name does NOT include the ".drv" part of the name.

[Smiley]

Thanks for the information. I'll try to fix it in rbuild