Build pipeline failed to resolve CLI tooling after VS2019 installation

[mwpowellhtx]

We got errors in our build pipeline related to our internal CLI tooling failing to resolve correctly, in our estimation, following VS2019 installation.

Running the latest NuGet: Version: 5.3.0.6260

If it helps, our dotnet --info looks like this:

.NET Core SDK (reflecting any global.json):
 Version:   3.0.100
 Commit:    04339c3a26

Runtime Environment:
 OS Name:     Windows
 OS Version:  6.1.7601
 OS Platform: Windows
 RID:         win7-x64
 Base Path:   C:\Program Files\dotnet\sdk\3.0.100\

Host (useful for support):
  Version: 3.0.0
  Commit:  7d57652f33

.NET Core SDKs installed:
  2.1.104 [C:\Program Files\dotnet\sdk]
  2.1.202 [C:\Program Files\dotnet\sdk]
  2.1.401 [C:\Program Files\dotnet\sdk]
  2.1.402 [C:\Program Files\dotnet\sdk]
  2.1.403 [C:\Program Files\dotnet\sdk]
  2.1.500 [C:\Program Files\dotnet\sdk]
  2.1.502 [C:\Program Files\dotnet\sdk]
  2.1.503 [C:\Program Files\dotnet\sdk]
  2.1.504 [C:\Program Files\dotnet\sdk]
  2.1.505 [C:\Program Files\dotnet\sdk]
  2.1.507 [C:\Program Files\dotnet\sdk]
  2.1.508 [C:\Program Files\dotnet\sdk]
  2.1.509 [C:\Program Files\dotnet\sdk]
  3.0.100 [C:\Program Files\dotnet\sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.1.3 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.1.4 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.1.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.1.6 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.1.7 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.1.8 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.1.9 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.1.11 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.1.12 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.1.13 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.3 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.1.4 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.1.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.1.6 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.1.7 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.1.8 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.1.9 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.1.11 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.1.12 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.1.13 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.0.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.0.6 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.0.9 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.3 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.4 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.6 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.8 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.9 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.11 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.12 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.13 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 3.0.0 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

[mwpowellhtx]

We thought at first this might require setting ToolsVersion="15.0" in all of our projects, to no avail.

Our CLI tooling is targeting netcoreapp2.1, specifically.

Eventually, we drudged up the solution, global.json (or one of its derivatives, i.e. project.json?), and after consulting with this decoder ring, we set the most appropriate compatible VS2017 sdk.version.

This has resolved the issue, but I'm not sure then how we "share" projects among mixed environments? i.e. VS2017 and/or VS2019? Or does it matter? i.e. do we need to identify another sdk.version to run the same in a VS2019 environment? In other words, we need to support netcoreapp2.1, does this support extend into VS2019 at all? Or does support there abruptly end in a VS2017 environment? Further, what is there a seamless migration path allowing us to use either environment?

[dsplaisted]

You are supposed to be able to use the latest tools/SDK. Global.json is an escape hatch to use an older version of the tooling in case there is a bug, but I don't recommend it in general.

Can you provide more information about what is failing? It sounded like it was an issue with dotnet CLI tools. How are you trying to use them, and how are they failing?

Thanks!

[mwpowellhtx]

@dsplaisted Evidently not. The failure occurs trying to run the CLI tooling. I'm not sure it even restored the package in to begin with, and I can promise you the package was there and ready for the next phase(s) in the pipeline to consume it. The tooling builds at an earlier phase in the pipeline and packages as a standard NuGet package. All working just fine prior to the VS install.

Best guess, sounds like we possibly need a <RollForward/> comprehension at some level of the build pipeline. I think we might also be using the prefercliruntime mechanism as well.

[livarcocc]

Can you share what error you are getting and give us more details on your setup? As Daniel says, a latest SDK can target all previous TFMs, as in, it can build projects targeting older TFMs.

But, if you are trying to fun an application, you still need to install the runtime required by that app. It won't roll forward automatically for you. So, if as part of your process, you are creating a tool (which is a framework dependent app) that targets netcoreapp2.x, you need to install the matching runtime in the machine in order to run it. If I managed to grasp the issue here accurately.

[mwpowellhtx]

@livarcocc That sounds accurate. We've installed the VS environments, but since VS2019 was installed, the default runtime is 3.0. The pipeline worked before VS2019 was installed. The errors indicate along the lines netstandard2.0 and netcoreapp2.1 are not supported by the run time. The answer is for our CLI tool to include the roll forward flags in its project properties?

[livarcocc]

You could do that, to force your 2.1 app to run against a 3.0 runtime. Or, you can include a 2.x runtime in your VS environments as well. There are 2.x optional components in VS that you can select to install.

[mwpowellhtx]

@livarcocc I'm not sure what that means. When I go to command prompt and dotnet --info the run times are enumerated, including the one(s) supporting netcoreapp2.1. However, the default is 3.0, hence the solution/project needs help forcing the issue. So... I think it was mentioned in another thread, but the mention escapes me. There is a project property we can use to help relax that dependency a bit? However, I am unclear where that gets declared. I thought perhaps in the CLI tooling project, but correct me if I am wrong about that.

[livarcocc]

Can you share with us the exact error code you are getting?

[mwpowellhtx]

@livarcocc I do not have it right in front of me. After some digging, discovered it was the CLI runtime that was the issue, following VS2019 installation. We have circumvented the issue for the moment using global.json, but what is the project property (or properties) that we can use to allow the correct runtime to be used when it comes time for our CLI invocation to occur properly. Otherwise it trips up because netcoreapp2.1 is not supported by 3.0.

[livarcocc]

that's the thing @mwpowellhtx, I don't understand what you mean by netcoreapp2.1 is not support by netcoreapp3.0. Do you mean that an app targeting netcoreapp2.1 won't run against netcoreapp3.0?

If that's the case, you can set <Rollforward>. You can see what the allowed values for it are here: https://devblogs.microsoft.com/dotnet/announcing-net-core-3-0-preview-5/.

By the way, that's the case because there is no guaranteed compatibility between major versions of the runtime. If you opt in to roll forward for major versions, you should validate your app running against 3.0.

However, if you do have 2.1 and 3.0 runtime installed in the box next to each other and your app targets 2.1, that runtime should be picked up and used.

Please share more details and the error message and maybe a repro if possible so that we can investigate this further.

[mwpowellhtx]

@livarcocc It is not a mystery. Our CLI tooling targets netcoreapp2.1. I think we may be using preferclitooling mechanism as well; not sure if that is perhaps influencing things as well.

The tooling build pipeline was working just fine prior to VS2019 installation. Following VS2019 installation, CLI invocation failed abruptly. No other error than that, but for perhaps a cryptic runtime message indicating as previously mentioned.

The workaround (loosely so-called) we currently have is to use global.json to force the correct CLI runtime. But this also locks us into VS2017, whereas we might like to relax the runtime restriction a bit to allow for eventual forward migration path into VS2019.

Upon further digging, indeed dotnet --info does indeed report 3.0 being the default runtime, which we think is probably causing the snafu.

I'm sorry I cannot give you anything more specific than that.

[livarcocc]

Is the dotnet --info that you shared at the beginning of this issue the output you get from the server when running your build as well?

I would still really appreciate if you could share an error message with us.

What you are doing is something that we do ourselves all the time. A CLI tool is just a portable application being invoked through dotnet. At that point, dotnet will honor the information in your runtimeconfig.json and run your app to the framework that it declares if at all possible.

So, the scenario works and I was trying to understand what is different in your CI so that we could either help you fix it (if it is on your side) or identify a bug in our product and potentially fix it as well.

If the information from this thread, I don't feel like we have enough to diagnose what is happening here.

[mwpowellhtx]

@livarcocc Feel free to clone and verify, my OrTools wrappers. Initially I was trying to run against an actual Code.Generation.Roslyn generator, but that ran into its own set of kerfuffles, so we parked that particular effort on the shelf, and instead spun up a fit-for-purposes CG, notwithstanding the IDE run-time snafu. The build order is manual at the moment, code, then src, then tests, due to some run-time locking issues and so forth.

If everything builds and tests smoothly, then you should have a CLI tooling from code, that is subsequently invoked during src build, and which outcome is further verified during tests.

Enjoy!