`dotnet sln add <proj>` does not understand IL projects

[Ilia-Kosenkov]

Description

dotnet currently supports several 'types' of projects, including *.csproj for C# projects and *.fsproj for F#.
There is another rare project type, *.ilproj, which can sometimes be useful.

dotnet cli can be used to add IL project to another project as a reference using

dotnet add <target_proj> reference <referenced_proj>

However, IL project cannot be added to a solution file using

dotnet sln <sln_path> add <il_proj>

This fails with an error:

Project 'Path/To/ILProj.ilproj' has an unknown project type and cannot be added to the solution file. Contact your SDK provider for support.

Here is a reproducible example (PowerShell targeting Windows):

reprex.ps1

$global_json = "
{
    `"msbuild-sdks`":
    {
        `"Microsoft.NET.Sdk.IL`" : `"5.0.0`"
    }
}"
$Project_ilproj = "
<Project Sdk=`"Microsoft.NET.Sdk.IL`">
  <PropertyGroup>
    <TargetFramework>netstandard2.0</TargetFramework>
    <MicrosoftNetCoreIlasmPackageVersion>5.0.0</MicrosoftNetCoreIlasmPackageVersion>
  </PropertyGroup>
</Project>"

$Project_csproj = "
<Project Sdk=`"Microsoft.NET.Sdk`">
  <PropertyGroup>
    <TargetFramework>netstandard2.0</TargetFramework>
  </PropertyGroup>
</Project>"

dotnet new sln -o ILSolution                               # Set up empty solution
mkdir ILSolution/ILProj                                    # Manually create subfolder for IL project
$Project_ilproj > ILSolution/ILProj/ILProj.ilproj          # Write IL project file
$global_json > ILSolution/ILProj/global.json               # Wrige global.json to resolve SDK

mkdir ILSolution/CSProj                                    # Manually create subfolder for CS project
$Project_csproj > ILSolution/CSProj/CSProj.csproj          # Write C# project file

# This adds IL project as reference to C# project. Finishes successfully
dotnet add ILSolution/CSProj/CSProj.csproj reference ILSolution/ILProj/ILProj.ilproj

# This attempts to add CS project to the solution and succeeds
dotnet sln ILSolution/ILSolution.sln add ILSolution/CSProj/CSProj.csproj

# This attempts to add IL project to the solution and fails with an error
dotnet sln ILSolution/ILSolution.sln add ILSolution/ILProj/ILProj.ilproj

After running reprex.ps1, the following folders/files are created:

tree /F ILSolution

C:\...\ILSOLUTION
│   ILSolution.sln
│
├───CSProj
│       CSProj.csproj
│
└───ILProj
        global.json
        ILProj.ilproj

The expected behaviour, in this case, is dotnet sln add succeeds for IL project, and does the same as for C# project.
Even though IL does not seem to be a first-class citizen in the build infrastructure, dotnet is able to manage IL project as a reference, build & run it (providing there is some *.il code to compile), so the same is expected when managing a solution file.

It seems that when invoking dotnet sln add the cli relies on file extensions rather than on the file structure. The problem can be partially resolved if IL proj is renamed to *.csproj. However, to make IL builds work, the name has to be reverted back and *.sln file manually edited (fixing project file extension), which is far from ideal UX and significantly complicates any CI integrations.

As an example, here is System.Runtime.CompilerServices.Unsafe.ilproj
https://github.com/dotnet/runtime/blob/79ae74f5ca5c8a6fe3a48935e85bd7374959c570/src/libraries/System.Runtime.CompilerServices.Unsafe/src/System.Runtime.CompilerServices.Unsafe.ilproj#L1

And here it is listed in System.Runtime.CompilerServices.Unsafe.sln
https://github.com/dotnet/runtime/blob/79ae74f5ca5c8a6fe3a48935e85bd7374959c570/src/libraries/System.Runtime.CompilerServices.Unsafe/System.Runtime.CompilerServices.Unsafe.sln#L8-L9

To me, this indicates that the scenario I am describing (adding IL project to SLN using dotnet cli) should be supported

Tested in the following environments

• Windows 10 x64 Pro 10.0.19042:

dotnet --info

.NET SDK (reflecting any global.json):
 Version:   6.0.100-preview.2.21155.3
 Commit:    1a9103db2d

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

Host (useful for support):
  Version: 6.0.0-preview.2.21154.6
  Commit:  3eaf1f316b

• WSL2 Ubuntu 20.04.2 LTS (GNU/Linux 5.4.72-microsoft-standard-WSL2 x86_64)

dotnet --info

.NET SDK (reflecting any global.json):
 Version:   5.0.103
 Commit:    9effbc8ad5

Runtime Environment:
 OS Name:     ubuntu
 OS Version:  20.04
 OS Platform: Linux
 RID:         ubuntu.20.04-x64
 Base Path:   /usr/share/dotnet/sdk/5.0.103/

Host (useful for support):
  Version: 5.0.3
  Commit:  eae88cc11b

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[FiniteReality]

It seems that when invoking dotnet sln add the cli relies on file extensions rather than on the file structure.

I believe this is incorrect - from my testing it requires that the ProjectTypeGuids property or the DefaultProjectTypeGuid property contain a valid value.

Here's a link to the relevant source code which performs these checks: https://github.com/dotnet/sdk/blob/main/src/Cli/dotnet/SlnFileExtensions.cs#L19

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[Ilia-Kosenkov]

It seems that when invoking dotnet sln add the cli relies on file extensions rather than on the file structure.

I believe this is incorrect - from my testing it requires that the ProjectTypeGuids property or the DefaultProjectTypeGuid property contain a valid value.

Here's a link to the relevant source code which performs these checks: https://github.com/dotnet/sdk/blob/main/src/Cli/dotnet/SlnFileExtensions.cs#L19

Thanks for the update, I was just speculating (I have not seen the sources you linked before).
My speculations were based on the fact that one can create, say, a class library C# project, rename it to *.ilproj, and it will be impossible to add it to a solution file. Rename it to .fsproj or .csproj, and it works. Here is an illustration:

dotnet new sln -o SlnDir
dotnet new classlib -o SlnDir/CSProj
mv ./SlnDir/CSProj/CSProj.csproj ./SlnDir/CSProj/CSProj.ilproj
dotnet sln SlnDir/SlnDir.sln add SlnDir/CSProj/CSProj.ilproj     # <- Here it fails
mv ./SlnDir/CSProj/CSProj.ilproj ./SlnDir/CSProj/CSProj.fsproj
dotnet sln SlnDir/SlnDir.sln add SlnDir/CSProj/CSProj.fsproj    # <- Works

To me it seems like it does not care about the content of the project file as long as it is valid.

Because the error is likely caused by an unresolved guid, it seems there is no entry for DefaultTypeGuid when the project type is IL.

UPD:
This seems awfully similar to what I was describing:

sdk/src/Cli/Microsoft.DotNet.Cli.Sln.Internal/ProjectTypeGuids.cs

Lines 4 to 13 in 4465892

	namespace Microsoft.DotNet.Cli.Sln.Internal
	{
	public static class ProjectTypeGuids
	{
	public const string CSharpProjectTypeGuid = "{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}";
	public const string FSharpProjectTypeGuid = "{F2A71F9B-5D33-465A-A702-920D77279786}";
	public const string VBProjectTypeGuid = "{F184B08F-C81C-45F6-A57F-5ABD9991F28F}";
	public const string SolutionFolderGuid = "{2150E333-8FDC-42A3-9474-1A3956D46DE8}";
	}
	}

[FiniteReality]

After some quick skimming, only SolutionFolderGuid is actually used out of that; the rest are only used in unit tests.

It seems that Microsoft.NET.Sdk.IL only sets one of the required values when Microsoft.NET.Sdk.IL.targets is imported: https://github.com/dotnet/runtime/blob/3c1f142c1d717f86b2f64b4d2843ab0dd689a13e/src/coreclr/.nuget/Microsoft.NET.Sdk.IL/targets/Microsoft.NET.Sdk.IL.targets#L19

However, that file is only imported from Microsoft.NET.Sdk.IL.Common.targets when '$(IsCrossTargetingBuild)' != 'true': https://github.com/dotnet/runtime/blob/3c1f142c1d717f86b2f64b4d2843ab0dd689a13e/src/coreclr/.nuget/Microsoft.NET.Sdk.IL/targets/Microsoft.NET.Sdk.IL.Common.targets#L11

And that itself is referenced by $(LanguageTargets), only when the project extension is .ilproj: https://github.com/dotnet/runtime/blob/3c1f142c1d717f86b2f64b4d2843ab0dd689a13e/src/coreclr/.nuget/Microsoft.NET.Sdk.IL/sdk/Sdk.targets#L16

The $(LanguageTargets) property is unconditionally imported as part of the .NET Sdk:

sdk/src/Tasks/Microsoft.NET.Build.Tasks/sdk/Sdk.targets

Line 37 in 4465892

<Import Project="$(LanguageTargets)"/>

To me, it seems plausible that either:

• the .NET SDK targets aren't being imported correctly when running dotnet sln add (leading to Microsoft.NET.Sdk.IL.Common.targets not being imported), or
• Somehow $(IsCrossTargetingBuild) has been set to true.

[Ilia-Kosenkov]

Ok, here is another of my observations, perhaps it will somehow help:
Create an empty *.ilproj file and write to it the following:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>netstandard2.0</TargetFramework>
  </PropertyGroup>
</Project>

Notice that Sdk is the regular one, not IL.
This project -- which does not reference Microsoft.NET.Sdk.IL explicitly -- still fails when it is added to an existing solution.
If *.Sdk.IL is not referenced implicitly somehow, the problem does not seem to be related to the IL version of the SDK and its nuget.