Unable to use `dotnet sln add` to add an esproj to a solution

[danroth27]

Visual Studio has an esproj project type for working with JavaScript in a .NET solution. If I try to use the .NET SDK to add an esproj to a solution I get the following error:

PS C:\Users\user\Documents\RazorClassLibraryWithEsProjTemplate\bin\samples> dotnet sln add .\RclESBuild\RclESBuild.Assets
Project 'C:\Users\user\Documents\RazorClassLibraryWithEsProjTemplate\bin\samples\RclESBuild\RclESBuild.Assets\RclESBuild.Assets.esproj' has an unknown project type and cannot be added to the solution file. Contact your SDK provider for support.

.NET SDK version 8.0.100

@baronfel @joj

[KalleOlaviNiemitalo]

Similar issues for other project types

• .shproj dotnet sln add doesn't support shared projects #22921
• .ilproj dotnet sln add <proj> does not understand IL projects #16690
• .msbuildproj dotnet sln add does not work for projects with extension .msbuildproj #11292
• .dcproj How to add .dcproj into solution via dotnet sdk #4100

[baronfel]

@KalleOlaviNiemitalo is correct - we have to add explicit support for different project types. This is (I believe) due to the need to know the project type guid to insert into the solution file. If @joj wants to send a quick PR we'd be happy to take it, or we can see if we can squeeze this in the next iteration.

[KalleOlaviNiemitalo]

I wonder if a --project-type-guid option could be defined as a way to add projects with types that .NET SDK itself does not support.

[baronfel]

I believe the original intent of the constrained set of explicitly supported projects was to prevent adding projects that the . NET SDK itself couldn't build. As more kinds of projects support modern .NET we may need to rethink this assumption.

[KalleOlaviNiemitalo]

I imagine the new option would work like this:

Options:
  --in-root                                Place project in root of the solution, rather than creating a solution folder.
  -s, --solution-folder <solution-folder>  The destination solution folder path to add the projects to.
  -g, --project-type-guid <guid>           The GUID from which Visual Studio recognizes the project type.
  -?, -h, --help                           Show command line help.

$ dotnet sln add --project-type-guid=DA4F50F0-C525-43EB-9B35-2E48D2D10781 Lib/Lib.csproj
Project `Lib\Lib.csproj` added to the solution.
note: Did not use the default project type GUID 'FAE04EC0-301F-11D3-BF4B-00C04F79EFBC'.
$ dotnet sln add Proj2/Proj2.msbuildproj
Project 'C:\Demo\Proj2\Proj2.msbuildproj' has an unknown project type and cannot be added to the solution file. Contact your SDK provider for support, or override with the --project-type-guid option.

with a table in docs:

Visual Studio requires a project type GUID for each project in a solution. dotnet sln add tries to choose the correct GUID automatically, based on the DefaultProjectTypeGuid property defined in the SDK used by the project, or based on the file extension. Starting from .NET SDK 9.0.100, if dotnet sln add does not recognize the project type or you need to override it, you can specify the GUID with the --project-type-guid option.

Extension	Project type GUID	First supported in
.csproj	FAE04EC0-301F-11D3-BF4B-00C04F79EFBC	.NET Core SDK v1.0.0-rc3-004517
.fsproj	F2A71F9B-5D33-465A-A702-920D77279786	FCS-15.0.1
.vbproj	F184B08F-C81C-45F6-A57F-5ABD9991F28F	.NET Core SDK v1.0.0-rc3-004517
.shproj	D954291E-2A0B-460D-934E-DC6B0785DB48	.NET SDK 8.0.100-preview.7.23376.5

(Version numbers from dotnet/cli#5022 merge dotnet/cli@441277c, dotnet/fsharp#2993 merge dotnet/fsharp@9c75634, and #33837 merge ed87865.)

Do .esproj files import some SDK that could set the DefaultProjectTypeGuid property?

[KalleOlaviNiemitalo]

On second thought, drop the -g; this option would be rarely used and not deserve such a short alias.

[baronfel]

Two things need to happen:

• we need to add the esproj guid of {54A90642-561A-4BB1-A94E-469ADEE60C69} to our mapping here (strictly speaking this is optional, it's mainly used for tests)
• the ESProj SDK needs to set DefaultProjectTypeGuid to this same value early in its targets file

Then sln add should start working

[KalleOlaviNiemitalo]

slngen has a different scheme, using SlnGenCustomProjectTypeGuid items rather than the DefaultProjectTypeGuid property.

[baronfel]

Logged #36638 to document this implicit requirement of the SDK (along with hopefully many others).

[MithrilMan]

any news on this issue?
what's the actualy way (if any) to add an existing dcproj to a solution with dotnet sln CLI?

[baronfel]

dcproj is a separate thing from esproj - the docker compose project type doens't support building with new-style SDKs, and so the .NET CLI isn't able to interact with it. The only reason esproj works is because the team that owns esproj did the work to make their project type work with the .NET SDK. I would suggest that you log a feedback ticket in Developer Community for the Visual Studio Container Tools for Docker team to request that they support the .NET SDK. Once that work is done, the .NET CLI should work pretty much automatically.

[MithrilMan]

After trials and error I managed to make my script work. In my scenario my script is generating a solution using CLI and copying some files, I managed to use dotnet sln add by adding

<PropertyGroup>
	<ProjectTypeGuids>E53339B2-1760-4266-BCC7-CA923CBCF16C</ProjectTypeGuids>
</PropertyGroup>

in my dcproj I'm adding and it's working