.NET Core SDK 2.0.3 has hard-coded version string in bundle UI

[Petermarcu]

@barnson commented on Thu Nov 16 2017

Steps to reproduce

• Install dotnet-sdk-2.0.3-win-x64.exe, downloaded from https://www.microsoft.com/net/download/windows.

Expected behavior

The Success page tells me I installed version 2.0.3.

Actual behavior

The loc string FirstTimeWelcomeMessage used on the Success page in the bundle has hard-coded 2.0.0 strings.

Environment data

n/a

[Petermarcu]

Thanks @barnson , I moved it here where the SDK installer lives.

[barnson]

I spent 15 minutes trying to figure out which repo it belonged in. :)

[Petermarcu]

Nice, I know. we're actually working on some repo renaming to try to make things seem a little more obvious. Not sure if it will help a ton but I know its a bit of a challenge today.

[4creators]

@Petermarcu @barnson
I have noticed that problem yesterday as well and prepared temporary fix for the installer. Below are screenshots of two versions. Design is open to any changes requested 😃 Version data are sourced from build/DependencyVersions.deps and will update automatically with sources. If this is of any interest I can submit PRs for master and other branches.

And the second arrangement:

[Petermarcu]

@wli3 I'm sure is interested in a PR :)

[livarcocc]

@KathleenDollard can you take a look at the screenshots above and comment? I would like at least the .NET Core SDK version to match the number that will be installed on the disk for you. The number you are displaying right now does not.

Also, if we are showing some dependencies numbers there, should we show others? Like the template engine, the test console and NuGet?

[4creators]

IMHO it would be great to show everything what is installed similar to about box for VS, but with finer granularity.

[akoeplinger]

The macOS installer has the same issue btw (2.0.3 in the title bar vs 2.0.0 in the summary screen):

[SamArmand]

Correct me if I'm wrong but I think this issue stretches beyond the UI. I updated to 2.0.3 but restoring NuGet packages still installs Microsoft.NETCore.App 2.0.0 to my project. What's causing that?

[livarcocc]

@SamArmand that's intentional. This will guarantee that for portable applications your application will run on any runtime starting at 2.0.0. This is to prevent cases where you update to the latest SDK and publish your app, say, to Azure before that data center installs the 2.0.3, runtime. This way, that will continue to work.
There are no API changes in a patch release, so, this is perfectly safe.

If you are a self-contained app, then you need to set RuntimeFrameworkVersion 2.0.3 to target that runtime. That is currently a bug that we are working out how to solve.

In any case, this is unrelated to the version we print in the installer.

[dasMulli]

@livarcocc can't find the tracking issue now, but I was wondering why the implicit versions for the 1.* runtimes weren't raised to 1.0.8/1.1.5 in the 2.0.3 SDK - as far as I can tell it shouldn't be affected by the issue that's causing troubles for different versions for portable/self-contained (unless you want to fix the portable version to a lower version).

[livarcocc]

@dasMulli for the same reason we don't upgrade them for the 1.1.x SDK. If someone is targeting netcoreapp1.0 or 1.1 and updates their SDK to 2.0.3 and then publishes to a hoster that hasn't updated their runtime yet, the app is broken.

[KathleenDollard]

There are two aspects here

1. Change the UI on install to not use hard coded strings. Yippeee!!!! Excellent. Excellent.

2. Adding several new version numbers to the UI. I don't particularly like this and feel strongly that this is a bad time to do it.

Since we are diverging the runtime and SDK, the more clarity and simplicity we can provide, the less confusion from that change. The SDK is the thing they elected to install, so I want to reiterate that number (as before) and include the runtime for clarity (again, as before).

I would like to discuss what scenarios exist where the versions of Roslyn, MSBuild, F#, etc. are important to users. I would like to use that discussion to guide the right places to provide that information. I'm skeptical that a passing install complete screen is the most useful place to put this information.

[dasMulli]

I think the installer should at maximum display versions vor included ""things"" that could also be installed on their own.

