Allow extracting framework-compatible DLLs from package

[filipw]

Nuget.Core has a method that lists all DLLs in a package:

public static IEnumerable<IPackageFile> GetLibFiles(this IPackage package);

You can then use another Nuget method to filter out only those DLLs that are relevant for a relevant version of the .NET framework:

 public static bool TryGetCompatibleItems<T>(FrameworkName projectFramework, IEnumerable<T> items, out IEnumerable<T> compatibleItems) where T : IFrameworkTargetable;

For example scriptcs uses these features to load Nuget packages by convention on startup. It would be cool if the same was available in the Paket API

[Vidarls]

would be a big step in making #707 happen 😎

[forki]

just to clarify, please take a look at https://github.com/fsprojects/Paket/blob/master/tests/Paket.Tests/InstallModel/Xml/SystemNetHttpForNet4.fs#L41

Here we fake a Nuget package with Nupec file which allows to reference all libs in the package and filter the installmodel to "Exactly .NET 4.0". And then we generate the XML for the csproj/fsproj file.

If I understand you correctly you just want the HintPaths to the filtered dlls, right?
How about this pseudo code:

 InstallModel
  .CreateFromPackage(packageName)
  .ApplyFrameworkFilter([DotNetFramework(FrameworkVersion.V4)])

which would then return a list of file names.

[forki]

Is the package already downloadrd at that point?

[filipw]

yeah the pseudo code you mention would do the trick.

The package is indeed available at that point - it's purely to be able to approach a folder with installed packages and pick up only the assemblies that I should care about given my version of the framework

[forki]

I assume the package is also downloaded with Paket (the version number is not in the path)

[filipw]

yes

[forki]

In 0.35.13 you can do:

let api = Dependencies.Locate()

let installedPackageVersions = api.GetInstalledPackages()

installedPackageVersions 
|> Seq.map (fun (packageName,_) -> api.GetLibraries(packageName,DotNetFramework(FrameworkVersion.V4)))
|> Seq.concat

[filipw]

⭐ ✨

[forki]

Please let me know when you use it somewhere. Thanks

[Vidarls]

Is this restricted to specific fx version or will it give up to given fx as well (if not all dependencies have fx specific version, but maybe previous fx version.)

[forki]

I hope 8c90659#diff-b6098bc56cf08cdcb2f6c0d652b578efR539 solves that question ;-)

[Vidarls]

Hope I get time to take this for a spin next week. (maybe #707 is closer to being realized than I thought).

Does this even handle old / bad packages that just puts everything in lib (no fx specific folders)

Are there similar features for content in tools and content?

[forki]

Just ask what you need. Most stuff is there and just needs to be exposed
via api
On Mar 27, 2015 8:20 PM, "Vidar Løvbrekke Sømme" [email protected]
wrote:

Hope I get time to take this for a spin next week. (maybe #707
#707 is closer to being
realized than I thought).

Does this even handle old / bad packages that just puts everything in lib
(no fx specific folders)

Are there similar features for content in tools and content?

—
Reply to this email directly or view it on GitHub
#723 (comment).

[Vidarls]

you can have a look at this gist:https://gist.github.com/Vidarls/549ce388ea6d219ed417 to see what I did outside Paket.

I'm looking at getting all binaries, tools and content from a set of packages (not all, need to be able to filter) with best compatibility for a specified fx (i.e net 4.5 falling back through prv fx if package does not support the newest fx).

[forki]

looks like you reinvent a lot of Paket's inner stuff. Will try to look a bit deeper this weekend.

[Vidarls]

i did the simple and easy bits..