search

fsprojects / Paket

A dependency manager for .NET with support for NuGet packages and Git repositories.
https://fsprojects.github.io/Paket/
MIT License
2.02k stars 520 forks source link

File share access with some reflection #540

Closed Thorium closed 9 years ago

Thorium commented 9 years ago

This kind of totally fictive situation: Mainly packages comes from NuGet, but there are also two other scenarios: a) All the old dll-references are not migrated to NuGet yet. b) There might be also some proprietary purchased dll-libraries which are not available open-source

So, some reference-files are in some common file-share, network-drive or where ever (like in #54 ).

If I open a dll file with ILSpy, it can tell itself:

// C:\path...\Castle.Facilities.Logging.dll // Castle.Facilities.Logging, Version=3.2.0.0, Culture=neutral, PublicKeyToken=407dd0808d44fbdc

// Architecture: AnyCPU (64-bit preferred) // Runtime: .NET 4.0

And also References:

// mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 // Castle.Windsor, Version=3.2.0.0, Culture=neutral, PublicKeyToken=407dd0808d44fbdc // Castle.Core, Version=3.2.0.0, Culture=neutral, PublicKeyToken=407dd0808d44fbdc // System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089

So, could I include this network path having these dlls ("include subdirectories") to the calculation of the Paket dependency-hierarchy? Would Paket help migrating these to NuGet?

Thorium commented 9 years ago

Something like this: https://gist.github.com/Thorium/ff0d59a914872dde60bf

Generates files: paket.test.dependencies

source c:\3rdPartyDlls\

file ABCpdf 9.1.1.5
file NVelocity 1.1.1.0
file Castle.Core 3.2.0.0
file Castle.Facilities.Logging 3.2.0.0
file Castle.Windsor 3.2.0.0
file Rhino.Mocks 3.6.0.0
...

and paket.test.lock

FILESHARE
  remote: c:\3rdPartyDlls\
  specs:
    ABCpdf (9.1.1.5)
    NVelocity (1.1.1.0)
    Castle.Core (3.2.0.0)
    Castle.Facilities.Logging (3.2.0.0)
      Castle.Windsor (3.2.0.0)
      Castle.Core (3.2.0.0)
    Castle.Windsor (3.2.0.0)
      Castle.Core (3.2.0.0)
    Rhino.Mocks (3.6.0.0)
    ...

Next steps:

Thorium commented 9 years ago

Updated the source snippet: https://gist.github.com/Thorium/ff0d59a914872dde60bf Any thougths / wishes about this? Would it have any actual benefits? Should I continue to actually implement this to Paket?

forki commented 9 years ago

I think this sounds like a great feature. Many projects have a lib folder where additional dlls are placed.

Thorium commented 9 years ago

Just listing external dlls in paket.dependencies and paket.lock would be easy. It is nice-to-know the dependencies for dll-structures. But this benefit is only informational. To get real functional benefits, we should be able to map dlls to the corresponding NuGet-packages.

Mapping to Nuget is trivial for packages that have same dll-name as nuget-id, like:

But then, there are also non-trivials, and some packages contain multiple dlls:

forki commented 9 years ago

I don't get this nuget mapping - what's the goal?

isaacabraham commented 9 years ago

I'm using some NuGet packages locally (funnily enough, in a lib folder) - either from private repos or similar - for performance reasons.

What's the use case behind this - either (a) that you have some random DLLs which aren't NuGet compatible, in which case is it even possible to make them look like NuGet packages, or (b) you have some NuGet packages that don't exist in a real NuGet server - in which case you can just use the local file system.

forki commented 9 years ago

b) is already covered by http://fsprojects.github.io/Paket/nuget-dependencies.html#Path-sources

isaacabraham commented 9 years ago

@forki exactly. and that's exactly what i'm doing now :-)

Thorium commented 9 years ago

Well, I'm testing for many things just to manage complex dependency-hierarchies. But I guess the main problem is this:

Let's say that I have (quite typical) enterprise-application, e.g. 50 solutions having 500 csproj-files or more. They use old direct projects reference dll without NuGet, so hint-path in the csproj-file: ........\lib\EntityFramework\EntityFramework.dll (5.0.0.0) (ok, bunch of other dlls also, but let this EF be an example for now.)

Now, I have also 20 new projects in this same enterprise application. They also use EntityFramework, but via NuGet. They build to this same bin-folder. If each project\bin would be separate, then I would have 520 copies of EntityFramework.dll in my hard drive.

(Actually there are a few bin folders, separated with the business-boundaries, but whatever: many projects and solutions build to the same bin.)

Managing packages.config-files between different sln-solutions (and syncing to these lib-versions) is painful. I think Paket will handle references between solutions better than NuGet.

Now we know that we can't update those new 20 projects to EntityFramework 6.1.0.0 because it would conflict bin with those 500 other projects. But Paket don't know this.

So you suggest downloading those nuget-packages to lib-folder? And make fake ones for the dll's that won't have any?

I don't know how to replace 500 projects to use NuGet without manual work. (Of course I have F#-scripts to manage and modify these 500 .csproj-files so this could be possible.)

My goal is to

Thorium commented 9 years ago

I close this as file assembly versions do not correspond to the NuGet package versions. So the right solution is to first migrate to NuGet.