Import language targets conditional on proj file extension

[dazinator]

This is in the SDK targets:

  </Import>

C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\Sdks\Microsoft.NET.Sdk\Sdk\Sdk.targets
============================================================================================================================================
-->
  <PropertyGroup Condition="'$(LanguageTargets)' == ''" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
    <LanguageTargets Condition="'$(MSBuildProjectExtension)' == '.csproj'">$(MSBuildToolsPath)\Microsoft.CSharp.targets</LanguageTargets>
    <LanguageTargets Condition="'$(MSBuildProjectExtension)' == '.vbproj'">$(MSBuildToolsPath)\Microsoft.VisualBasic.targets</LanguageTargets>
    <!-- If LanguageTargets isn't otherwise set, then just import the common targets.  This should allow the restore target to run,
         which could bring in NuGet packages that set the LanguageTargets to something else.  This means support for different
         languages could either be supplied via an SDK or via a NuGet package. -->
    <LanguageTargets Condition="'$(LanguageTargets)' == ''">$(MSBuildToolsPath)\Microsoft.Common.CurrentVersion.targets</LanguageTargets>
  </PropertyGroup>

Shouldn't the language targets be imported based on a capability( i.e CSharp), not project file extension?

I currently have to manually import the csharp targets into my custom project (.dnnproj), when using the new proj file format.. event though I declare CSharp capability.

[dazinator]

Ok so this also seems to be the reason why Roslyn compilation can't find assemblies referenced via PackageReference - which I raised in #218

Declaring the following LanguageTargets property, in my custom project system props file, seems to fix everything, and I no need to directly import the csharp targets anymore in my project system

  <PropertyGroup>
 <LanguageTargets>$(MSBuildToolsPath)\Microsoft.CSharp.targets</LanguageTargets>  
  </PropertyGroup>

[srivatsn]

This issue was moved to dotnet/sdk#1051

[borgdylan]

@dazinator The project capabilities get added based on the extension so what is being proposed depends on information that would not have been inferred.

[dazinator]

Capabilities get automatically added based on extension so in the case of .Csproj or .Vbproj the capability can remain inferred. However in the case of other project types with different extensions, (i.e cps projects) capabilities are declared in custom targets file. So in this instance it's up to the project type itself to declare the 'csharp' capability - therefore no inference is necessary.. so I guess i'm not understanding why there is an issue..?

[borgdylan]

Yes it's up to the custom targets to add the capabilities. I am the author of a custom .Net based language and had to write custom targets and props files to make everything available for msbuild to work. i had to manually set language targets as well. The targets and props shipped in msbuild are kind of custom targets that microsoft maintains to support c# and VB.

[dazinator]

Yes, so why wouldn't what i have suggested work then?

I guess im just failing to see the problem with this suggestion. If the code shown in this issue was changed so that it imports the appropriate language targets (csharp / vb) based on presence of a capability, it could infer this capability for .Csproj, .Vbproj file extensions - but this would now allow custom project systems (based on cps) that use the SDK targets, to work by declaring the appropriate language capability. As you've said, and as this issue shows, at the moment the capability s not enough, you also have to manually import the language targets.

Honestly not sure what the point in having a csharp capability is, if the build system can't use it to infer language capability..

[dazinator]

And just to add some more detail, my custom project type is a csharp project, just with some additional / augmented capabilities. This is why i use the standard msbuild SDK targets for csharp - because i want the standard / Microsoft provided csharp behaviour!

[borgdylan]

You should use .csproj and import extra targets/props then. In your case using a custom extension is just extra work. I recommend https://docs.microsoft.com/en-us/visualstudio/msbuild/msbuild as a starting point if you are new to MSBuild.

[dazinator]

I'm not new to MSBuild but thanks for the link! I can't use .csproj unfortunately. I am implementing a custom project type for many reasons - my use case is I want my custom project type to support csharp language features. Declaring the csharp capability should be enough to express this intent.. Hence this issue. Thanks for the suggestion.

[borgdylan]

At the msbuild level that means custom language targets then. if you import the csharp ones it will be identical to having .csproj as teh extension. You may end up with too much i.e. more than what you want from it.

[dazinator]

End up with too much from it? But I want the lot.. because I want the standard csharp feature. I think this is backwards.. If I wanted to only support part, or say, customise how I support csharp - only at that point should it become necessary to write a custom version of the language targets. Why should I be forced to implement custom csharp targets if I just want the default support?

Here is what my project file looks like:

<Project Sdk="Microsoft.NET.Sdk">
-- lots of other stuff

  <Import Project="$(CustomProjectExtensionsPath)DnnVsProjectSystem.targets" />
</Project>

And in my custom targets,

<ItemGroup>
    <ProjectCapability Include="DnnVsProjectSystem" />
      <ProjectCapability Include="CSharp" />
Lots of other capabilities

[dazinator]

And in terms of why I need a custom project type, its because even though my project type is using the csharp language - the rest of the project system is customised quite heavily. For example, I have a custom debugger, and a suite of other CPS extensibility points that differ from the implementations provided by csproj. I tried implementing these behavioural changes on top of csproj, but in the end, I couldn't achieve the types of changes necessary through "flavouring", I had to create my own project type.