Default web templates to net5.0 #19860

ViktorHofer · 2020-03-14T20:52:59Z

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

This is required for preview2 which closes down EOW.

mkArtakMSFT · 2020-03-15T18:44:19Z

@pranavkm can you please review this early in the week (Monday, Tuesday)? We need to get this in early in the week.

pranavkm

The template change looks alright to me, but I'd prefer if someone from @dotnet/aspnet-build signs off on the other changes in the PR

ViktorHofer · 2020-03-16T13:57:56Z

I don't understand why builds are failing with requiring a newer msbuild even though I didn't update the global.json's sdk value. Just updating the dotnet value should only impact which version is bootstrapped but not which minimum version is required by desktop msbuild...

eng/Workarounds.targets

global.json

dougbu · 2020-03-16T14:54:54Z

src/ProjectTemplates/build.cmd

@@ -1,3 +1,3 @@
 @ECHO OFF
 SET RepoRoot=%~dp0..\..
-%RepoRoot%\build.cmd -projects %~dp0*\*.*proj "/p:EnforceE2ETestPrerequisites=true" %*
+%RepoRoot%\build.cmd -projects %~dp0*\*.*proj -ForceCoreMsbuild "/p:EnforceE2ETestPrerequisites=true" %*


Why is -ForceCoreMsbuild needed?

ViktorHofer · 2020-03-16T15:04:19Z

@dougbu thanks for reviewing this. It would great if you can help me with #19860 (comment).

dougbu

Just updating the dotnet value should only impact which version is bootstrapped but not which minimum version is required by desktop msbuild...

But the CI build will use the bootstrapped SDK and that requires a newer version of VS.

What surprises me is the lack of 16.5 on the Windows agents. @MattGal shouldn't the BuildPool.Server.Amd64.VS2019.BT.Open agents be more up-to-date?

global.json

MattGal · 2020-03-16T16:15:53Z

Just updating the dotnet value should only impact which version is bootstrapped but not which minimum version is required by desktop msbuild...

But the CI build will use the bootstrapped SDK and that requires a newer version of VS.

What surprises me is the lack of 16.5 on the Windows agents. @MattGal shouldn't the BuildPool.Server.Amd64.VS2019.BT.Open agents be more up-to-date?

Latest public version of VS 2019 is 16.4.6. The VS 2019 BT queues currently have 16.4.3. Since that's not a preview queue, until some time after that's publicly released I don't think they should be more up-to-date as that would require running a Preview SKU.

(2019 "Pre" queues have 16.5.0 Preview 2.0)

ViktorHofer · 2020-03-16T16:20:44Z

Thanks Matt for the infos. I pinged @jaredpar who will update the RoslynTools.MSBuild package (which contains an xcopyable verison of MSBuild) to 16.5.0 preview. This will allow us to require a newer vs version in global.json which will fix the current failures.

dougbu · 2020-03-16T16:57:52Z

I think another option may be to change the .azure/pipelines/jobs/default-build.yaml file to switch the pools to BuildPool.Server.Amd64.VS2019.BT.Pre.Open and BuildPool.Server.Amd64.VS2019.BT.Pre. (Did I get those names right @MattGal?)

MattGal · 2020-03-16T17:09:05Z

I think another option may be to change the .azure/pipelines/jobs/default-build.yaml file to switch the pools to BuildPool.Server.Amd64.VS2019.BT.Pre.Open and BuildPool.Server.Amd64.VS2019.BT.Pre. (Did I get those names right @MattGal?)

Neither of those queues exist. Basically we only started having these before we'd figured out how to properly automatically activate VS on our machines, and the time-bomb prompts were causing some builds to hang. We've solved the activation issue for some time, so the only preview VSes we have are Enterprise Preview.

You could try these two:

buildpool.server.amd64.vs2019.pre
buildpool.server.amd64.vs2019.pre.open

But if it's at all possible (we recognize that it isn't always) you should bootstrap such pre-release dependencies as part of your builds as Viktor mentions. There are other benefits to this as well, such as making OSS contributors able to build and run without having to install prerelease VS themselves.

ViktorHofer · 2020-03-17T15:19:02Z

Unfortunately that didn't solve the issue as the RoslynTools.MSBuild package doesn't contain VC++ assets. @MattGal 16.5 was released yesterday, when will the queues be updated? Regarding the Pre queues, I don't see a BT one for pre.

MattGal · 2020-03-17T16:25:54Z

Unfortunately that didn't solve the issue as the RoslynTools.MSBuild package doesn't contain VC++ assets. @MattGal 16.5 was released yesterday, when will the queues be updated? Regarding the Pre queues, I don't see a BT one for pre.

I'm checking in with DDFUN folks; there's a PR out that updates these images right now but I'm uncertain whether it picks up the latest VSes. (We do not, and have not had preview queues for buildtools sku. Not sure why people are suddenly asking for it?)

jaredpar · 2020-03-17T16:29:34Z

@MattGal is this also going to silently roll runtime repositories native toolset forward again? If we're just updating the images in place it seems like we're going to be doing this.

MattGal · 2020-03-17T16:32:23Z

@MattGal is this also going to silently roll runtime repositories native toolset forward again? If we're just updating the images in place it seems like we're going to be doing this.

Yes, except for the silent part (there will be a partners mail before such a rollout). I believe this will also bring the updated CMake that doesn't produce the warnings that were causing issues. There are options to the buildpool.windows machines; you can also use the (silently upgraded whenever they want as well) hosted-build machines, or bootstrap all your build dependencies at your discretion.

jaredpar · 2020-03-17T16:36:32Z

@MattGal

bootstrap all your build dependencies at your discretion.

This has been discussed endlessly and every time the conclusion is that this is not a viable option for native toolsets.

Yes, except for the silent part (there will be a partners mail before such a rollout).

Are we testing it? The official builds for dotnet/runtime have been on the floor for almost a week now due to an untested arcade publishing changes. Just now as we're getting past that we're going to get another untested change to the infrastructure. The expectation here, given the history, should be that this will cause further instability.

We've proposed solutions to this problem, specifically dotnet/arcade#5018, but we're getting no traction on the discussion.

@jkotas, @jkoritzinsky as FYI that this is likely coming our way.

MattGal · 2020-03-17T16:45:45Z

Are we testing it? The official builds for dotnet/runtime have been on the floor for almost a week now due to an untested arcade publishing changes.

Yes, we can absolutely run a set of your builds through the staging environment before this rolls out. I'll coordinate it with @ilyas1974 once the changes are made and in (hopefully tomorrow)

v-joshli · 2020-03-17T22:46:42Z

Hello,

Casey has completed the VS2019 images. The names are:
Helix-Client-Enterprise-RS5-VS2019BuildTools-03-17-2020
Helix-Client-Enterprise-RS5-VS2019Enterprise-03-17-2020
Helix-Server-DataCenter-RS5-VS2019BuildTools-03-17-2020
Helix-Server-Datacenter-RS5-VS2019Enterprise-03-17-2020

Thanks,
Josh

wtgodbe · 2020-04-08T19:44:50Z

Would be because we reference that project directly, and it targets netcoreapp5.0:

aspnetcore/src/ProjectTemplates/test/ProjectTemplates.Tests.csproj

Line 47 in 26020ed

<ProjectReference Include="$(RepoRoot)src\Hosting\Server.IntegrationTesting\src\Microsoft.AspNetCore.Server.IntegrationTesting.csproj" />

Can we get away with multitargeting either the projectTemplate test project, or Microsoft.AspNetCore.Server.IntegrationTesting?

wtgodbe · 2020-04-08T20:07:42Z

@dougbu am I reading this thread correctly, that the issue I mentioned in the comment above was supposed to be fixed by updating the machine pool to one w/ a VS new enough to have a Nuget that knows about net50?

Pilchie · 2020-04-08T20:10:08Z

fixed by updating the machine pool to one w/ a VS new enough to have a Nuget that knows about net50?

Actually, an SDK with a new enough NuGet, but that SDK required a newer desktop msbuild (which comes with VS). The updated machine pool that was rolled out yesterday was supposed to unblock this.

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

The updated machine pool that was rolled out yesterday was supposed to unblock this.

Was there a thread/issue about that pool? Want to make sure we're using the right one(s) in this PR

wtgodbe · 2020-04-08T20:21:44Z

Hmm, we are definitely using the machines that have been updated to VS 16.5.1:

aspnetcore/.azure/pipelines/jobs/default-build.yml

Lines 95 to 107 in 26020ed

    
           ${{ if eq(parameters.agentOs, 'Windows') }}: 
        
             ${{ if eq(variables['System.TeamProject'], 'public') }}: 
        
               name: NetCorePublic-Pool 
        
               ${{ if ne(parameters.isTestingJob, true) }}: 
        
                 # Visual Studio Build Tools 
        
                 queue: BuildPool.Server.Amd64.VS2019.BT.Open 
        
               ${{ if eq(parameters.isTestingJob, true) }}: 
        
                 # Visual Studio Enterprise - contains some stuff, like SQL Server and IIS Express, that we use for testing 
        
                 queue: BuildPool.Server.Amd64.VS2019.Open 
        
             ${{ if eq(variables['System.TeamProject'], 'internal') }}: 
        
               name: NetCoreInternal-Pool 
        
               # Visual Studio Enterprise - contains some stuff, like SQL Server and IIS Express, that we use for testing 
        
               queue: BuildPool.Server.Amd64.VS2019

