Closed Thorium closed 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:
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?
I think this sounds like a great feature. Many projects have a lib
folder where additional dlls are placed.
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:
I don't get this nuget mapping - what's the goal?
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.
b) is already covered by http://fsprojects.github.io/Paket/nuget-dependencies.html#Path-sources
@forki exactly. and that's exactly what i'm doing now :-)
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
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.
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?