Home: Consume pdbs from packages in PackageReference - add Debug Symbols to LockFileTargetLibrary

Created on 23 Sep 2017  路  10Comments  路  Source: NuGet/Home

https://github.com/dotnet/sdk/issues/1458 depends on this

To include PDB to _CopyLocal_, SDK need _NuGet.ProjectModel_ to categorize PDB and XML file to an ideally different category like "debug symbol" or "related file".

So SDK can get all the symbol files by something like var symbolPath = lockFileTargetLibrary.debugSymbols , just like CompileTimeAssemblies, RuntimeAssemblies today

https://github.com/NuGet/NuGet.Client/blob/efae789c75899ca0bdd063f34a4b73cd41510d56/src/NuGet.Core/NuGet.ProjectModel/LockFile/LockFileTargetLibrary.cs#L27

Symbols Customer Sprint Restore CLI-SDK Backlog 2 PackageReference Feature

Most helpful comment

Here is a small proposal to push this forward:

For any given asset, if there are files next to it that differ only by extension AND those files are not themselves assets of another type, then add a "related" array underneath the asset listing the extensions of these files.

{
  "version": 3,
  "targets": {
    ".NETCoreApp,Version=v5.0": {
      "Newtonsoft.Json/12.0.3": {
        "type": "package",
        "compile": {
-          "lib/netstandard2.0/Newtonsoft.Json.dll": {}
+          "lib/netstandard2.0/Newtonsoft.Json.dll": {
+             "related": [".pdb", ".xml"]
+          }
        },
        "runtime": {
-          "lib/netstandard2.0/Newtonsoft.Json.dll": {}
+          "lib/netstandard2.0/Newtonsoft.Json.dll": {
+             "related": [".pdb", ".xml"]
+          }
      }
    }
  },

Then in the SDK, any place where we copy a nuget asset should respect AllowedReferenceRelatedFileExtensions

Since I no longer work on .NET. I will leave it to the SDK and NuGet teams to come up with a final proposal.

All 10 comments

@wli3 @nguerrera

I know we discussed this in a sync-up meeting.
If there's any sort of urgency for this issue, let us know so we can account for that in our triaging.

fyi @aortiz-msft

It was on me to write up a more complete proposal and I got caught up with release issues since. I still intend to push forward on this. It would be good to have it on your radar for soon. There are a lot of pings on related sdk issues for quite some time. I think we should try to prioritize it.

@wli3
Let us know when this becomes a priority for you.

Here is a small proposal to push this forward:

For any given asset, if there are files next to it that differ only by extension AND those files are not themselves assets of another type, then add a "related" array underneath the asset listing the extensions of these files.

{
  "version": 3,
  "targets": {
    ".NETCoreApp,Version=v5.0": {
      "Newtonsoft.Json/12.0.3": {
        "type": "package",
        "compile": {
-          "lib/netstandard2.0/Newtonsoft.Json.dll": {}
+          "lib/netstandard2.0/Newtonsoft.Json.dll": {
+             "related": [".pdb", ".xml"]
+          }
        },
        "runtime": {
-          "lib/netstandard2.0/Newtonsoft.Json.dll": {}
+          "lib/netstandard2.0/Newtonsoft.Json.dll": {
+             "related": [".pdb", ".xml"]
+          }
      }
    }
  },

Then in the SDK, any place where we copy a nuget asset should respect AllowedReferenceRelatedFileExtensions

Since I no longer work on .NET. I will leave it to the SDK and NuGet teams to come up with a final proposal.

The reason for the increased priority behind the original issue is because this is a regression in the experience for PackageReference projects compared to packages.config.

@nkolev92 https://github.com/dotnet/sdk/issues/1458#issuecomment-708662232 Looks like we've gotten our request for increased priority. Do you think we'll be able to do this before 6.0?

It's a high on the customer sprint task list as of now :)

I think that this issue is already on the planning backlog as well as a partner ask.

This would be the alternative to #7815 /cc @JonDouglas

This would be the alternative to #7815 /cc @JonDouglas

I think they tackle the same problem, but I don't necessarily think they have to be exclusive.

This covers already existing packages, while #7815 is more about the direction new packages need to take.

Was this page helpful?
0 / 5 - 0 ratings