Project-system: Show FrameworkReference version in Solution Explorer

[davidfowl]

Visual Studio for MAC does this and it's super useful:

[DamianEdwards]

Why are we calling it The SDK though, it isn't. Those versions are different, but I'd like to see them all.

[davkean]

Agreed @davidfowl I found this missing too.

@DamianEdwards What do you mean?

[DamianEdwards]

Maybe it's fine now that we're attempting to unify version numbers better, but for a long time the actual SDK version was different to the shared framework version (which is what Microsoft.NETCore.App actually is). The SDK is actually Microsoft.Net.SDK

[MattGertz]

Post-15.3, please. (15.4 would be OK.) It's a great idea, but this is borderline feature work and you already have great quantities of bugs to push through for 15.3 shutdown.

[tmeschter]

@davidfowl @DamianEdwards @davkean So what should we show next to "Microsoft.NETCore.App", since the version of the SDK and the version of Microsoft.NETCore.App could be different?

I'm inclined to show the actual version of Microsoft.NETCore.App, and show the actual SDK version in the SDK node (e.g. "SDK (1.1.1)") or perhaps just show it in the property grid when you select the SDK node.

[tmeschter]

PR #2807 will add the version to the captions of items under the SDK node.

Is it useful to show the SDK version on the SDK node itself?

[davidfowl]

Is it useful to show the SDK version on the SDK node itself?

@tmeschter yes. There are actually 2 versions:

• The SDK version
• The runtime version (Microsoft.NETCore.App)

Both of these today are nearly impossible to figure out what VS chose to use without looking at an msbuild diagnostics log. We need to show both of these versions in the IDE.

[tmeschter]

@davidfowl OK. PR #1572 will address the runtime version (well, that PR plus a small change to the SDK).

Now I'm trying to figure out if the SDK version is available in an MSBuild property.

[tmeschter]

Sounds like further work on this is blocked by https://github.com/dotnet/cli/issues/7051.

[dsplaisted]

I'm not sure it's going to be too helpful to show these versions. If you target .NET Standard 1.4, you will see the package version as 1.6.1. You have to expand the dependency tree to find it though, so hopefully not too many people will be confused by it.

[davidfowl]

I'm not sure it's going to be too helpful to show these versions. If you target .NET Standard 1.4, you will see the package version as 1.6.1. You have to expand the dependency tree to find it though, so hopefully not too many people will be confused by it.

Why would it not be helpful to show the effective version of the SDK and runtime? It's as useful as the package versions. It's required to do any reasonable diagnostics. The last time I asked @nguerrera how I figure out what version of the SDK was being used by VS there was a pause. It shouldn't require any though to figure that out because it should be obvious in the UI 😄 .

Here's what jetbrains rider shows:

[tmeschter]

Moving further work out to 15.6. This no longer meets the bar for 15.5.

[davidfowl]

Damn

[DamianEdwards]

It seems now we have the version of the platform package (shared framework) showing up here in 15.6 (GREAT!) however we still don't actually have the SDK itself.

I'd really like to see us show the actual SDK names and versions under the SDK node, and have the platform packages/shared-frameworks shown under a new node, or under the NuGet node. Then we'll have all the implied, platform-level details visible for the project.

[DamianEdwards]

Also, the actual SDK's are pretty much guaranteed to have different versions from what's actually being shown here (the shared fx) from now, so this is even more important that it was before.

[nguerrera]

We now have an msbuild property with the sdk version (beginning in recent 2.1.300 builds) so project system is unblocked to grab that. You'll have to be prepared for it to be undefined in earlier versions. Should be an easy fix (finally).

[nguerrera]

Use $(NETCoreSdkVersion)

[nguerrera]

@Pilchie @tmeschter Can we get this into 15.7?

[davkean]

@DamianEdwards Can someone mock me up what they want this to look like? This stuff is damn complicated and I have no idea what/how these versions numbers come into play.

[DamianEdwards]

I'd say something like:

• Depenencies
  
  
  
  • Analyzers
  
  
  • NuGet
  
  
  • Framework (This is what is currently shown under the SDK node today)
  
  
  • Microsoft.NETCore.App (2.1.0-preview1-26216-03)
    
    
    
    
    
    • OMG all the assemblies
    
    
    
  
  
  • Projects
  
  
  • SDK (This would now actually be the SDK)
  
  
  • Microsoft.NET.Sdk (2.1.300-preview1-008174)
  
  

