Default web templates to net5.0#19860
Conversation
2193024 to
0860039
Compare
0860039 to
f45f4e3
Compare
|
@pranavkm can you please review this early in the week (Monday, Tuesday)? We need to get this in early in the week. |
pranavkm
left a comment
There was a problem hiding this comment.
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
|
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... |
a8f6f61 to
4472da1
Compare
| @ECHO OFF | ||
| SET RepoRoot=%~dp0..\.. | ||
| %RepoRoot%\build.cmd -projects %~dp0*\*.*proj "/p:EnforceE2ETestPrerequisites=true" %* | ||
| %RepoRoot%\build.cmd -projects %~dp0*\*.*proj -ForceCoreMsbuild "/p:EnforceE2ETestPrerequisites=true" %* |
There was a problem hiding this comment.
Why is -ForceCoreMsbuild needed?
|
@dougbu thanks for reviewing this. It would great if you can help me with #19860 (comment). |
dougbu
left a comment
There was a problem hiding this comment.
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) |
|
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. |
|
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: 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. |
|
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?) |
|
@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. |
This has been discussed endlessly and every time the conclusion is that this is not a viable option for native toolsets.
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. |
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) |
|
Hello, Casey has completed the VS2019 images. The names are: Thanks, |
|
Would be because we reference that project directly, and it targets Can we get away with multitargeting either the projectTemplate test project, or |
|
@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 |
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. |
Was there a thread/issue about that pool? Want to make sure we're using the right one(s) in this PR |
|
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 |
|
@markwilkie @jaredpar any ideas? |
I'll take a look too just in case those guys are busy |
|
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 |
|
Do we know what version of |
|
I confirmed the builds are running on agents using the |
|
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 |
|
Also tagging @ericstj. |
|
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? |
|
You need the VS that has our preview2 bits inserted i think. |
|
I think our main option here is to confirm 6.5.1 has an older @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?
|
Some notes:
|
|
To reiterate, these PR builds are running on |
|
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 |
|
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. |
|
Why closed? |
|
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. |
|
Let's rather make it Preview3 as that's what we're targeting for the change |
|
See #20748 for the future of this work |
Updating the web templates to default to net5.0 instead of netcoreapp5.0.
Contributes towards dotnet/sdk#10756.
cc @anurse @Pilchie
This is required for preview2 which closes down EOW.