Upgrade to net9 #11535
Upgrade to net9 #11535
Conversation
|
I'm guessing this comment is not an issue any more? https://github.com/dotnet/razor/pull/11000/files#r1796869549 |
Hmm I'll take a look. From vs code side everything should be fine. I don't know why this would be a problem in vs but I'll kick off integration tests and a test insertion |
|
I know nothing about nothing, I was just mainly interested in how many more changes there are in @jjonescz's PR, but it is relatively old, so I wouldn't be surprised if it was working around things that now no longer need to be worked around. |
It probably would have been okay to upgrade but if we let Roslyn do it first then we avoid some work ;) We're roll forward so we're technically running net9 even if we target net8. The extension handles downloading the runtime as needed |
src/Razor/benchmarks/Microsoft.AspNetCore.Razor.Microbenchmarks/Resources.cs
Outdated
Show resolved
Hide resolved
Directory.Build.props
Outdated
| <NetVS>net8.0</NetVS> | ||
| <NetVSCode>net9.0</NetVSCode> | ||
| <NetVSAndVSCode>$(NetVS);$(NetVSCode)</NetVSAndVSCode> |
There was a problem hiding this comment.
Consider copying the approach taken in https://github.com/dotnet/roslyn/blob/b6ed7a5f13a3f00e7edf8cc4fab0d4524251f056/eng/targets/TargetFrameworks.props#L14-L22 even more. I.e., instead of setting these in the <Otherwise> block, declare and set them in the main <PropertyGroup> above and like the <Choose> just override them. That way, they're easy to update.
Also, consider renaming DefaultNetFxTargetFramework, since you're unifying the naming convention.
There was a problem hiding this comment.
Consider copying the approach taken in dotnet/roslyn@b6ed7a5/eng/targets/TargetFrameworks.props#L14-L22 even more. I.e., instead of setting these in the block, declare and set them in the main above and like the just override them. That way, they're easy to update.
SGTM :)
Also, consider renaming DefaultNetFxTargetFramework, since you're unifying the naming convention.
To NetFxVS?
| @@ -1,7 +1,7 @@ | |||
| <Project Sdk="Microsoft.NET.Sdk"> | |||
|
|
|||
| <PropertyGroup> | |||
| <TargetFrameworks>$(DefaultNetCoreTargetFrameworks);netstandard2.0;$(DefaultNetFxTargetFramework)</TargetFrameworks> | |||
| <TargetFrameworks>$(NetVSAndVSCode);netstandard2.0;$(DefaultNetFxTargetFramework)</TargetFrameworks> | |||
There was a problem hiding this comment.
This is outside of the scope of your PR, but I wonder if Razor tooling still needs to compile anything with netstandard2.0? I believe we only ship net8.0 binaries in service hub.
[View Complete Diff of Changes](https://github.com/dotnet/razor/compare/2798396c3481573aa49f9c792179ebbb5e183dca...c0bd75d99369adcd5a2f7e1f1ac42bee8a3bf619?w=1) * Move VS Code To Pull Diagnostics (#11602) (PR: [#11602](dotnet/razor#11602)) * Upgrade to net9 (#11535) (PR: [#11535](dotnet/razor#11535)) * Cleanup CompletionTriggerAndCommitCharacters (#11600) (PR: [#11600](dotnet/razor#11600)) * Add constraints to CaptureParameters method (#11530) (PR: [#11530](dotnet/razor#11530)) * [main] Update dependencies from dotnet/source-build-reference-packages (#11598) (PR: [#11598](dotnet/razor#11598)) * [FUSE] Layout mapping (#11567) (PR: [#11567](dotnet/razor#11567)) * Stop running cohosting tests with and without FUSE (#11592) (PR: [#11592](dotnet/razor#11592))
| <DefaultNetCoreTargetFrameworks>$(DefaultNetCoreTargetFramework)</DefaultNetCoreTargetFrameworks> | ||
| <NetVS>$(NetCurrent)</NetVS> | ||
| <NetVSCode>$(NetCurrent)</NetVSCode> | ||
| <NetVSAndVSCode>$(NetVS);$(NetVSCode)</NetVSAndVSCode> |
There was a problem hiding this comment.
This looks wrong. When building the product from source, only the latest TFM should get built. See roslyn's defines as an example: https://github.com/dotnet/roslyn/blob/c02ed62551e0880585f14b511cc1b9ba4c48bcf2/eng/targets/TargetFrameworks.props#L53-L61
Is there any reason why those older TFMs got added? cc @dotnet/source-build @jaredpar
There was a problem hiding this comment.
So only $(NetCurrent) should be built? I can fix
This will be needed for the new EA so putting in a separate PR