@nguerrera does that property only include details on the Microsoft.NET.Sdk SDK? What about projects using Microsoft.NET.Sdk.Web, or Microsoft.NET.Sdk.Razor (new in 2.1)? Should they all define their own property, or something else?

[DamianEdwards]

@nguerrera also, we need to know where to get the SDK name as well as the version I guess

[nguerrera]

Most of them version with the .net core sdk. But with the new nuget sdk resolver, that might change. To enumerate all msbuild sdks and versions, I think an MSBuild API would be best. It has all of this information returned to it by sdk resolvers. I don't think such an API exists today though. Cc @jeffkl @andygerlicher

[DamianEdwards]

OK so for now how about we just hard-code assumption of the Microsoft.NET.Sdk and show the version for that using the property you described, and we can work towards a more complete solution in a future release.

[Pilchie]

Pulling into 15.7, and moving to @etbyrd. We'll try to get to them.

[etbyrd]

So it seems this issue has been now split into two parts:

Change 1: Renaming the SDK node to "Framework" and refactoring the code to reflect this

Change 2: Creating a new SDK node that contains the value from $(NETCoreSdkVersion)

After talking to several people on the team offline, it seems most people agree with making the first change. I put out a PR making this change here: https://github.com/dotnet/project-system/pull/3461 The refactoring part is still a WIP.

I will be putting out a PR for the second change at a later time.

[drewnoakes]

@nguerrera @DamianEdwards under what circumstances can the SDK version change? Can that happen while the project is loaded? Currently the grouping nodes (SDK, NuGet, Analyzers, etc) are created once and not updated based on property changes. The complexity of the implementation here will in part depend upon whether the SDK version could change over time (without a project unload/reload).

[davkean]

Currently the grouping nodes (SDK, NuGet, Analyzers, etc) are created once and not updated based on property changes.

Hmm, that's not my understanding. Adding/removing a reference will add/remove parent nodes.

[drewnoakes]

They're currently singleton instances, shared between projects, added/removed to/from the tree, and never updated.

We can change that of course. Knowing whether the SDK version can change at arbitrary points in time (vs. just when added to tree) will influence how that change happens.

[nguerrera]

The SDK can change between evaluations. If global.json is modified or a new SDK is installed. This isn't necessarily an important scenario, but we'd have to do significant work to block it.

[davkean]

They're currently singleton instances, shared between projects, added/removed to/from the tree, and never updated.

Can you expand on that? What exactly are singletons?

[drewnoakes]

The IDependencyModel instance that backs the SDK node (and other dependency type group nodes) are created via IProjectDependenciesSubTreeProvider.CreateRootDependencyNode().

IDependencyModel is immutable, so the six implementations of the method currently return their own singleton instances.

The implementation in SdkRuleHandler can be changed to return a new instance each time (or from a pool).

IProjectDependenciesSubTreeProvider is part of the public API so the signature of that method cannot be changed. The implementation will need to remember the SDK version.

[drewnoakes]

I think I misunderstood the request here. I interpreted this as showing the SDK version alongside the SDK node:

Perhaps it makes more sense to add a Microsoft.NET.Sdk node and show the SDK version there.

We should conclude #4362 before commencing this work.

[cartermp]

The version is called out now in #4362. Can we close this in favor of that issue?

[drewnoakes]

With the introduction of FrameworkReferences the SDK node is no longer going to show targeting packs and will only show extension SDKs.

I don't see any actionable task from this issue so will close it.

[Pilchie]

@drewnoakes is there still something tracking the desire to know what SDK is going to get used? The issue is that with global.json, the “use previews” option, etc, it can be hard to know what SDK the resolver actually ended up picking. I’ve seen several requests on twitter and Github asking for that, and I thought that’s what this tracked.

[davkean]

Agreed this is tracking different work.

[drewnoakes]

The tracking of MSBuild project SDKs is in #3463.

[davidfowl]

It still doesn’t show the shared framework version. The dependencies node for 3.0 ASP.NET Core applications are pretty broken

[drewnoakes]

The version of the shared framework _will_ be visible in the property pages. The concensus appears to be that the version of the shared framework would not be useful to most users and at worst, confusing.

The dependencies node for 3.0 ASP.NET Core applications are pretty broken

