$(SolutionDir) MSBuild property incorrect when running Sandcastle Help File Builder via CMD

21,152

Solution 1

While @m0sa has pointed out a very obvious fact (since I'm building the Sandcastle Help File Builder project, there's no actual solution directory), the issue was also happening during a TFS Build when building the solution where the so-called documentation project resides.

For now I've managed to solve the issue using a nasty workaround: adding a SolutionDir property in each C# project that needs to be built as part of documentation project:

  <PropertyGroup>
    <SolutionDir>$([System.IO.Path]::GetDirectoryName($(MSBuildProjectDirectory)))\</SolutionDir>
  </PropertyGroup>

Since my solution file will always be located in the parent directory of Sandcastle Help File Builder project directory, in my case this workaround works...

Now referenced projects as documentation sources are able to import a custom project where I define common MSBuild properties, both in Visual Studio builds or external ones:

<Import Project="$(SolutionDir)MSBuild\Common.properties" />

Solution 2

You only get the the correct $(SolutionDir) if you're building your solution (.sln file). The .shfbproj is a project file, and as such has no reference to its parent solution. You can try specifying the $(SolutionDir) in your command line explicitly:

msbuild /p:Configuration=Development /p:SolutionDir=MySolutionDir myproject.shfbproj

For reference: $(SolutionDir) and MSBuild

Share:
21,152
Matías Fidemraizer
Author by

Matías Fidemraizer

I define myself as a passionate software guy. From a young age I have always looked forward to new technologies. I have seen first-hand how the Internet has grown and evolved. From plain hypertext to the internet of services and cloud computing. I grew up along with the Internet, I have been learning Web tech and programming for more than 15 years. I am self-taught but an enthusiast and big fan of Computer Science, this has led me to learn and challenge myself every day. I understand Software as more than just code, it is creativity and innovation and a great opportunity to share knowledge with other professionals. After all, the tool does not make the professional. My principle is "enthusiasts do great things". A tool is just a possible expression of some valid solution to get things done right! What am I looking for? I am committed to grow, share, build, create and innovate. At the end of the day, to learn and enjoy.

Updated on July 09, 2022

Comments

  • Matías Fidemraizer
    Matías Fidemraizer almost 2 years

    When I run the Sandcastle Help File Builder project file (for example, myproject.shfbproj) using Windows CMD, I get an annoying issue: $(SolutionDir) has the same value as $(ProjectDir), and this means that project documentation sources won't build correctly, because I'm adding custom targets which already use $(SolutionDir).

    If I build the whole Sandcastle Help File Builder from Visual Studio it builds successfully.

    I'm using the following command (executed from the directory where the project is stored):

    "C:\Program Files (x86)\MSBuild\14.0\Bin\MSBuild.exe" /p:Configuration=Development myproject.shfbproj
    

    Is there a workaround for this?

  • Matías Fidemraizer
    Matías Fidemraizer over 8 years
    I tried this with no luck. I managed to workaround the issue defining the whole solution dir in each csproj before I need the right $(SolutionDir) value..
  • Alex
    Alex almost 7 years
    Needed quotes to work for me - /p:SolutionDir="MySolutionDir" rather than /p:SolutionDir=MySolutionDir
  • sorosh_sabz
    sorosh_sabz about 4 years
    I think it is very better to define some of these variable as predefined variable by Microsoft by default.
  • SandRock
    SandRock about 4 years
    This also works when running msbuild /target:Package xxx.csproj