search

CZEMacLeod / MSBuild.SDK.SystemWeb

This MSBuild SDK is designed to allow for the easy creation and use of SDK (shortform) projects targeting ASP.NET 4.x using System.Web.
MIT License
151 stars 8 forks source link

Support for C# 10? #28

Closed Bouke closed 2 years ago

Bouke commented 2 years ago

I'm using C# 10 in my ASP.NET WebApplication (<LangVersion>10</LangVersion>). Using this SDK it seems this is not possible:

Invalid option '10' for /langversion. Use '/langversion:?' to list supported values.

Is there a way to make this work? FWIW I am building other libraries against .NET Framework 4.8 with C# 10.

binki commented 2 years ago

You probably have to update the version of Roslyn being pulled in. You might be able to specify in your project a newer version of Microsoft.Net.Compilers.Toolset.

Bouke commented 2 years ago

I've added the latest version of that package, but the error remains.

    <PackageReference Update="Microsoft.Net.Compilers.Toolset" Version="4.0.1" />
CZEMacLeod commented 2 years ago

The SDK pulls in 

<PackageReference Include="Microsoft.Net.Compilers.Toolset" Version="3.8.0" PrivateAssets="All"/>

automatically - as well as 

<PackageReference Include="Microsoft.CodeDom.Providers.DotNetCompilerPlatform" Version="3.6.0" />

unless you set the property ExcludeASPNetCompilers to true.

If you are using Microsoft.Build.CentralPackageVersions you can actually set these versions in your central packages file.

Because of the order, if you place it in your project file, I'm pretty sure your 

    <PackageReference Update="Microsoft.Net.Compilers.Toolset" Version="4.0.1" />

happens before the include so there will be nothing to update at that point. If you move that to Directory.Build.targets it should work though.

Alternatively use

<PropertyGroup>
    <ExcludeASPNetCompilers>true</ExcludeASPNetCompilers>
</PropertyGroup>
<ItemGroup>
    <PackageReference Include="Microsoft.Net.Compilers.Toolset" Version="4.0.1" PrivateAssets="All"/>
    <PackageReference Include="Microsoft.CodeDom.Providers.DotNetCompilerPlatform" Version="3.6.0" />
</ItemGroup>

I will also look at potentially updating the default version pulled in by the SDK to 4.0.1.

I'm not entirely sure if there is an updated version of the CodeDom Providers, which means the langversion available in your compiled pages might not support C# 10.

Bouke commented 2 years ago

Using version 4.0.66 with <MicrosoftNetCompilersToolset_Version>4.0.1</MicrosoftNetCompilersToolset_Version> gets rid of that error 👍. Thank you for your time and investigation.

Sadly I'm running into another issue which I hoped to get rid off by switching to Sdk-style project in the first place. My project builds fine on Windows (old-style csproj), but fails to build on macOS/Mono with the following error. I don't understand why this happens as MyLibrary builds just fine.

Assembly 'MyLibrary' with identity 'MyLibrary, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' uses 'System.Net.Http, Version=4.2.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' which has a higher version than referenced assembly 'System.Net.Http' with identity 'System.Net.Http, Version=4.1.1.3, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'

Warning MSB3277 : Found conflicts between different versions of "System.Net.Http" that could not be resolved.
There was a conflict between "System.Net.Http, Version=4.1.1.3, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" and "System.Net.Http, Version=4.2.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a".
"System.Net.Http, Version=4.1.1.3, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" was chosen because it was primary and "System.Net.Http, Version=4.2.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" was not.
References which depend on "System.Net.Http, Version=4.1.1.3, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" [/Users/bouke/.nuget/packages/system.net.http/4.3.4/ref/net46/System.Net.Http.dll].
/Users/bouke/.nuget/packages/system.net.http/4.3.4/ref/net46/System.Net.Http.dll
Project file item includes which caused reference "/Users/bouke/.nuget/packages/system.net.http/4.3.4/ref/net46/System.Net.Http.dll".
System.Net.Http
References which depend on "System.Net.Http, Version=4.2.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" [/Library/Frameworks/Mono.framework/Versions/6.12.0/lib/mono/4.8-api/System.Net.Http.dll].
/Users/bouke/Developer/MyProject/MyLibrary/bin/Debug/net48/MyLibrary.dll
Project file item includes which caused reference "/Users/bouke/Developer/MyProject/MyLibrary/bin/Debug/net48/MyLibrary.dll".
/Users/bouke/Developer/MyProject/MyLibrary/bin/Debug/net48/MyLibrary.dll
slang25 commented 2 years ago

That brings back some bad memories. I think this SO answer might help: https://stackoverflow.com/a/51424880/2225808

Bouke commented 2 years ago

Yes bad memories indeed. I thought I left those behind by migrating to PackageReference and auto binding redirects. And it has been working fine for years now on Windows (regular Framework 4.8).

Thanks for the suggestion. My project already has a transitive dependency on System.Buffers 4.5.1, and making that dependency explicit doesn't resolve the build warning. I suspect the bug is with Mono not resolving the System.Net.Http dependencies similar to framework v4.7.2 or 4.8, but I have yet to find proof of this.

CZEMacLeod commented 2 years ago

@Bouke Since the update to 4.0.66 deals with the c#10 issue, do you mind closing this? If there is something specific to the SDK which affects your binding redirects / package resolving process perhaps open a new issue about it. It should be noted, that using this on Linux/Mac with Mono is not really a supported scenario for this SDK and you are in for many other difficulties I suspect.