解决Visual Studio依赖项

Question

I am parsing the project.assets.json file in a C# project to retrieve the dependencies for a project (I'm doing this as part of a project which is extracting documentation information from the project files).

I haven't been able to find much documentation for project.assets.json online. It appears to have a number of sections.

Here's an extract:

{
    "version": 3,
    "targets": {
        "Microsoft.IdentityModel.JsonWebTokens/5.3.0": {
            "type": "package",
            "dependencies": {
                "Microsoft.IdentityModel.Tokens": "5.3.0",
                "Newtonsoft.Json": "10.0.1"
            },
            "compile": {
                "lib/netstandard2.0/Microsoft.IdentityModel.JsonWebTokens.dll": {}
            },
            "runtime": {
                "lib/netstandard2.0/Microsoft.IdentityModel.JsonWebTokens.dll": {}
            }
        },
    },
    "libraries": {
        "Microsoft.IdentityModel.JsonWebTokens/5.3.0": {
            "sha512": "GmiwCJPEe+V8+2GO3kD8K0IeqNHlTL0xZcHePIjyJveRn7OderxdT32aCZeJZEvz5w2Jlyag3zdyu1zkdTJo2A==",
            "type": "package",
            "path": "microsoft.identitymodel.jsonwebtokens/5.3.0",
            "files": [
                ".nupkg.metadata",
                ".signature.p7s",
                "lib/net45/Microsoft.IdentityModel.JsonWebTokens.dll",
                "lib/net45/Microsoft.IdentityModel.JsonWebTokens.pdb",
                "lib/net45/Microsoft.IdentityModel.JsonWebTokens.xml",
                "lib/net451/Microsoft.IdentityModel.JsonWebTokens.dll",
                "lib/net451/Microsoft.IdentityModel.JsonWebTokens.pdb",
                "lib/net451/Microsoft.IdentityModel.JsonWebTokens.xml",
                "lib/net461/Microsoft.IdentityModel.JsonWebTokens.dll",
                "lib/net461/Microsoft.IdentityModel.JsonWebTokens.pdb",
                "lib/net461/Microsoft.IdentityModel.JsonWebTokens.xml",
               "lib/netstandard1.4/Microsoft.IdentityModel.JsonWebTokens.dll",
               "lib/netstandard1.4/Microsoft.IdentityModel.JsonWebTokens.pdb",
               "lib/netstandard1.4/Microsoft.IdentityModel.JsonWebTokens.xml",
              "lib/netstandard2.0/Microsoft.IdentityModel.JsonWebTokens.dll",
               "lib/netstandard2.0/Microsoft.IdentityModel.JsonWebTokens.pdb",
              "lib/netstandard2.0/Microsoft.IdentityModel.JsonWebTokens.xml",
                 "microsoft.identitymodel.jsonwebtokens.5.3.0.nupkg.sha512",
                 "microsoft.identitymodel.jsonwebtokens.nuspec"
            ]
        },
    }
}

Conceptually, my parser looks at the targets section and extracts the path to the DLL that gets referenced by the project. For packages, that path is relative to the local nuget package repository (typically C:\\Users\\<username>\\.nuget\\packages ).

But I've run into some situations -- and the extract is one of them -- where the specified DLL ( Microsoft.IdentityModel.JsonWebTokens/5.3.0/lib/netstandard2.0/Microsoft.IdentityModel.JsonWebTokens.dll ) doesn't exist in the local nuget repository. In fact, the libraries section shows a repository path ( Microsoft.IdentityModel.JsonWebTokens/5.3.0 ) which doesn't exist in the repository folder (there's not even a Microsoft.IdentityModel.JsonWebTokens folder).

Yet the project with the "broken" reference builds without any errors, and functions properly.

I'd appreciate any insight others might have on how these "broken" repository paths should be resolved. If anyone knows of online documentation for project.assets.json that'd be great, too.

Answer 1

Look for the packageFolders section of the project.assets.json file. This is what I have:

  "packageFolders": {
    "C:\\Users\\zivkan\\.nuget\\packages\\": {},
    "C:\\Program Files\\dotnet\\sdk\\NuGetFallbackFolder": {}
  },

Microsoft.IdentityModel.JsonWebTokens sounds a lot like something that would be used by ASP.NET Core, and therefore the .NET Core SDK NuGetFallbackFolder sounds like a very likely place for it to be.

By using the package folders listed in the json file, your program will also be more robust if used on a project that redirects its global packages folder away from the default user profile location.