search

dotnet / project-system

The .NET Project System for Visual Studio
MIT License
968 stars 386 forks source link

Show MSBuild project SDKs in the Dependencies node #3463

Open DoCode opened 6 years ago

DoCode commented 6 years ago

When referencing a custom SDK project like this:

<Project Sdk="MyCompany.MyProduct.SDK/2018.1.0-preview3">
...

it doesn't show under the Dependencies node in Visual Studio. And also it is not seeable and updatable from NuGet Package Manager.

Also see: https://github.com/Microsoft/MSBuildSdks/issues/24

Pilchie commented 6 years ago

Related to https://github.com/dotnet/project-system/issues/2248

davkean commented 6 years ago

Just as a side note, that SDKs node is actually something different; "Extension SDKs" not be confused with "MSBuild SDKs". I think we should rename the former from "SDK -> Extension SDKs".

drewnoakes commented 5 years ago

I've renamed this issue to better reflect the feature request.

nguerrera commented 5 years ago

Restating some relevant info from #2248:

  1. For MSBuild SDKs coming from the .NET Core SDK, they all have Version=$(NETCoreSDKVersion). There was some talk in #2248 of starting by showing $(NETCoreSDKVersion) somewhere.

  2. To actually enumerate all imported MSBuild SDKs and their versions (for example, including those pulled down with NuGet MSBuild SDK resolver), I believe there will need to be a new MSBuild API added. cc @rainersigwald @livarcocc

drewnoakes commented 4 years ago

We now have the project import tree, which may be a good place to show such a version.

For example, we could show the value of $(NETCoreSDKVersion) on top-level Sdk.props and Sdk.targets tree items.

nguerrera commented 4 years ago

Is the full path to the Sdk.props/Sdk.targets visible somewhere in that tree? If so, there is the version in the path. I'm not saying this is the best way to present it, but it would mean it's at least something you could find now if the path to imports can be discovered.

nguerrera commented 4 years ago

We now have the project import tree,

Should I expect to see this in dogfood build already? I don't.

drewnoakes commented 4 years ago

Is the full path to the Sdk.props/Sdk.targets visible somewhere in that tree?

Not yet, but the plan is to make it available in the properties panel. Best you can do now is double-click the file then see the path in the editor tab tool tip.

Should I expect to see this in dogfood build already? I don't.

Yep, but you have to turn on 'Show all files' for the project. Feedback appreciated.

nguerrera commented 4 years ago

Nice!

So even if we don't do this feature (still think we should), I now have a way to find the version:

image

drewnoakes commented 4 years ago

Can you see any issues with using $(NETCoreSDKVersion)? For example if using Microsoft.NET.Sdk.WindowsDesktop? I haven't played around with it yet.

davkean commented 4 years ago

Is there a general purpose version that comes with the MSBuild SDK itself (think like when the SDK comes from a package) that we can pull so we don't have to specifically handle this variable that is SDK-specific?

nguerrera commented 4 years ago

SDK resolvers return a version to MSBuild so I think the right, general way would be to ask msbuild for a list of resolved sdks and their names and versions. (# 2 in https://github.com/dotnet/project-system/issues/3463#issuecomment-513947382)

nguerrera commented 4 years ago

I would imagine it isn’t a huge change for msbuild to expose resolved sdks, but I could be very wrong. I think we should investigate what that would take.

nguerrera commented 4 years ago

The source of truth is what the sdk resolver returns to msbuild. The package resolver returns a package version. The .NET core sdk resolver returns the .NET Core SDK version for all sdks it bundles.