When I installed a 2.2.0 CLI, it would be good to know that I got a 2.1.0 runtime and package store with it. I may remind me to download a 1.1.* / 2.0.* runtime installer as well. (at some point there was a change setting the CLI version to 15.5 which I liked since it couldn't be confused with a runtime version like 2.0.3)

In contrast to that, I don't think showing the versions of roslyn, msbuild, f# and friends don't provide any actionable information. Since I cannot install a version of roslyn/msbuild/… alone, there is nothing I can do about it.

[4creators]

Adding several new version numbers to the UI. I don't particularly like this and feel strongly that this is a bad time to do it.

From developer perspective it is the most vital information. SDK is targeted at developers and not consumers and having full and detailed version info on every part of it is just IMHO minimum info requirement.

I would like to discuss what scenarios exist where the versions of Roslyn, MSBuild, F#, etc. are important to users

Everywhere where they are relevant - we are talking about development tools which won't be released in a 2 - 3 year cadence but my hope is that it will be 1 - 3 months cadence. With that granularity we need to know every detail of tool to get relevant support, raise issue in relevant repos etc. IMHO one of the reasons why ppl have hard time finding right repos for reporting issues is lack of relevant information on runtime and sdk components and their versions.

If I get any warnings or error and I have do dig up info for posting an issue it becomes particularly frustrating.

I think the installer should at maximum display versions vor included ""things"" that could also be installed on their own.

Disagree - installer and tool after installation should provide full info otherwise we paternalise developers who are anyway usually grown ups and quite fluent in parsing visual complexity associated with version numbers - if they are unable to do that most probably they will have hard time on their jobs.

I don't think showing the versions of roslyn, msbuild, f# and friends don't provide any actionable value. Since I cannot install a version of roslyn/msbuild/… alone, there is nothing I can do about it

Wrong assumtpion - never underestimate devs

[4creators]

Ahh just forgot - all Windows SDKs provide detailed information on every tool installed in their sdks, installers, logs etc.

[dasMulli]

Wrong assumtpion - never underestimate devs

I don't. I'm the first one to learn roslyn, VS, msbuild version numbers by heart. But even VS has them tucked away in a help dialog. dotnet --info would be a more appropriate place to show all these details.
You also mentioned reporting issues. I don't think you'll re-run the installer just to get the version numbers when creating an issue.

But I really don't feel strongly about it.

[4creators]

dotnet --info

Agree - there should be an easy way to query for detailed tool info. It is very important for some scenarios where build scripts check for prerequisites or for error reporting. But it would be a separate issue.

I would even suggest to have dotnet <tool_name> --info/--version syntax support.

[KathleenDollard]

@4creators: I'm not suggesting hiding this data from programmers.

If we had a link on the installation summary that says "For details on SDK contents" we could provide a location where you can look this information up - and access it after the fact.

Would that solve your concerns?

[4creators]

Hmm .. I would say that yes and no. If I want to get info this will solve the problem but if I want to go with OSS spirit than the answer is no - this will not solve the problem.

I think very good example of what I am thinking about is an attempt to install some toolchain via apt-get install command on Debian and Debian derived Linux distros. What user is informed about before install will proceed these are all details of every package which will be installed on the machine including it's size, full version etc. I find this info very useful particularly if I am troubleshooting some build issues. Usually I keep tools versions memorized for several weeks after I have seen them once during install.

Another good example would be to have a look on the scope of info which will be provided by Linux distros during install once they will be able to build SDK fully from source and .NET Core will meet oss standards of the distros (what is not the case currently see issue dotnet/source-build#187). I bet it would be info on every tool installed.

[KathleenDollard]

@4creators Looking at the spirit of your comments, I'm even less happy with the version info in the completion dialog, because you talked about having that information before or during install. Supplying this info after install does not meet that spirit. If the right info is available somewhere online, it's available before, immediately after, or two months later, that better meets the spirit of ensuring that programmers have the right information to make the right decision at the right time.

So I suggest we

• fix this now by updating the version numbers that were already there (runtime and SDK), and
• create a new issue to establish the right way to communicate the contents of each SDK.

[leecow]

@KathleenDollard - once a final plan is decided up, the changes are needed in the release/15.5 (soon to be release/2.1)

[eduherminio]

Quite offtopic, @livarcocc, but...

If you are a self-contained app, then you need to set RuntimeFrameworkVersion 2.0.3 to target that runtime. That is currently a bug that we are working out how to solve.

Where can I follow the progress on that bug? Is there any workaround or is it possible to set it manually?
I'm afraid I need Core v2.0.3 in a self-contained app since this infinite recursion bug is solved in that version.

cc/ @danmosemsft, who tracked that bug until it was solved in v2.0.3 release

[Petermarcu]

Yes, you can set <RuntimeFrameworkVersion>2.0.3</RuntimeFrameworkVersion> in your project or pass /P:RuntimeFrameworkVersion=2.0.3 on the command line to publish and it should pick up 2.0.3.

[eduherminio]

Thanks :)

[poke]

@KathleenDollard

So I suggest we

• fix this now by updating the version numbers that were already there (runtime and SDK), and
• create a new issue to establish the right way to communicate the contents of each SDK.

I agree with this plan. The original list of installed components is good enough for the installer. As @dasMulli said, those are the things that actually get installed and what I should be conscious about. The internal components are interesting from a debugging perspective but serve no real use while installing.

So if the SDK installer contains the .NET Core SDK, the .NET Core Runtime, and the Runtime Package Store, then those should list their actual version numbers.

Then, I would like to see dotnet --info expanded to include the full details about the individual components (e.g. MSBuild, NuGet, Roslyn), so that as a developer, I can easily see what versions of those things I am using when I do stuff.

In addition, I think it would be very helpful to have some resource online to see exactly which SDK version includes what versions of those bits. So that when someone refers to a specific SDK version, I have a way to look up what versions are involved (e.g. to see whether specific Roslyn features are available).
As an example, I was directed to this issue because of a discussion where we wanted to figure out what SDK version is the earliest to support a certain C# version. By being able to look up what Rosyln versions ship with each released SDK, this would have been a lot easier.

[dasMulli]

Since it is a sort-of-public slack channel I don't think @jchannon and @poke mind me posting this.
That's the conversation leading to revisit this.