-
Notifications
You must be signed in to change notification settings - Fork 10k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove the cast from the empty web project template #33393
Conversation
davidfowl
commented
Jun 9, 2021
- Remove the cast from the empty web project template
@@ -4,6 +4,7 @@ | |||
<TargetFramework>${DefaultNetCoreTargetFramework}</TargetFramework> | |||
<NoDefaultLaunchSettingsFile Condition="'$(ExcludeLaunchSettings)' == 'True'">True</NoDefaultLaunchSettingsFile> | |||
<RootNamespace Condition="'$(name)' != '$(name{-VALUE-FORMS-}safe_namespace)'">Company.WebApplication1</RootNamespace> | |||
<LangVersion>preview</LangVersion> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we'll be able to remove this when we get a new SDK.
cc @jaredpar
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will go away in .NET 6 P7.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jaredpar can you help me understand this better as the docs seem to say preview frameworks will always default to their matching preview language: https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/configure-language-version
When your project targets a preview framework that has a corresponding preview language version, the language version used is the preview language version. You use the latest features with that preview in any environment, without affecting projects that target a released .NET Core version.
It looks like
|
@halter73 we should use the Microsoft.Net.Compilers.Toolset version from eng/Versions.props everywhere, even on Helix machines when testing templates (because they're special-cased). If that covers the complete "preview compiler", everything should be fine. Unfortunately the Helix logs are far too detailed to be useful. The one interesting bit is
This may indicate the SDK (or something) attempts to override https://github.com/dotnet/aspnetcore/blob/main/eng/Versions.props#L159 (which hasn't changed in a couple of months). I'm not sure what version it falls back to. |
@dougbu we need to check in changes that will work with the latest VS and SDK before preview6 ships. There seems be an issue with ingestion of newer bits here and that's blocking this change. I don't really understand how any of this works can you help diagnose this please? |
/azp run |
Azure Pipelines successfully started running 2 pipeline(s). |
So I have a clue, when I build a sample in this repository with LangVersion set to preview I see this in a binlog:
Any ideas @dougbu ? This might be an arcade question... The exact same code builds fine outside of this repo with the same outer command line. |
I think it's coming from here Line 160 in 9fd548f
|
OK I figured it out. Lets see if it breaks the entire repo 😄 |
/azp run |
Azure Pipelines successfully started running 2 pipeline(s). |
Feel free to let me know if this change is crazy because I removed some fundamental piece of infrastructure. |
<PackageReference Include="Microsoft.Net.Compilers.Toolset" | ||
Version="${MicrosoftNetCompilersToolsetVersion}" | ||
PrivateAssets="all" | ||
IsImplicitlyDefined="true" /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we know why this was here before?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know, we'll see if something breaks. I spoke to Doug and he's going to follow up and do some research.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@wtgodbe introduced this long ago (for a 3.0.0 preview) in 23a6e3e / #11818. We were reacting to a Roslyn breaking change and needed a newer toolset than Arcade (think we set $(UsingToolMicrosoftNetCompilers)
at one point) or msbuild
references by default. Maestro++ managed the version for a while but we stopped that at some point. @BrennanConroy and @pranavkm were among the few to change the version after we made the version manual.
I don't remember the details of the breaking change but it had something to do w/ nullability annotations and @roji did relevant work in the efcore repo. @jaredpar may know though he wasn't involved in the conversation back in the summer of 2019.
As a follow up, we should do one of
- change the manually-controlled toolset version and re-introduce this package reference
- clean up
Line 160 in 8ee0b03
<MicrosoftNetCompilersToolsetVersion>3.10.0-1.final</MicrosoftNetCompilersToolsetVersion> - enable
$(UsingToolMicrosoftNetCompilers)
, meaning Arcade updates will bump the toolset version on occasion
I don't know enough about the toolset to have an opinion on which choice is best. @jaredpar❔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In general repositories should avoid explicitly referencing this package and instead prefer the one that just comes with arcade. The arcade version is updated at a regular cadence (roughly every other week). The idea being that this update cadence means we're regularly pushing new versions of the compiler to our partners in .NET.
This type of change where the version is pinned should be reserved for cases where a breaking change, bug, etc ... hits the repo and you need to pause the updates until we get a fix out. That appears to be what happened here except we forget to undo the pin once the bug was fixed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The arcade version is updated at a regular cadence (roughly every other week).
Right now, the Arcade version (see https://github.com/dotnet/arcade/blob/05634736a53ee65b0d19cf913d77d1f5d4293ebc/eng/Versions.props#L37) is far behind what the SDK uses by default (see https://github.com/dotnet/sdk/blob/ef6249b3b034b12f127b0d3a72ea428979f44413/eng/Versions.props#L120). Right now Arcade is only at v3.10.0-4.21329.37
while the SDK is at v4.0.0-2.21354.7
. I suggest we simply remove our confusing $(MicrosoftNetCompilersToolsetVersion)
property and leave $(UsingToolMicrosoftNetCompilers)
unset i.e. my option (2). Agreed @dotnet/aspnet-build @jaredpar❔