Pilchie · 2020-04-08T20:27:51Z

@markwilkie @jaredpar any ideas?

MattGal · 2020-04-08T20:32:55Z

@markwilkie @jaredpar any ideas?

I'll take a look too just in case those guys are busy

markwilkie · 2020-04-08T20:36:57Z

Sorry, beyond confirming that the following queues have been updated to 16.5.1 on Monday, I don't have much insight.

BuildPool.Server.Amd64.VS2019.BT.Open
BuildPool.Server.Amd64.VS2019.Open
BuildPool.Server.Amd64.VS2019
Windows.Server.Amd64.VS2019.BT.Open
BuildPool.Server.Amd64.VS2019.BT

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

Do we know what version of Nuget.Client first knew about the net50 TFM? I'm trying to confirm that the SDK we're using actually does have a new enough Nuget

MattGal · 2020-04-08T20:40:56Z

I confirmed the builds are running on agents using the BuildPool.Server.Amd64.VS2019.BT.Open/versions/2020.0403.135905 image; whatever version came with 16.5.1 buildtools is on the machine. I'll poke about a bit more but I think this may just be expecting VS 16.5.1 to have something it might not have in box.

wtgodbe · 2020-04-08T21:17:47Z

Newer SDK didn't help. I don't know exactly what the requirements are here - a specific version of Nuget/Msbuild/something else on the machine/in the SDK? It appears some combination of those things is required to allow us to reference a netcoreapp5.0 project from a net50 project - @jaredpar do you know?

Pilchie · 2020-04-08T21:36:47Z

Also tagging @ericstj.

ericstj · 2020-04-09T01:46:36Z

So I believe this failure is in nuget restore. From the logs it appears to be using desktop MSBuild from VS. I believe you need to update the version of VS on the build machine to have a new nuget that understands the TFM. Has that been done?

dougbu · 2020-04-09T01:52:32Z

I believe you need to update the version of VS on the build machine to have a new nuget that understands the TFM. Has that been done?

Well, we thought so… 😈

I would add that from what @wtgodbe and @MattGal are seeing / saying, VS 16.5.1 isn't new enough ☹️

ericstj · 2020-04-09T01:54:44Z

You need the VS that has our preview2 bits inserted i think.

Pilchie · 2020-04-09T02:35:17Z

We don’t insert .NET 5 bits into VS yet, but I think that 16.5 has a new MSBuild and NuGet which *does* understand the new TFM. — Kevin Pilch https://twitter.com/Pilchie

…

