search

dotnet / project-system

The .NET Project System for Visual Studio
MIT License
969 stars 387 forks source link

Show FrameworkReference version in Solution Explorer #2248

Closed davidfowl closed 5 years ago

davidfowl commented 7 years ago

image

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

image

DamianEdwards commented 7 years ago

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

davkean commented 7 years ago

Agreed @davidfowl I found this missing too.

@DamianEdwards What do you mean?

DamianEdwards commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

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

@tmeschter yes. There are actually 2 versions:

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 commented 7 years ago

@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 commented 7 years ago

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

dsplaisted commented 7 years ago

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 commented 7 years ago

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:

image

tmeschter commented 7 years ago

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

davidfowl commented 7 years ago

Damn

DamianEdwards commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

Use $(NETCoreSdkVersion)

nguerrera commented 6 years ago

@Pilchie @tmeschter Can we get this into 15.7?

davkean commented 6 years ago

@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 commented 6 years ago

I'd say something like:

@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 commented 6 years ago

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

nguerrera commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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

etbyrd commented 6 years ago

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 commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

image

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 commented 5 years ago

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

drewnoakes commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

Agreed this is tracking different work.

drewnoakes commented 5 years ago

The tracking of MSBuild project SDKs is in #3463.

davidfowl commented 5 years ago

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

drewnoakes commented 5 years ago

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 commented 5 years ago

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:

image

image

Where do I look?

davidfowl commented 5 years ago

There's target framework...

jmarolf commented 5 years ago

@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 commented 5 years ago

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:

jmarolf commented 5 years ago

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

image

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

cartermp commented 5 years ago

@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 commented 5 years ago

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

davidfowl commented 5 years ago

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 commented 5 years ago

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

image

drewnoakes commented 5 years ago

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 commented 5 years ago

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