5.0.100-alpha1-01483 SDK pulls down 3.0.0 preview 7 when netcoreapp3.0 tfm specified

[jkoritzinsky]

When building with the nightly 5.0.100-alpha1-01483 SDK and targeting netcoreapp3.0, the SDK will pull down 3.0.0 Preview 7 bits instead of newer previews.

This was initially discovered in https://github.com/dotnet/coreclr/issues/26578

That issue also has an MSBuild binlog that shows the issue (the KnownFrameworkReference for Microsoft.NETCore.App for tfm netcoreapp3.0 has PackageVersion=3.0.0-preview7-27912-14).

[livarcocc]

This is a known issue that will exist until 3.0 ships. We needed to pick an implicit version of 3.0 for 5.0 and at the time, P7 was the latest.

[weltkante]

But on a fresh VS 2019 preview this does pick the right bits somehow, and I think it also has a 3.0 preview out of the box. Just on a machine which had other previews installed before this doesn't work (and doesn't get repaired with repair install either).

So does this mean 5.0 nightlies are broken for the time being and its not possible to test fixes/features flowing into master branches currently? (unless setting up a fresh VS preview VM everytime)

Either way whatever the bug is, you should improve the behavior for future branches, otherwise the time between branching and actual release is kinda dead time for developers who want to work against master builds ...

[livarcocc]

We are currently focused on getting 3.0 out the door. That's is our highest priority. I am not sure I follow your issues regarding VS.

What this means, right now, is that if you use 5.0 to target 3.0, it will target a P7 runtime. If there is anything beyond that happening, please, share that with us.

[weltkante]

I am not sure I follow your issues regarding VS.

While trying to figure out what was wrong with my build I had setup a fresh VS 2019 preview + nightly build a few days ago, and it was actually taking the right comhost.dll not the one from P7. Taking the same project on my dev machine (same VS and nightly version) took it from P7, so I was assuming this was actually working and my dev machine was broken due to having a history of previous previews (repair install didn't change anything).

Now I'm trying to make a binlog of the successful build on the previously "fresh" machine but it stopped working, its also pulling in P7, no idea what is different now. Maybe never having built a 3.0 project and jumping right to 5.0 nightly did something different when being freshly installed. I don't have time to setup another machine so I'll just wait for the problem being adressed.

What this means, right now, is that if you use 5.0 to target 3.0, it will target a P7 runtime.

Is it actually possible to use 5.0 for something else than targeting 3.0, considering you mention it explicitely that I'm targeting 3.0? Wasn't aware of doing anything wrong, I'm just trying to build against nightly because WinForms is already flowing changes into master (5.0) which I'd like to test if they fix my problems. They are related to COM interop so I also need the comhost.dll working, at which point I was running into this build problem.

Anyways, I understand that 3.0 release got priority, but it'd be great if this problem can be fixed in general for future major branches (not just for 3.0 vs 5.0) so the next time there isn't a downtime of several weeks before being able to continue using nightly builds of master.

[weltkante]

For anyone else coming across this, apparently the .NET 5 nightly SDK has been (and still is) broken and unusable. I have come across another issue where you can't compile netcoreapp3.1 at all when you have 5.0 SDK installed. Apparently the only option is to uninstall the .NET 5 SDK.

@livarcocc it would be great if the experience can be improved in the future, I basically have the choice between continuous uninstall/reinstall cycles of SDKs depending on what I want to test, setting up separate VMs for separate SDKs, or just not doing anything for a few months.

Considering that the SDKs install side-by-side I'd expect them to actually work side-by-side and not be fixed using the newest SDK (which then is not maintained for several months)

[nguerrera]

You can use global.json to pick a different SxS installed SDK. Sorry I was unclear on the other thread about that.

However, it is the case that .NET 5 SDK is not in great shape right now. The focus is on getting 3.0.101 and 3.1.100 out. These are shipping soon and have higher priority. Generally, you can always expect rough edges when using nightly builds instead of official previews, and in the very early days of a new major version, you can expect very rough edges.

[weltkante]

Being able to specify in global.json when I don't need the nightly SDK is a good thing, thanks. Unfortunately it wouldn't have helped in this particular case.

This isn't going to be the last version switch, so maybe in the future it can be arranged to be smoother? The fix I wanted to look at in this issue is only in 5.0 so not being able to use the SDK of the master branch for months (across both the 3.0 and 3.1 release) is a bit worse than "rough edges".

(To be honest I don't know the state of this particular issue, didn't get around to retry yet, but I do want to get some attention on the general workflow of version switches in the future.)

[nguerrera]

This particular issue and the one we were discussing on the other thread (being unable to target 3.1 with 5.0) should be fixed as of a PR I just merged.

I appreciate wanting things to go smoother, but we are doing as much as we can as fast as we can. 5.0 is way out and can afford to take longer to stabilize and so it gets attention with lower priority than 3.0.x and 3.1.x.