Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow extracting framework-compatible DLLs from package #723

Closed
filipw opened this issue Mar 25, 2015 · 16 comments
Closed

Allow extracting framework-compatible DLLs from package #723

filipw opened this issue Mar 25, 2015 · 16 comments

Comments

@filipw
Copy link

filipw commented Mar 25, 2015

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
Copy link
Contributor

Vidarls commented Mar 26, 2015

would be a big step in making #707 happen 😎

@forki
Copy link
Member

forki commented Mar 26, 2015

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
Copy link
Member

forki commented Mar 26, 2015

Is the package already downloadrd at that point?

@filipw
Copy link
Author

filipw commented Mar 27, 2015

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
Copy link
Member

forki commented Mar 27, 2015

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

@filipw
Copy link
Author

filipw commented Mar 27, 2015

yes

@forki forki closed this as completed in 0977334 Mar 27, 2015
@forki
Copy link
Member

forki commented Mar 27, 2015

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
Copy link
Author

filipw commented Mar 27, 2015

⭐ ✨

@forki
Copy link
Member

forki commented Mar 27, 2015

Please let me know when you use it somewhere. Thanks

@Vidarls
Copy link
Contributor

Vidarls commented Mar 27, 2015

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 added a commit that referenced this issue Mar 27, 2015
@forki
Copy link
Member

forki commented Mar 27, 2015

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

@Vidarls
Copy link
Contributor

Vidarls commented Mar 27, 2015

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
Copy link
Member

forki commented Mar 27, 2015

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
Copy link
Contributor

Vidarls commented Mar 27, 2015

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
Copy link
Member

forki commented Mar 28, 2015

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

@Vidarls
Copy link
Contributor

Vidarls commented Mar 28, 2015

i did the simple and easy bits..

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants