Default web templates to net5.0 #20748

dougbu · 2020-04-11T03:48:10Z

Updating the web templates to default to net5.0 instead of netcoreapp5.0.
Contributes towards dotnet/sdk#10756.

Continuing #19860 with different branches all 'round. (I couldn't push to @ViktorHofer's fork).

dougbu · 2020-04-11T03:56:08Z

Notes

#19860 (comment) (@MattGal)

We've never had BT.Pre queues, but the latter two do exist.

As a "source of truth", especially in these core-reduction times, https://helix.dot.net/api/2019-06-17/info/queues will always give a (huge, JSON formatted) accurate list of what's actually available

A less accurate (by virtue of just being an MD file), but relatively recently updated version describing what's available can be seen here: https://github.com/dotnet/arcade/blob/8ca46105193bd25c95af49bc6cd3604aaefec980/Documentation/AzureDevOps/AzureDevOpsOnboarding.md

I'm not sure why (will have to consult with @ChulHul ) but BuildPool.Server.Amd64.VS2019.Pre is still on 16.5.0-pre.2.0+29721.120 so is significantly older than 16.5.1 RTW.

#19860 (comment) (@wtgodbe)

To reiterate, these PR builds are running on BuildPool.Server.Amd64.VS2019.BT.Open and BuildPool.Server.Amd64.VS2019.Open

#19860 (comment) (@dougbu)

Correct @wtgodbe and those queues use VS 16.5.1. Unfortunately, if we switched to use BuildPool.Server.Amd64.VS2019.Pre and BuildPool.Server.Amd64.VS2019.Pre.Open for all Windows jobs i.e. ignored BuildTools options, we'd be moving to a version of VS from February. Unless there's a hack we haven't tried that works around the msbuild / nuget gaps, we need newer .Pre agents.

#19860 (comment) (@markwilkie)

We're hoping to get the .pre queues updated with latest by a week from Wednesday. (the 22nd) From then on, we'll be keeping more up to date, as well as providing a scouting queue.

wtgodbe · 2020-04-13T17:39:55Z

The version of Nuget.Client in VS16.5.1 is from November of last year: https://dev.azure.com/devdiv/DevDiv/_git/VS?path=%2F.corext%2FConfigs%2Fcomponents.json&version=GTrelease%2Fvs%2F16.5.1. The change we care about was made in March: NuGet/NuGet.Client@162e235. So 16.5.1 would appear to not be sufficient 😢. @rrelyea will we have to wait for 16.6 to get a version of VS w/ sufficient knowledge of the net5.0 TFM?

Pilchie · 2020-04-13T17:57:38Z

This is a restore time issue isn't it? Couldn't we restore with dotnet restore which will have the NuGet from the 5.0 SDK, even if we're later going to build with the desktop (VS) msbuild?

wtgodbe · 2020-04-13T20:00:51Z

This is a restore time issue isn't it

I believe it happens during the regular project build, after restore - it's an issue with net5.0 project (ProjectTemplates.Tests.csproj) referencing a netcoreapp5.0 project (Microsoft.AspNetCore.Server.IntegrationTesting.csproj) when nuget.client doesn't yet know that those 2 are the same thing

dougbu · 2020-04-13T20:03:54Z

Either way, I'm trying out using dotnet to restore in all Windows jobs. We don't have another option for a near-term release.

wtgodbe · 2020-04-13T20:08:38Z

.azure/pipelines/ci.yml

@@ -134,15 +126,6 @@ stages:
      # This is intentional to workaround https://github.com/dotnet/arcade/issues/1957 which always re-submits for code-signing, even
      # if they have already been signed. This results in slower builds due to re-submitting the same .nupkg many times for signing.
      # The sign settings have been configured to
-      - ${{ if ne(variables['System.TeamProject'], 'public') }}:


Why remove this? We'll have to add it back in if/when we do internal builds of net5 (CC @mmitche)

Yes, this should remain or it will have to be added back later.

I didn't remove it; I just moved the same steps up in default-build.yml to make sure it happens before running ./restore.cmd. The change also removes some duplication in the YAML.

@wtgodbe @mmitche put another way, this is no longer necessary anywhere the default-build.yml template is used.

Is this conversation resolved?

Pilchie · 2020-04-13T20:14:29Z

NuGet shouldn't be involved in the regular project build, only the restore phase (keeping in mind that dotnet build restore implicitly, though msbuild doesn't unless the /restore flag is passed).

dougbu · 2020-04-13T21:51:42Z

Current branch isn't working because (a) dotnet can't restore C++ projects and (b) executing ./build.cmd restores the projects (again) by default. Nothing proven yet one way or the other about the overall "don't use msbuild to restore" approach; more coming soon…

dougbu · 2020-04-13T22:35:47Z

.azure/pipelines/ci.yml

@@ -134,15 +126,6 @@ stages:
      # This is intentional to workaround https://github.com/dotnet/arcade/issues/1957 which always re-submits for code-signing, even
      # if they have already been signed. This results in slower builds due to re-submitting the same .nupkg many times for signing.
      # The sign settings have been configured to
-      - ${{ if ne(variables['System.TeamProject'], 'public') }}:


@wtgodbe @mmitche put another way, this is no longer necessary anywhere the default-build.yml template is used.

Is this conversation resolved?

dougbu · 2020-04-13T22:38:55Z

.azure/pipelines/ci.yml

@@ -163,6 +147,7 @@ stages:
                -all
                -buildNative
                -noBuildJava
+                -noRestore


I'm least sure about using -noRestore in this build job because it's goes back and forth between X64 and X86 builds multiple times and the bitness can change how some projects are restored. Will kick off an internal build to make sure I didn't break anything. (Could add more ./restore.cmd invocations if need be.)

https://dev.azure.com/dnceng/internal/_build/results?buildId=599183

Now https://dev.azure.com/dnceng/internal/_build/results?buildId=599363

dougbu · 2020-04-14T00:13:12Z

I need to focus almost exclusively on #20760 (spent too much time on this one today ☹️). Feel free to update this branch while I'm working elsewhere if latest try doesn't work.

dougbu · 2020-04-14T04:10:42Z

🆗 centralizing the Windows restore operations doesn't work quite right. Will spread the build steps for this out again after #20760.

dougbu · 2020-04-17T22:00:29Z

When I tried building with a newer VS locally, I saw lots of new warnings e.g.

C:\dd\dnx\aspnetcore\.dotnet\sdk\5.0.100-preview.2.20163.4\Sdks\NuGet.Build.Tasks.Pack\build\NuGet.Build.Tasks.Pack.targets(198,5): warning NU5118: File 'C:\dd\dnx\aspnetcore\artifacts\bin\dotnet-dev-certs\Release\netcoreapp5.0\publish\dotnet-dev-certs.deps.json' is not added because the package already contains file 'tools\netcoreapp5.0\any\dotnet-dev-certs.deps.json' [C:\dd\dnx\aspnetcore\src\Tools\dotnet-dev-certs\src\dotnet-dev-certs.csproj]
...
C:\dd\dnx\aspnetcore\.dotnet\sdk\5.0.100-preview.2.20163.4\Sdks\NuGet.Build.Tasks.Pack\build\NuGet.Build.Tasks.Pack.targets(198,5): warning NU5129: - At least one .targets file was found in 'build/netcoreapp5.0/', but 'build/net5.0/Microsoft.AspNetCore.Mvc.Testing.targets' was not. [C:\dd\dnx\aspnetcore\src\Mvc\Mvc.Testing\src\Microsoft.AspNetCore.Mvc.Testing.csproj]

Are these warnings something we should be concerned about @ViktorHofer❔

When restoring w/ dotnet, I get even more of the above plus two errors indicating too few projects are restored up front for a -noRestore build to succeed.

C:\dd\dnx\aspnetcore\.dotnet\sdk\5.0.100-preview.2.20163.4\Sdks\Microsoft.NET.Sdk\targets\Microsoft.PackageDependencyResolution.targets(234,5): error NETSDK1004: Assets file 'C:\dd\dnx\aspnetcore\artifacts\obj\TestClient\project.assets.json' not found. Run a NuGet package restore to generate this file. [C:\dd\dnx\aspnetcore\src\Servers\HttpSys\samples\TestClient\TestClient.csproj]
C:\dd\dnx\aspnetcore\src\Servers\IIS\build\testsite.props(73,5): error MSB3073: The command "dotnet C:\dd\dnx\aspnetcore\src\Servers\IIS\build\..\IIS\test\testassets\TestTasks\bin\Release\netcoreapp5.0\TestTasks.dll "C:\dd\dnx\aspnetcore\artifacts\obj\InProcessWebSite\Release\netcoreapp5.0\win-x64\InProcessWebSite.deps.json" win-x64 " exited with code 255. [C:\dd\dnx\aspnetcore\src\Servers\IIS\IIS\test\testassets\InProcessWebSite\InProcessWebSite.csproj]

Because we use $(RestoreAdditionalProjectSources) in a few places to pick up artifacts we just created, using dotnet restore everywhere we can is going to get very messy. So, I'm going to switch gears and use -ForceCoreMSBuild everywhere except when building Site Extensions or the Windows installers.

Tempted to change our -ForceCoreMSBuild switch to be ignored and add -noCoreMSBuild but that could mess up devs.

dougbu · 2020-04-21T03:28:41Z

@rrelyea according to the latest validation build w/ the scouting queue, msbuild or the NuGet components it carries in VS16.6.2 do not treat the .NET 5.0 TFMs as equivalent. Seeing a lot of errors like

error NU1202: Package Microsoft.Extensions.Internal.Transport 5.0.0-preview.4.20219.6 is not compatible with net50 (.NETFramework,Version=v5.0). Package Microsoft.Extensions.Internal.Transport 5.0.0-preview.4.20219.6 supports: netcoreapp5.0 (.NETCoreApp,Version=v5.0) [C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\Common7\IDE\CommonExtensions\Microsoft\NuGet\NuGet.targets]

Are hacks such as using dotnet for everything except C++ compiles the only viable approach for now? (We currently use desktop msbuild on Windows for almost everything.)

rrelyea · 2020-04-21T03:36:28Z

That smells like that nuget doesn’t understand that net5.0 is equivalent to netcoreapp5.0

(It still thinks it is .NetFramework :
net50 (.NETFramework,Version=v5.0)
)

In order for full framework msbuild to work, you need to install the right build of VS with nuget that knows about net5.0

dougbu · 2020-04-21T03:57:13Z

@rrelyea so, "VS 16.6 – Preview 2" (according to internal emails, what's on these scouting agents) isn't new enough -- still?

rrelyea · 2020-04-21T04:02:15Z

What build # is that preview 2 build?
One possibility: Perhaps it is not the latest preview2 build?

dougbu · 2020-04-21T05:35:46Z

@rrelyea sorry, looks like I tested with the wrong scouting queue. Will check back tomorrow…

wtgodbe · 2020-04-21T17:26:43Z

I'm hearing queues will be updated to 16.6 preview tomorrow morning

markwilkie · 2020-04-21T17:33:27Z

Yes, the following queues are slated to be updated to 16.6.0 Preview 2 tomorrow.
BuildPool.Server.Amd64.VS2019.Pre
BuildPool.Server.Amd64.VS2019.Pre.Open
BuildPool.Windows.10.Amd64.VS2019.Pre
BuildPool.Windows.10.Amd64.VS2019.Pre.Open
BuildPool.Windows.Amd64.VS2019.Pre.ES.Open

dougbu · 2020-04-21T19:08:18Z

The latest validation build is hitting similar problems to #21017. The agent updates won't solve our ills.

But, @rrelyea the validation build does look much better than the one I complained about last night. Sorry.

dougbu · 2020-05-11T00:36:51Z

I'm hoping we can unblock dotnet/razor#1873, trigger the subscription into this repo, and change the TFM everywhere. But, we'll probably need to build with dotnet msbuild where we can on Windows and I don't have that working yet. (A few too many managed projects reference C++ projects and don't build correctly when $(BuildNative) isn't true.)

dougbu · 2020-05-11T20:10:08Z

Closing in favour of #21630

dougbu mentioned this pull request Apr 11, 2020

Default web templates to net5.0 #19860

Closed

Pilchie added the area-mvc Includes: MVC, Actions and Controllers, Localization, CORS, most templates label Apr 13, 2020

wtgodbe reviewed Apr 13, 2020

View reviewed changes

dougbu commented Apr 13, 2020

View reviewed changes

This was referenced Apr 19, 2020

A quick collection of quick fixes #20993

Merged

Upgrade to more recent .NET SDK #21017

Merged

dougbu force-pushed the ViktorHofer/TemplateNet50Update branch from 972d990 to 644f977 Compare April 21, 2020 02:33

dougbu requested review from analogrelay, BrennanConroy, halter73, jkotalik, SteveSandersonMS and Tratcher as code owners April 21, 2020 02:33

dougbu requested a review from a team April 21, 2020 02:33

dougbu changed the base branch from release/5.0-preview3 to master April 21, 2020 02:33

dougbu force-pushed the ViktorHofer/TemplateNet50Update branch from 644f977 to cb32800 Compare April 21, 2020 02:35

mkArtakMSFT mentioned this pull request Apr 25, 2020

CLI does not set TFM net5.0 in .csproj #21206

Closed

ViktorHofer added 5 commits May 6, 2020 11:08

Default templates to net5.0

ebbe4f6

Update global.json to allow prerelease and rollforward

810ea29

Update required vs msbuild version

53d6b25

PR feedback

7a5a539

Update missing project templates tfms

60ae51c

dougbu force-pushed the ViktorHofer/TemplateNet50Update branch from 0587cf4 to 60ae51c Compare May 6, 2020 18:14

dougbu closed this May 11, 2020

dougbu deleted the ViktorHofer/TemplateNet50Update branch May 11, 2020 20:10

ViktorHofer mentioned this pull request May 11, 2020

[master] Update dependencies from dotnet/arcade dotnet/aspnetcore-tooling #21630

Merged

Default web templates to net5.0 #20748

Default web templates to net5.0 #20748

Uh oh!

Conversation

dougbu commented Apr 11, 2020

Uh oh!

dougbu commented Apr 11, 2020

Notes

#19860 (comment) (@MattGal)

#19860 (comment) (@wtgodbe)

#19860 (comment) (@dougbu)

#19860 (comment) (@markwilkie)

Uh oh!

wtgodbe commented Apr 13, 2020

Uh oh!

Pilchie commented Apr 13, 2020

Uh oh!

wtgodbe commented Apr 13, 2020

Uh oh!

dougbu commented Apr 13, 2020

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Pilchie commented Apr 13, 2020

Uh oh!

dougbu commented Apr 13, 2020

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dougbu commented Apr 14, 2020

Uh oh!

dougbu commented Apr 14, 2020

Uh oh!

dougbu commented Apr 17, 2020

Uh oh!

dougbu commented Apr 21, 2020

Uh oh!

rrelyea commented Apr 21, 2020

Uh oh!

dougbu commented Apr 21, 2020

Uh oh!

rrelyea commented Apr 21, 2020

Uh oh!

dougbu commented Apr 21, 2020

Uh oh!

wtgodbe commented Apr 21, 2020

Uh oh!

markwilkie commented Apr 21, 2020

Uh oh!

dougbu commented Apr 21, 2020

Uh oh!

dougbu commented May 11, 2020

Uh oh!

dougbu commented May 11, 2020

Uh oh!

Uh oh!