Here is what I ended up doing:
The problem that I tried to solve does not repeat itself (DRY) and does not indicate the output directory of the solution (in a solution with a large number of projects), that is, when compiling the solution, all projects will have their own output. The directory is set to something like $(SolutionDir)bin\Debug or $(SolutionDir)bin\Release . It is worth noting that some projects are included in the repository and in more than one solution.
First, I created the MSBuild file (a <Project> XML - named it MySolution.sln.targets ). In it, I defined a <PropertyGroup> , which overrides the <OutputPath> property:
$(SolutionDir)bin\$(Platform)\$(Configuration)
Then I added the following import to all the relevant projects before importing the assembly targets:
<Import Project="$(SolutionPath).targets" />
Thus, each solution has an accompanying .targets file defining such things that I want to be a solution.
This worked fine, but then I came across the following problem: the above macros $(Platform) and $(Configuration) relate to project properties , not solutions. What happens if my Debug / Any CPU Configuration solution still creates a very specific project in its Release configuration? As far as I know, after a careful examination of the documentation, such macros are not exported, which have a general granularity of the solution.
I found ceztko Visual Studio extension , as a result of which Visual Studio exported exactly the macros that I was looking for, but after some experimenting and messing around, I found that this extension installed them too late - only when building the solution. This caused problems with the Visual Studio Incremental Build function - she continued to think that the projects were out of date because she was looking for the wrong place - she did not know the variables, but MSBuild.exe was.
I started messing with the IVsUpdateSolutionEvents interface , tracking every time I called the method, and then I found that IVsUpdateSolutionEvents.OnActiveProjectCfgChange is called twice when opening a 1-project solution in a new Visual Studio or changing the solution configuration from Debug to Release. Further use showed that if I set up the project for compilation in Release in both solution configurations, this method is now called once instead of twice when changing solution configurations.
I unlocked the extension repository and corrected the problem by moving the macro logic to the above method. You can find it here .
Disclaimer: this may not work well with batch build operations from the IDE and requires that you export these properties yourself when you create MSBuild.exe from the command line.
Good luck on your travels.