Real support for shared projects (shproj/projitems)

[thomaslevesque]

What's the current story for shared projects with the .NET Core SDK?

I can create a shared project in VS, and reference it from my .NET Core project, but the experience is far from ideal. The shproj is an "old-style" project, where source files are explicitly included. I can use glob patterns, but when I add a new file from VIsual Studio, it's added explicitly to the project, which causes it to be included twice.

Is it possible to make a real .NET Core shared project ?

[pipe01]

Any updates on this?

[Phyyl]

I would also love to know if there are any developments on this. If I can be of any help too!

[markusschaber]

Almost two years now without any reactions :-/

[msedi]

I would also be interested what the current status is?

[dasMulli]

I guess that's more a project system issue than a .NET SDK issue. The SDK has tests assuring that both shared projects and "deploy projects" (referencing SDK project but wihout any own comiplation) work.
VS support is more interesting here I guess - cc @davkean
Then SDK commands could also have some knowledge about shproj.. the difference is that these aren't technically project references but includes

[VAllens]

Are there any plans to support it?

[sharpjs]

I've been using Microsoft.Build.NoTargets for SDK-style shared/just-a-bunch-of-files projects.

[commonsensesoftware]

I might wrong, but other than Visual Studio forums, I think the only other place we might voice an option is:

https://github.com/microsoft/VSProjectSystem

I don't see any mention of shared projects there. The Shared Project System is closed source (to my knowledge). There probably isn't all that much work to get this done, it just has to be prioritized.

Microsoft.Build.NoTargets does work well for loose files, there are some features lacking from a Shared Project. If you just need miscellaneous files, it's a good choice. If you have arbitrary source code files, which should honestly be pretty rare in my experience, it also works well, but you still have to link the files.

I'm not sure why the project system doesn't exclude these in its targets by default, but I find it annoying that unnecessary or usable files appear in content-only type project of loose files. The following will hide it from Visual Studio, if you care.

<ItemGroup>
  <None Include="**\*.*" Exclude="*.msbuildproj;obj\**\*.*" />
</ItemGroup>

I have several projects that multi-target and I find Shared projects the most useful and functional experience in Visual Studio to share code. The issues all stem around the UI experience. You can manually edit the *.projitems file as follows to get the .NET SDK style type MSBuild experience:

<ItemGroup>
  <Compile Include="$(MSBuildThisFileDirectory)**\*.cs" />
</ItemGroup>

Inside *.projitems

You only ever have to do this once. The problem is what the project system tries to do afterward. All my attempts at adding or removing files via Solution Explorer will cause things to go haywire. The only solution I've found is adding the files directly to disk, if not just an empty file. Once visible in the project, you can edit it just like any other file. The Shared project will pick up the files, but you may not see it in the Solution Explorer right away. Any of the following should remedy that:

• Unload/Reload the Shared project
  • This would be a lot easier if VS still had macro support
• Show all files
• Restart Visual Studio

[commonsensesoftware]

I took the liberty to create a Visual Studio feature request:

https://developercommunity.visualstudio.com/t/Support-NET-SDK-Style-Behavior-in-the-S/10221992

If we really want to get it added, everyone needs to vote and spread the word. The program management team prioritizes what to work on based on features with the most votes.

[VAllens]

I took the liberty to create a Visual Studio feature request:

https://developercommunity.visualstudio.com/t/Support-NET-SDK-Style-Behavior-in-the-S/10221992

If we really want to get it added, everyone needs to vote and spread the word. The program management team prioritizes what to work on based on features with the most votes.

good

[marcpopMSFT]

Moving to the backlog. At the time, we are not planning on prioritizing this. Our recommendation today is to put the shared files in a folder and use globbing in the consuming projects.