Could you elaborate? We're currently waiting for merged MSBuild and SDK changes to be inserted to fully enable the project system feature.

[davidfowl]

Lets say I want to answer the question: "What version of ASP.NET Core and .NET Core am I using".

Here's a file new empty ASP.NET Core 3.0 project:

Where do I look?

[davidfowl]

• There's no ASP.NET Core shared framework version
• There's no .NET Core shared framework version
• There's no SDK version
• The dependencies node has only analyzers

There's target framework...

[jmarolf]

@davidfowl the build you are using doesn't have the Framework reference support yet. Any new 16.3 build (from master) should have these fixes but I'm not convinced that we show the info you want in those builds

What version of ASP.NET Core and .NET Core am I using

So we can show you

1. The SDK version you are building with
2. The version of the runtime you would be using in a self-contained publish scenario
3. The version of the runtime assemblies that the SDK picked for you based on your combination of SDK and Framework References
4. The Target Framework that your app is building against

I am making the assumption that you want to be shown 3 since that is the closest to what is shown for nuget packages (but please correct me if I am wrong).

For nuget packages there is only really one thing that makes sense to show, the nuget package version. Its also something that is actionable. The user may need to reason about their package versions and make changes to their dependencies.

For framework references its unclear to me what the user is going to do with this information. The only knob that is available to them is changing their TFM. One of the points of Framework References is that the user is auto-migrated to newer runtimes and packages as security fixes are released, so while we _should_ have a plan for how all four categories of info are accessible from VS I am not convinced that the project tree nodes is the ideal place. Feel free to correct me where I am wrong or made incorrect assumptions tho :)

[davidfowl]

Thanks for the reply! Yes I'm sad that of those 4 things you listed, none of them show me what I'm looking for. We have dotnet --info:

.NET Core SDK (reflecting any global.json):
 Version:   3.0.100-preview7-012715
 Commit:    1ee9aab9cb

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.17134
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\3.0.100-preview7-012715\

Host (useful for support):
  Version: 3.0.0-preview7-27826-20
  Commit:  ee0c7ead1a

.NET Core SDKs installed:
  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.600-preview-009497 [C:\Program Files\dotnet\sdk]
  2.1.600 [C:\Program Files\dotnet\sdk]
  2.1.601 [C:\Program Files\dotnet\sdk]
  2.1.602 [C:\Program Files\dotnet\sdk]
  2.1.700-preview-009597 [C:\Program Files\dotnet\sdk]
  2.1.700-preview-009601 [C:\Program Files\dotnet\sdk]
  2.1.700-preview-009618 [C:\Program Files\dotnet\sdk]
  2.1.700 [C:\Program Files\dotnet\sdk]
  2.1.800-preview-009677 [C:\Program Files\dotnet\sdk]
  2.1.800-preview-009696 [C:\Program Files\dotnet\sdk]
  2.2.100 [C:\Program Files\dotnet\sdk]
  2.2.102 [C:\Program Files\dotnet\sdk]
  3.0.100-preview7-012715 [C:\Program Files\dotnet\sdk]

.NET Core runtimes installed:
  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.2.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.2.1 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  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.2.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.2.1 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.0.0-preview-19054-0257 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.0.0-preview-19055-13 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.0.0-preview-19055-14 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.0.0-preview-19056-06 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.0.0-preview-19058-39 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.0.0-preview-19058-58 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.0.0-preview-19058-73 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.0.0-preview-19059-33 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.0.0-preview-19059-78 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.0.0-preview-19067-0383 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.0.0-preview7.19329.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.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.2.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.2.1 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.0.0-preview-27219-3 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.0.0-preview7-27826-20 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 3.0.0-preview5-27618-09 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 3.0.0-preview5-27619-03 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 3.0.0-preview5-27619-12 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 3.0.0-preview7-27826-20 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

Now I'm not saying we need to show this information but it should be the starting point of all relevant information that we can show users. This shows all possible options but visual studio picked a specific SDK and the application is targeting specific versions of each framework reference (not specifically the version that you will run on, we know that's a different story).

For nuget packages there is only really one thing that makes sense to show, the nuget package version. Its also something that is actionable. The user may need to reason about their package versions and make changes to their dependencies.

👍

