Need a common way to reference CMakeLists.txt projects from a csproj

This is of use in https://github.com/dotnet/winforms/pull/1932

See https://github.com/dotnet/winforms/pull/1932#discussion_r325710760

We’d basically like to extract the behavior present in coreclr (https://github.com/dotnet/coreclr/blob/master/Documentation/building/test-configuration.md) where you can write

<ProjectReference Include="../NativeDll/CMakeLists.txt" />

This is useful to many different .NET Core projects, not just coreclr. I’d like to use it in winforms but also WPF would need to be able to test interop scenarios similarily

/cc @RussKie @AaronRobinsonMSFT @jkoritzinsky

[jkoritzinsky]

I’ve been working locally on making a new SDK to add to Arcade that would drive our CMake builds in the runtime repo. I could definitely add a feature that enables referencing a CMakeLists.txt from another project through this SDK.

I’m going to do a little bit of work testing it out with CoreCLR before I put out a PR here.

[AaronRobinsonMSFT]

Yeah I noticed this. Ideally, yes. Would simplify things greatly

That is a bit more complicated since there would be complexity with parallel build, but of course would be preferred. It does increase the work and testing burden significantly.

Do we not already have a standard layout artifacts/bin/projectname?

We do indeed. However, that needs to be propagated to all CMake generated projects so that those projects are also aware of the layout. In order to do that CMake needs to know about the additional build flavour (Checked) and ensure that configuration is described properly with respect to compiler flags et al. Also of note, I don’t believe the default Release build configuration in CMake passes the “generate symbol files” compiler flag, so that configuration’s flags must also be updated in a global way.

There is also the IDE support question. If the user loads the .csproj file in VS or some other IDE, is the expectation that the ProjectReference tags will be respected? Probably not a blocker, but this is similar to my initial post about defining the expectations for the work done by the Arcade team. @markwilkie’s suggestion of creating a proof-of-concept (POC) in the WinForms repo so the Arcade team can understand a second example of desired support would be the ideal way to make the case.