Home: Feature Request: Match assemblies to nuget packages.

[jessehouwing]

As a devops consultant I'm often brought in to help clients to brush up their old code bases, migrate them to newer technologies, lean out their repositories etc.

In these quests I often stumble upon folders with a gazillion binaries. Worst case randomly thrown together in a big folder. One of my clients has about 1.7GB in external dependencies in their TFVC repo. I'd like to get rid of that as part of the migration.

Ideally I'd move the bulk of these dependencies to nuget packages, remove as many transient ones as possible and purge them prior to moving the client to git.

The little-known T:some-type-in-assembly query API in resharper is helpful, but it doesn't help me find the right version of the package. it may also give me a lot of options to choose from.

Ideally I'd pass in a fully-qualified-assembly-name, that should narrow down the selection substantially. From there it would be much easier to compute the direct and transient dependencies and update the project files accordingly.

My proposal

Add a A:AssemblyName query API that will return all nuget packages that contain this assembly.

A:Microsoft.ServiceBus, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35
|
+- windowsazure.servicebus.4.1.11

Alternatively, let me pass a hash of a file and use that.

Looks like I'm not alone in this desire.

https://twitter.com/jessehouwing/status/1246150174654828550

[dominoFire]

@jessehouwing Are you asking to add a query API in NuGet for Visual Studio?

[jessehouwing]

An API would be a start. A feature in VS or a global tool or even a nuget.exe command would be even better. I received a dataset from a fellow MVP with 1000's of assembly-nuget pairs. So I think I can cobble something together for what I need now.

I bump into this problem with many clients who need to migrate/upgrade/clean-up existing solutions and it can be a nightmare.

[nkolev92]

cc @aortiz-msft @anangaur @chgill-MSFT

The ask is more general and spans multiple components, but a good start to track the experience here.

@anangaur Feel free to link any related efforts.

[anangaur]

IMO, there should one effort to dissect the packages on nuget.org and log the package details like assembly info, API info, file info, supported TFMs info etc. Once this is done we can expose these as useful info for multiple functionalities and experiences, including this one.

[jessehouwing]

Jetbrains & https://twitter.com/maartenballiauw already have an index with much of that info in in and a query syntax in the VS NuGet manager. Is there a possibility for a collaboration here?

[jessehouwing]

I've done a very rudimentary utility to scan the 1.7GB of my client's TFVC References folder and I can add the following details that may be useful:

• Since many Framework assemblies have a fixed assembly version of (for example) 4.0.0.0 it's probably useful to capture AssemblyFileVersion or a hash of the binary contents.
• Some assemblies are also found as "patched" in some other packages ant then signed with a different pubkey. So the full assembly name is preferred.
• Some of the assemblies in my clients directory were part of many nuget packages through binary inclusion instead of a transient dependency. Ideally you'd be able to resolve to a verified publisher or the nuget with the most downloads.
• Some assemblies are available in a Meta Package. ideally you'd be able to detect that a certain percentage of the meta package contents are there and suggest to reference the meta-package instead.
• Some packages are available as official as well as unofficial packages. Again, some algo to find the most trusted package is probably preferred.
• Some packages that use binary inclusion actually depend on assemblies from nugets with known vulnerabilities. Should these be marked by proxy?