Project system fails to load when extension is not .csproj

[ericstj]

Visual Studio Version:
VS 2019 RC

Summary:
I have an SDK based project using a custom SDK. It is not a C# project but I expect CPS to be able to load and handle it just fine. If I attempt to add it to a SLN as an ".msbuildproj" it fails. If I name it .ilproj and add it to the SLN manually in a text editor it also fails. If I rename it to .csproj the project system will load it.

dotnet build has no problem with the project regardless of extension which makes me think this is a project-system bug.

Steps to Reproduce:

1. Load attached SLN.

Expected Behavior:
Both projects load correctly.

Actual Behavior:
csproj loads correctly, ilproj fails with error : The project file cannot be opened by the project system, because it is missing some critical imports or the referenced SDK cannot be found. despite it being idetntical to the csproj.

User Impact:
Lack of extensibility for non-default project types.

ilproj-repro.zip

/cc @zsd4yr

[ericstj]

Turns out the csproj workaround here is not viable. Though it permits loading many other targets condition things off of $(MSBuildProjectExtension) so it breaks the ilproj behavior.

[ericstj]

So it turns out I can workaround this by adding the following:

  <!-- Import design time targets for Roslyn Project System. These are only available if Visual Studio is installed. -->
  <PropertyGroup>
    <ManagedDesignTimeTargetsPath Condition="'$(ManagedDesignTimeTargetsPath)'==''">$(MSBuildExtensionsPath)\Microsoft\VisualStudio\Managed\Microsoft.Managed.DesignTime.targets</ManagedDesignTimeTargetsPath>
  </PropertyGroup>
  <Import Project="$(ManagedDesignTimeTargetsPath)" Condition="'$(ManagedDesignTimeTargetsPath)' != '' and Exists('$(ManagedDesignTimeTargetsPath)')" />

Is that really needed for custom project types? I remember before I was able to make this work without importing anything so long as I imported Common.targets.

Kudos to @nguerrera for pointing me in the right direction.

[davkean]

I missed this. This repro and csproj are not general purpose projects for targets that don't produce something through csc. While legacy did seemingly enable you to workaround this by overriding targets, practically, a bunch of stuff broke because of it. As an example, the up-to-date check never worked. We are planning on making changes to not require that set of targets above be defined, but even then, you'll be swimming upstream to make this work.

I think we'll either want a specific project type that's designed for IL, or alternatively, a project type that lets you hang off any random targets, but opens and shows a tree. Either way, I'm duping this against #4600, which I'll use to track this.