Show FrameworkReference version in Solution Explorer #2248
Comments
|
Why are we calling it The SDK though, it isn't. Those versions are different, but I'd like to see them all. |
|
Agreed @davidfowl I found this missing too. @DamianEdwards What do you mean? |
|
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 |
|
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. |
|
@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. |
Related to dotnet#2248. Currently we include the version number in the caption for _package_ items under the Dependencies node in Solution Explorer, like this: > StyleCop.Analyzers (1.0.2) However, we don't do the same thing for items under the SDK node. In this case the model for SDK dependencies supports a version number; we just need to update the caption to show it. Note that the SDK dependencies are ultimately backed by items produced by the `CollectSDKReferencesDesignTime` task in the [dotnet/sdk](https://github.com/dotnet/sdk) repo, and these items currently do not include `Version` metadata. That will go in as a separate change, and only once both of these changes come together will you see the version number in Solution Explorer.
|
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? |
Related to dotnet/project-system#2248. When generating MSBuild items representing SDK references make sure to pass along the Version metadata. This way we can display it in Solution Explorer and the Properties window.
@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. |
|
@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. |
|
Sounds like further work on this is blocked by https://github.com/dotnet/cli/issues/7051. |
|
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:
|
|
Moving further work out to 15.6. This no longer meets the bar for 15.5. |
|
Damn |
Pilchie
added
Area-New-Project-System
Feature-Dependency-Node
|
With the introduction of I don't see any actionable task from this issue so will close it. |
|
@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. |
|
Agreed this is tracking different work. |
|
The tracking of MSBuild project SDKs is in #3463. |
|
It still doesn’t show the shared framework version. The dependencies node for 3.0 ASP.NET Core applications are pretty broken |
|
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.
Could you elaborate? We're currently waiting for merged MSBuild and SDK changes to be inserted to fully enable the project system feature. |
|
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? |
There's target framework... |
|
@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
So we can show you
I am making the assumption that you want to be shown For For |
|
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 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).
👍
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 |
|
@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. |
|
The framework targeting pack version will show in property pane already with latest bits, right? |
|
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? |
|
Will it also have the path to the shared framework or ref pack?
|
yes, once all the latest bits (project system, MSBuild, SDK) are running in concert.
Not yet. That's being tracked by #4444.
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. |
|
I believe so, let me know when it's available in a build so I can give feedback as soon as possible 😄 |
|
Given this is in master, I'm assuming it's not landing in d16.3 preview 1? |
|
|
|
I have a version that shows framework refs without a version |
|
@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. |
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 I grab a repro and I want to know what version is in effect:
|
|
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 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
This is being tracked in #3463 |
drewnoakes
changed the title
Visual Studio for MAC does this and it's super useful:
The text was updated successfully, but these errors were encountered: