Home/ Questions/Q 6588093
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-25T17:00:11+00:00

I have a (python) script that accomplishes the following: Scanning a folder looking for

  • 0

I have a (python) script that accomplishes the following:

  1. Scanning a folder looking for .csproj and .vcproj files.
  2. Creating a solution file to contain all the projects by writing text according to the .csproj and .vcproj files.
  3. Building that solution. By calling devenv.exe /Build from command line (subprocess.call on python).

My problem is: When I build, VS changes configuration in my SLN. Specifically, on SLN’s Win32 configuration, all the .csproj projects (.NET projects) switch from x86 to x64 and are marked out from the build.

Attempt that did not work:
Changing the SLN to have all the .NETs at x86 and the VCs on Win32 under x86 solution config. Again, VS breaks it when it opens the SLN : VCs are automatically change to target x64 and marked out of the build.

Attempt that worked but quite clumsy:
First, I let VS break the file. The only clumsy way that I managed to do that is calling /Build then /Clean from command line. Next, I fix the SLN file by replacing the configs that VS broke. And now when I /Build it, VS does not alter the SLN.

So:

  1. Anyone with a more elegant solution ?
  2. Any nicer way to make VS break the file other then /Build – /Clean ?
Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    The simple answer is, indentation matters to the VS sln parser.

    So folks at the company claimed it all worked back in the day, and I found it hard to believe. Over and over again I scanned the code that builds it and the sln file that is produced and couldn’t tell any difference.

    Beacuse I didn’t look at whitespaces !

    Month ago I innocently changed the code that builds the .sln file to write the file with different indentation.

    Here’s the difference of the files:

    That worked, because the file was identical to a VS-made file, including the indenetation:

    Microsoft Visual Studio Solution File, Format Version 10.00
# Visual Studio 2008
Project("{19091980-2008-4CFA-1491-04CC20D8BCF9}") = "proj1", "..\proj1_2008.vcproj", "{C844505D-3D9E-437F-94D6-BDA74999651D}"
...
EndProject
Project ...
..
EndProject
Global
Global
  GlobalSection(SolutionConfigurationPlatforms) = preSolution
*good     Debug|Win32 = Debug|Win32
          Debug|x64 = Debug|x64
          Release|Win32 = Release|Win32
          Release|x64 = Release|x64
  EndGlobalSection
  ....

    This one caused VS to re-edit, and as a side eefect to break our desired solution configuration:

    Microsoft Visual Studio Solution File, Format Version 10.00
# Visual Studio 2008
Project("{19091980-2008-4CFA-1491-04CC20D8BCF9}") = "proj1", "..\proj1_2008.vcproj", "{C844505D-3D9E-437F-94D6-BDA74999651D}"
...
EndProject
Project ...
..
EndProject
Global
    GlobalSection(SolutionConfigurationPlatforms) = preSolution
*bad    Debug|Win32 = Debug|Win32
*indent-Debug|x64 = Debug|x64
*ation  Release|Win32 = Release|Win32
        Release|x64 = Release|x64
    EndGlobalSection
    ....
    • 0