Added JavaScript import after

[joj]

Esprojs may be referenced by ASP.Net projects (or others). When this happens, the .net project will have to not reference output assembly on the esproj, because there is no output assembly. This targets file provides that behavior.

[baronfel]

cc @rainersigwald @dsplaisted for review/insight here - @joj is from the esproj team trying to make consuming .esproj projects nicer for other SDK-style projects in general. Right now, consumers of .esproj ProjectReferences have to markup every one of their references.

Ideally this is something that could be done in by the esproj targets themselves, but these references are on the consuming side. We couldn't find another viable extension spot given the current ways we have to extend MSBuild, so this was the best thing that could be found.

If we take this we would also need to coordinate with VS to get the same file in their mirrored MSBuild extensions layout path.

[dsplaisted]

Seems fine to me. Does this need to work in non-SDK style consuming projects? If not, it would probably be easier to put it somewhere in the .NET SDK targets, and you wouldn't have to worry about mirroring it for .NET CLI and full MSBuild.

[KalleOlaviNiemitalo]

I thought this could be done as an ItemDefinitionGroup, but I got error MSB4190 when I tried.

<Project>
  <ItemDefinitionGroup>
    <ProjectReference>
      <ReferenceOutputAssembly Condition="'%(ProjectReference.Extension)' == '.esproj'">false</ReferenceOutputAssembly>
    </ProjectReference>
  </ItemDefinitionGroup>

  <ItemGroup>
    <ProjectReference Include="huhhuh.esproj" />
  </ItemGroup>

  <Target Name="Build">
    <Message Text="ProjectReference %(ProjectReference.Identity) %(ProjectReference.ReferenceOutputAssembly)" />
  </Target>
</Project>

error MSB4190: The reference to the built-in metadata "Extension" at position 1 is not allowed in this condition "'%(ProjectReference.Extension)' == '.esproj'".

[joj]

I tried the ItemDefinitionGroup and couldn't make it work, but I do believe the target still makes a lot of sense. @dsplaisted I'm all for a better location for this targets file. Where would a good location in .Net SDK Targets be? I wasn't sure, so just looked for other well known common after targets :)

[joj]

Oh, wait, just re-read that: this does in fact need to work for non-SDK Style projects. ASP.Net (.Net Framework) has the same scenario as the .Net Core version has.

[rainersigwald]

this does in fact need to work for non-SDK Style projects

Then the best home for this is probably in https://github.com/dotnet/msbuild/blob/main/src/Tasks/Microsoft.Common.CurrentVersion.targets.

[joj]

You mean modifying the actual common file? I can do that... I thought the bar was very high on that one :)

[rainersigwald]

It is pretty high, but it's the only way to get common functionality between .NET SDK and VS. Were you thinking of shipping this ImportAfter to VS in a VSIX as well as here?

[joj]

Yes on shipping vsix, but I would rather do common tbh. The problem with vsix is that it will only happen if we actually have the workload. In some corner cases that may not be true. I'll amend this PR today.

[joj]

Moved to msbuild to live in currentversion targets