Open srivatsn opened 7 years ago
From @dazinator on March 26, 2017 22:54
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>
The capability gets added based on the extension as well, so this will not work.
Yes it will work..
The capability is inferred based on extension (Csproj / Vbproj etc) which works fine for those projects. For custom project types though, i.e with a different extension (e.g dnnproj) they declare their own capabilities.. They would include any relevent language capabilities in their own targets - i.e csharp
.
Honestly dont see the point of a csharp
language capability if it cant be used to infer the language.
Due to lack of recent activity, this issue has been labeled as 'stale'. It will be closed if no further activity occurs within 30 more days. Any new comment will remove the label.
I no longer develop custom project types. However I think this should be active until someone can confirm if anything has already been or will be done:
Honestly dont see the point of a csharp language capability if it cant be used to infer the language.
From @dazinator on March 26, 2017 16:25
This is in the SDK targets:
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.Copied from original issue: Microsoft/VSProjectSystem#219