________________________________ From: Eric StJohn <[email protected]> Sent: Wednesday, April 8, 2020 6:54:58 PM To: dotnet/aspnetcore <[email protected]> Cc: Kevin Pilch <[email protected]>; Mention <[email protected]> Subject: Re: [dotnet/aspnetcore] Default web templates to net5.0 (#19860) You need the VS that has our preview2 bits inserted i think. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fi.8713187.xyz%2Fdotnet%2Faspnetcore%2Fpull%2F19860%23issuecomment-611283766&data=02%7C01%7Ckevinpi%40microsoft.com%7C1eb815d980e94c5629d708d7dc29024c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637219940995506644&sdata=T6g39j26MI3zhoX%2B7BI99q3I4twZQJXJ2d82ttAFLPM%3D&reserved=0>, or unsubscribe<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fi.8713187.xyz%2Fnotifications%2Funsubscribe-auth%2FAACMMA3HAFODPSBG7J6TBPLRLUTHFANCNFSM4LJXXQCA&data=02%7C01%7Ckevinpi%40microsoft.com%7C1eb815d980e94c5629d708d7dc29024c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637219940995506644&sdata=2M5%2FNPnJIA3ihjd6zWEt%2FCEejL%2FD78Mk2TgsNINPS4I%3D&reserved=0>.

dougbu · 2020-04-09T04:38:21Z

I think our main option here is to confirm 6.5.1 has an older msbuild or nuget than we need then switch to BuildPool.Server.Amd64.VS2019.Pre queues and similar.

@MattGal is there an updated list of queues available somewhere? If not, are these the correct names of preview queues that are similar to what we tend to use?

BuildPool.Server.Amd64.VS2019.BT.Pre
BuildPool.Server.Amd64.VS2019.BT.Pre.Open
BuildPool.Server.Amd64.VS2019.Pre
BuildPool.Server.Amd64.VS2019.Pre.Open

MattGal · 2020-04-09T15:23:55Z

I think our main option here is to confirm 6.5.1 has an older msbuild or nuget than we need then switch to BuildPool.Server.Amd64.VS2019.Pre queues and similar.

@MattGal is there an updated list of queues available somewhere? If not, are these the correct names of preview queues that are similar to what we tend to use?

BuildPool.Server.Amd64.VS2019.BT.Pre

BuildPool.Server.Amd64.VS2019.BT.Pre.Open

BuildPool.Server.Amd64.VS2019.Pre

BuildPool.Server.Amd64.VS2019.Pre.Open

Some notes:

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.

wtgodbe · 2020-04-09T16:27:05Z

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

dougbu · 2020-04-09T16:34:57Z

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.

markwilkie · 2020-04-09T17:32:41Z

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.

Pilchie · 2020-04-10T18:08:48Z

Why closed?

dougbu · 2020-04-10T23:52:52Z

Sorry I missed your question @Pilchie. Closing this was a side-effect of removing the underlying (dead) preview2 branch. I'll move it to target 'master' soon.

Pilchie · 2020-04-10T23:56:31Z

Let's rather make it Preview3 as that's what we're targeting for the change

dougbu · 2020-04-11T03:57:04Z

See #20748 for the future of this work

ViktorHofer force-pushed the TemplateNet50Update branch 2 times, most recently from 2193024 to 0860039 Compare March 15, 2020 12:07

ViktorHofer mentioned this pull request Mar 15, 2020

Support net5.0 dotnet/sdk#10756

Closed

10 tasks

Default templates to net5.0

f45f4e3

ViktorHofer force-pushed the TemplateNet50Update branch from 0860039 to f45f4e3 Compare March 15, 2020 13:23

mkArtakMSFT requested a review from pranavkm March 15, 2020 18:41

mkArtakMSFT added the area-mvc Includes: MVC, Actions and Controllers, Localization, CORS, most templates label Mar 15, 2020

pranavkm reviewed Mar 16, 2020

View reviewed changes

Update global.json to allow prerelease and rollforward

4472da1

ViktorHofer force-pushed the TemplateNet50Update branch from a8f6f61 to 4472da1 Compare March 16, 2020 14:50

dougbu reviewed Mar 16, 2020

View reviewed changes

global.json Outdated Show resolved Hide resolved

ViktorHofer added 2 commits March 16, 2020 21:32

Update required vs msbuild version

81698d2

PR feedback

05d74f7

Update queues to use 16.5

47ed39a

Pilchie mentioned this pull request Mar 17, 2020

Update .NET Core Sdk version dotnet/razor#1692

Closed

Try newer SDK

99d7b08

Revert to slightly older SDK

b825f6b

BrennanConroy mentioned this pull request Apr 9, 2020

Updating sdk/tooling version #20708

Closed

dougbu closed this Apr 10, 2020

dougbu mentioned this pull request Apr 11, 2020

Default web templates to net5.0 #20748

Closed

Default web templates to net5.0 #19860

Default web templates to net5.0 #19860

Uh oh!

Conversation

ViktorHofer commented Mar 14, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mkArtakMSFT commented Mar 15, 2020

Uh oh!

pranavkm left a comment

Choose a reason for hiding this comment

Uh oh!

ViktorHofer commented Mar 16, 2020

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

dougbu Mar 16, 2020

Choose a reason for hiding this comment

Uh oh!

ViktorHofer commented Mar 16, 2020

Uh oh!

dougbu left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

MattGal commented Mar 16, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ViktorHofer commented Mar 16, 2020

Uh oh!

dougbu commented Mar 16, 2020

Uh oh!

MattGal commented Mar 16, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ViktorHofer commented Mar 17, 2020

Uh oh!

MattGal commented Mar 17, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jaredpar commented Mar 17, 2020

Uh oh!

MattGal commented Mar 17, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jaredpar commented Mar 17, 2020

Uh oh!

MattGal commented Mar 17, 2020

Uh oh!

v-joshli commented Mar 17, 2020

Uh oh!

wtgodbe commented Apr 8, 2020

Uh oh!

wtgodbe commented Apr 8, 2020

Uh oh!

Pilchie commented Apr 8, 2020

Uh oh!

wtgodbe commented Apr 8, 2020

Uh oh!

wtgodbe commented Apr 8, 2020

Uh oh!

Pilchie commented Apr 8, 2020

Uh oh!

MattGal commented Apr 8, 2020

Uh oh!

markwilkie commented Apr 8, 2020

Uh oh!

wtgodbe commented Apr 8, 2020

Uh oh!

MattGal commented Apr 8, 2020

Uh oh!

wtgodbe commented Apr 8, 2020

Uh oh!

Pilchie commented Apr 8, 2020

Uh oh!

ericstj commented Apr 9, 2020

Uh oh!

dougbu commented Apr 9, 2020

ViktorHofer commented Mar 14, 2020 •

edited

Loading

MattGal commented Mar 16, 2020 •

edited

Loading

MattGal commented Mar 16, 2020 •

edited

Loading

MattGal commented Mar 17, 2020 •

edited

Loading

MattGal commented Mar 17, 2020 •

edited

Loading