For framework references its unclear to me what the user is going to do with this information. The only knob that is available to them is changing their TFM. One of the points of Framework References is that the user is auto-migrated to newer runtimes and packages as security fixes are released, so while we should have a plan for how all four categories of info are accessible from VS I am not convinced that the project tree nodes is the ideal place. Feel free to correct me where I am wrong or made incorrect assumptions tho :)

I appreciate the fact that the TFM decides what version is being targeted but there's a need to understand what the specific versions are for a couple of reasons:

• Pre-release versions. This information is critical when both us and users use preview versions our product to understand what the exact version of .NET Core is being used is.
• Patched versions. When that 3rd slot of the version number changes, it would be amazing to know which patch is "in effect".

[jmarolf]

I appreciate the fact that the TFM decides what version is being targeted but there's a need to understand what the specific versions are for a couple of reasons

My initial though is to show all this information in the properties pane. Traditionally this was where this sort of info went in .NET Framework

This way users that need this information can access is easily without increasing the concept count for new users of .NET

[cartermp]

@drewnoakes I don't have a build; are we showing child dependencies in framework references with your work? That feels like where we'd want people to look to be able to understand the version of ASP.NET Core they're referencing. If that isn't enough information to meet @davidfowl's requirement then we need to have a think about this, since people should be able to understand what they are referencing just by expanding nodes to see child dependencies.

[nguerrera]

The framework targeting pack version will show in property pane already with latest bits, right?

[davidfowl]

I have this in my runtimeconfig.json file:

{
  "runtimeOptions": {
    "tfm": "netcoreapp3.0",
    "framework": {
      "name": "Microsoft.AspNetCore.App",
      "version": "3.0.0-preview7.19329.2"
    },
    "configProperties": {
      "System.GC.Server": true
    }
  }
}

Microsoft.AspNetCore.App version 3.0.0-preview7.19329.2 will show up in the properties pane when I show details for the Microsoft.AspNetCore.App framework reference.

Can somebody send me a screenshot?

[davidfowl]

Will it also have the path to the shared framework or ref pack?

[drewnoakes]

The framework targeting pack version will show in property pane already with latest bits, right?

yes, once all the latest bits (project system, MSBuild, SDK) are running in concert.

Are we showing child dependencies in framework references with your work?

Not yet. That's being tracked by #4444.

Will it also have the path to the shared framework or ref pack?

Yes. Without any further changes (beyond waiting for things to sync up) things will look as discussed here.

@davidfowl would that address your concerns? This is still an active area of development so we can continue to refine the experience. Once we see it running end to end we'll have a better sense of where it's lacking.

[davidfowl]

I believe so, let me know when it's available in a build so I can give feedback as soon as possible 😄

[DamianEdwards]

Given this is in master, I'm assuming it's not landing in d16.3 preview 1?

[drewnoakes]

master is currently 16.3 so I believe the changes will be in d16.3p1.

[davidfowl]

I have a version that shows framework refs without a version

[drewnoakes]

@davidfowl the design is to show them without versions. Would you like to see a different behaviour? This was discussed and the conclusion was to omit them. Can you give an example where the version would be helpful? Note that the version will be available in the properties page soon.

[davidfowl]

Can you give an example where the version would be helpful? Note that the version will be available in the properties page soon.

Why do I have versions next to my nuget packages? Why does dotnet --version and dotnet --info exist? It's extremely useful when diagnosing problems for both customers and us the framework owners. It's the first thing we ask people to when they file an issue. I can go on but I don't want to list the reasons why showing version numbers are useful. They really are especially when you can change what the effective version is by using a global.json.

I grab a repro and I want to know what version is in effect:

• The SDK version chosen
• The shared framework ref pack I'm compiling against

[drewnoakes]

The idea was that users shouldn't be concerned with the version of a target framework. The version relates to their TFM, and seeing a number on the node can cause confusion in some cases. For example there was plenty of confusion when targeting netstandard1.3 and seeing a reference to NETStandard.Library version 1.6.1. So it's in that spirit that the version is not given prime screen real estate, yet is still available in the properties panel for users who want to know exactly what was resolved, and to help debug issues.

When I asked for an example, I was thinking that perhaps there's a case in ASP.NET Core that I'm not aware of where the version number is actually helpful for most users. I'm far more familiar with target frameworks for Microsoft.NETCore.App and the WinForms/WPF target frameworks where the version number isn't really helpful.

The SDK version chosen

This is being tracked in #3463