[cmake-developers] Adding support for C# shared projects

[Alan Rushforth]

Hello,

I am currently working on adding support for C# shared projects to CMake,
as I have a project which uses them heavily which I would like to migrate
to CMake.

Shared projects are are effectively a bag of source files, which can be
used in other projects but which have no direct compilation output. The
best workaround for the lack of support I have found so far is to use
"VS_CSHARP_Link" to include all the source files that would have been in
the shared project in each project that referenced it. This works but the
result in VS is pretty ugly and unintuitive, particularly if you are using
the shared project concept heavily and end up with hundreds of identical
source files linked into every project, hence my desire add proper support.

Instead of a .csproj file, shared projects have both a .shproj and
.projitems file. The content of both is effectively a stripped down .csproj
file so I have been able to reuse a lot of the .csproj generation code to
create these.

What I would like people's suggestions on is the best way of a user
specifying they want a shared project rather than a normal class library.

I have implemented a "working" patch based on a new boolean target property
"VS_DOTNET_SHARED_PROJECT" but having read other issues I'm aware Michael
Stürmer likes to minimise these properties. Therefore I am interested in
people's opinions as to whether this is an acceptable approach, or what a
better approach might be. The other option I thought of was to use the
STATIC flag of the "add_library" command, as C# doesn't differentiate
between STATIC and SHARED libraries and shared projects are conceptually
similar(ish) to STATIC libraries. Personally I think this second approach
might be muddying concepts and therefore cause confusion but am interested
in any thoughts or other ideas.

Cheers,
Alan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake-developers/attachments/20180124/8b83103e/attachment.html>