dotnet sln add doesn't support shared projects

Describe the bug

We’re currently building support scripts for our projects which download a part of a repository (which contains shared and “normal” c# projects) and then adds all those csproj and shproj files to the targeted visual studio solution using the dotnet sln add command.

All csproj projects are getting added succesfully whereas all shproj projects aren’t. Doing the same in Visual Studio (via the IDE) the shproj projects are getting added.

The following error message appears: Invalid project Path\XYZ.shproj. The imported project "C:\Program Files\dotnet\sdk\6.0.100\Microsoft\VisualStudio\v17.0\CodeSharing\Microsoft.CodeSharing.Common.Default.props" was not found. Confirm that the expression in the Import declaration "C:\Program Files\dotnet\sdk\6.0.100\Microsoft\VisualStudio\v17.0\CodeSharing\Microsoft.CodeSharing.Common.Default.props" is correct, and that the file exists on disk.

For every import statement, in the shproj file, we’re getting somewhat the same error message.

When creating a new shared project in Visual Studio you get the following pre defined import statements:

  <Import Project="$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props" Condition="Exists('$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props')" />
  <Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\CodeSharing\Microsoft.CodeSharing.Common.Default.props" />
  <Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\CodeSharing\Microsoft.CodeSharing.Common.props" />
  <Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\CodeSharing\Microsoft.CodeSharing.CSharp.targets" />

I understand the cause since the values for the parameters MSBuildExtensionsPath and MSBuildExtensionsPath32 are different between MSBuild and dotnet.

dotnet resolves the paths to C:\Program Files\dotnet\sdk\6.0.100 whereas msbuild resolves them to C:\Program Files\Microsoft Visual Studio\2022\Preview\MSBuild\

It seems that dotnet sln add does validate the project before adding it to the solution if all import statements are valid.

Would it be possible to:

• Skip the validation?
• Feed in the parameters value
• dotnet sln add honors the target framework of the projects and falls back to msbuild (similar to dotnet build)

Is the concept of shared project being canceled from a dotnet core perspective?

Thanks in advance!

To Reproduce

1. Open Visual Studio
2. Create new solution
3. Add shared project
4. Save
5. Open console
6. Run dotnet sln remove path_to_shared_project
7. Run dotnet sln add path_to_shared_project

Exceptions (if any)

See above

Further technical details

.NET SDK (reflecting any global.json): Version: 6.0.100 Commit: 9e8b04bbff

Runtime Environment: OS Name: Windows OS Version: 10.0.19043 OS Platform: Windows RID: win10-x64 Base Path: C:\Program Files\dotnet\sdk\6.0.100\

Host (useful for support): Version: 6.0.0 Commit: 4822e3c3aa

.NET SDKs installed: 6.0.100 [C:\Program Files\dotnet\sdk]

.NET runtimes installed: Microsoft.AspNetCore.App 6.0.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.NETCore.App 6.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.WindowsDesktop.App 6.0.0 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

IDEs: VS 2022 Preview 17.1.0 Preview 1.1

[baronfel]

Thank you for the quick response! In general I think we’re going to want to approve #22954 (or something like it) as pre-work necessary to support more kinds of projects at the CLI level, even if full support in the SDK isn’t quite there yet, but I want to confirm some details myself and discuss the support implication with the team before we go ahead much further.

Thank you for all of your work so far investigating, developing, and testing this scenario.

[MonkeyLeeT]

Adding shared projects to a solution would be sufficient for now. We’ve tried dotnet sln add because this is the only option to manipulate the solution in an “official” way. The only additional work which needs to be done is to add import conditions if the files exists because without that the cli command will fail because it can’t find the referenced files in the dotnet folder. VS doesn’t add those conditions since the files exist per definition.

Regarding dotnet build won’t work: It does actually. So I don’t see an issue here.

So 2 things need to happen before you’re able to use dotnet sln add with shared projects:

1. Add import conditions if the file exists for the props and targets files
2. Add <ProjectTypeGuids>0004291E-2A0B-460D-934E-DC6B0785DB48</ProjectTypeGuids> to the shproj file
3. Until Skip adding build configurations for shared projects #22954 get’s approved remove the build configuration from the solution (post dotnet sln add)

What’s interesting is that the ProjectTypeGuid can be ANY value. I tried adding “abc” and it still works (dotnet sln add and VS properly displays the shared projects). Also building the solution using dotnet build and in VS works succesfully.

I don’t know how it works but dotnet build executes msbuild internally somehow when it’s a non .net core project and msbuild honors the file extension rather then the project type guid.

Are you able to get dotnet build working by creating a sln containing shproj using the 3 steps you mentioned?

I tried to dotnet build directly on a shproj and it wouldn’t pass with exists() on 3 props and 1 target, wondering if there’s a way to make it work directly without help of sln file.