Allow defining project dependencies.

[tokizr]

Hello.

In my company's projects we now have a few native libraries that are wrapped by CppSharp, and that requires dedicated projects to setup the bindings. We'd like to add dependencies to those projects so they build order is correct.

This is possible with the ProjectDependencies section:

Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "NativeWrapper", "NativeWrapper.vcxproj", "{WRAPPER-GUID}"
	ProjectSection(ProjectDependencies) = postProject
		{BINDING-GENERATOR-GUID} = {BINDING-GENERATOR-GUID}
	EndProjectSection
EndProject

Currently it seems it is not possible to generate this information with SlnGen.

[jeffkl]

The project dependencies section of a solution file has always been a point of contention. If you only specify build order in a solution file, there is no guarantee that projects will build directly. I'm not opposed to adding this functionality to SlnGen since it exists in solution files themselves, but I would recommend you don't use project dependencies at all. Instead, you can add ProjectReference items to projects that depend on this VCXPROJ and set appropriate metadata so that you only have a build-time dependency and that's it.

<ItemGroup>
  <ProjectReference Include="..\NativeWrapper\NativeWrapper.vcxproj"
                    ReferenceAssemblyOutput="false"
                    SkipGetTargetFrameworkProperties="false" />
</ItemGroup>

SlnGen would generate the same solution but MSBuild and Visual Studio would always build NativeWrapper.vcxproj first, making it possible to build a project or a solution correctly.

https://docs.microsoft.com/en-us/visualstudio/msbuild/common-msbuild-project-items?view=vs-2022#projectreference

[tokizr]

I totally agree that this should be solved in the projects themselves, and that's exactly the first thing I tried, however we ran into issues with this approach:

1. We have two solutions, one that contains native projects (and is built in VS) and other that's built using the dotnet SDK (and does not contain the native projects). The Visual C++ SDK is not available when building with dotnet so it fails with Imported project "/Microsoft.Cpp.Default.props" was not found.
2. This does not work in the other direction, .i.e.: the same trick in the .vcxproj does not work (dependency even shows in vs but build order is not affected).

We can work around # 1 by making the dependency conditional, but that was far from perfect; And I could not get a workaround in place for # 2.

For that reason it seems to me the simplest solution is to instead use the build dependency system in the sln file.

[JeremyMorton-Blizzard]

2. This does not work in the other direction, .i.e.: the same trick in the .vcxproj does not work (dependency even shows in vs but build order is not affected).

It seems like a ProjectReference in a .vcxproj needs the Project set to the referenced project's GUID to get VS to treat it a build dependency, for example:

    <ProjectReference Include="..\Foo\Foo.vcxproj">
      <Project>{BB3995C0-27EF-0DB6-B0E3-078D1C9804BA}</Project>
      <ReferenceOutputAssembly>false</ReferenceOutputAssembly>
    </ProjectReference>

[FeralSquid]

We are also running into basically the same issue.

I believe we could solve this if there was some way to have slngen produce stable and consistent project guids for a given project.
For example, perhaps if a element exists in a csproj/vcxproj, have slngen use that instead of generating one ... or just add a new slngen-specific element for this.

If that were true, then we could declare the dependency in the vcxproj with a xml chunk like Jeremy lists above.

I did verify that this works if I generate the solution with slngen, and then update that "guid" with the one slngen set for the dependency ... but as soon as slngen changes that guid, it would break (and it already produces a different guid in our secondary sln)