All:
I need advise on how to use Nuget to make my project dependencies (libraries) available to other developers who will in turn have my project as dependency. See scenario below for details:
I have created a Visual Studio 2013 project (ProjA) in a solution (SolA) which has a dependency on a Library (LibA [which I do not commit into source control]). I have used Nuget to manage/fetch the dependencies of project ProjA (i.e. library LibA) via Nuget.Config in .nuget folder at solution SolA level and everything is working ok. Developers are able to checkout solution SolA and build/deploy with Nuget fetching LibA from a local server.
My issue is that I now need to have developers build their project (ProjB) in another solution (SolB) but which will import/use ProjA as a dependent project. Issue is that I cannot find a way to make Nuget fetch the dependencies of ProjA (i.e. LibA) when built as part of solution SolB. I tried putting the Nuget.Config File in the level of ProjA, but VS build seems to ignore it.
Any ideas????
You seem to be mixing two different but not-very-compatible approaches to code sharing here:
Code-level dependencies
Package-level dependencies
Code-level dependencies between different solutions are generally A Bad Thing, and you should avoid them. A solution should encapsulate and build all the source code it needs to, relying on 'library' DLLs (whether provided as raw DLLs or via NuGet).
I recommend that you re-work your solutions using the 'Package-level dependency' pattern, so that you have a separate 'library' solution which provides a NuGet package (or set of NuGet packages) which the other two solutions can consume:
Here is the current (awkward) dependency graph:
Solution A Solution B
Proj A -----------> Proj B
^--------------------'
Here is what I propose with the separate library solution:
+----> Solution L <----+
| |
Solution A Solution B
Solution A and Solution B thus consume the NuGet packages produced by Solution L (the library project). This is the dependency relationship which probably underlies your code anyhow, based on what you describe.
Related
I'm currently starting with JFrog Artifactory. Up to now I have only been working with source code control systems not with binary repositories.
Can someone please tell how the versioning of files is done in Artifactory?
I have been trying to deploy a file, then change it and deploy it again.
The checksum has changed, so it's the new file. But it seems that the old version is gone.
So it looks like there are no version of files. If I want that do I have to do it in the filename?
I found versions related to packages.
But I was thinking to use it for other files as well.
Thanks for your help
Christoph
Artifactory, unlike a VCS system, is not managing a history of versions for a given path. When you deploy an artifacts over an existing artifact, it will overwrite it (you can block this by configuring the right permissions).
If you wish to manage permission for generic artifacts (ones which are not managed by a known package manager like npm, Maven etc.), there are a couple of options you can take:
Add the version as part of the artifact name, for example foo-1.0.0.zip
Add the version as part of the artifact path, for example /foo/1.0.0/foo.zip
Combine the 2 above approaches, for example /foo/1.0.0/foo-1.0.0.zip
Use an existing package management tool which is flexible enough to handle generic packages. Many people are using Maven to manage all types of packages beyond Java ones (it comes with its pros and cons)
From the Artifactory point of view there are a couple of capabilities you can leverage:
Generic repositories - aimed at managing proprietary packages which are not managed by a known package manager
Custom repository layout - can be used to define a custom layout for your generic repository and assist with tasks like automatic snapshot version cleanup
Properties - can be used to add version (and other) metadata to your artifacts which can used for searching, querying,resolution and more
Lastly, Conan is another option you should consider. Conan is a package manager intended for C and C++ packages. It is natively supported in Artifactory and can give you a more complete solution for managing your C libraries.
I have a C# solution which contains 3 projects; Application.Server, Application.Client, and Application.Common. Both server and client have a project reference to common.
I want to pack server and client up so that they can be used by other teams in my organisation. I have some automated build pipeline set up that do so, and they publish the nuget packages for server and client. They do not package or publish common. When I inspect the nuget packages, I can see that they reference the common package.
Is there a way that I can get them to build that project into them self? Ideally I don't want to publish the common package as it's pretty specific to my application, and it doesn't really make sense that it's something that's independently consumable by other departments. I also don't want to have to worry about wrangling extra nuget packages if I can help it (as in reality, Common is actually several projects).
If your projects are "old style"/non-SDK/traditional csproj, AND if any project uses a NuGet package, if all those NuGet references are defined using packages.config, then use you can use nuget.exe pack -IncludeReferencedProjects. However, if any of your projects use PackageReference to define their package references (new, SDK-style projects can only use PackageReference), then nuget.exe pack will not correctly create NuGet dependencies for those packages. For SDK style multi-targeting projects, nuget pack will probably completely fail.
The only supported way to pack projects that use PackageReference, or any SDK style project, is to use NuGet's MSBuild pack target (either dotnet pack or msbuild -t:pack). However, this does not have an equivalent to nuget.exe's IncludeReferencedProjects.
If your projects are SDK style, it really shouldn't be any more difficult to create and publish one package or many packages. Simply run dotnet pack on your solution, and every packable project gets packed (remember to mark any class library project you don't want to become a package as not packable). Then use your favourite scripting language to find and publish all nupkg files. For example (Get-ChildItem -Recurse -Filter *.nupkg $SLN_DIR | ForEach-Object { & dotnet nuget push $_ }, or copy/move all nupkgs to a single place (or use the appropriate setting to make NuGet create the packages there in the first place) and use dotnet nuget push *.nupkg.
The NuGet team recommends one package per assembly, and the tooling automatically creates NuGet dependencies for project references, so it all "just works" out of the box. To create a package with all the assemblies included, instead of NuGet dependencies, requires you to do a bunch of work.
I'm checking for ways to add a reference to a project in another solution.
To be specific, I can add the reference to a project, even if it is in another solution. But I met 2 issues:
It refer the project by relative path, which may or may not exist if
my colleagues update the project
The Nuget package is not there (it is in the other solution's package folder)
For example, Let's say Project Restaurant (Solution A) depends on Project HotDog (Solution B). On project HotDog we refers a library Quartz for example.
But when we build, it would throw an exception "cannot find Quartz" because the reference of HotDog is pointing to "../packages", not "[Path_to_solutionB]\packages"
Of course we can re-add the reference but this solution is temporary only and will not work on our CI server (will retrieve these configurations through SVN).
I think there must be a way. So is there any best practice to cross-reference project in different solutions, without impacting the solution-managed Nuget Lib Packages?
I created a new asp.net project, and I am using the monodevelop as the ide.
On the left hand side in the explorer I can see two sections, one is called reference and the other called packages.
I assume that references are the library or dependency files like the jar equivalent of java. Then what are the packages section for?
Is it also another kind of dependency?
Can anybody help me understand the meaning of those two sections?
I assume you mean References and Packages. There is no Resources section/folder when I create an ASP.NET project in MonoDevelop.
The References folder will show the assemblies that are being referenced by your project. An assembly is equivalent to a jar file.
The Packages folder shows you the NuGet packages that are being used by your project. A NuGet package will typically provide assemblies and these will be shown inside the References folder but within a From Packages folder. A NuGet package may include other things, such as content files, which are added to the project, or custom MSBuild targets which modify the build behaviour.
I wish this is a stupid duplicate of an already answered question.
I have a asp.net website that depends on some other projects (dlls copied to bin). Now, what I want is every time any of those projects are updated, I get latest dlls in my website/bin. I DO NOT want my CI server to check-in updated dlls.
I already have a private NuGet feed for my project, and just want it to serve the latest dlls after each successful CI build. Now, my questions are
Is there a way to directly serve the dlls, without creating nupkg? And probably pick them from build output folder? (for some reasons, it's not that convenient to create package as a post build task for all the dlls hundred times a day) If that is possible, awesome!
If not, can we avoid increasing version number of dlls each time, still make nuget update to the new dlls? Something like update based on latest publish date or something? (there is huge bunch of dlls, and lot of dependencies)
Is there a way to take latest dlls without building the solution? Yeah, I can do a nuget update command, but is there any other way?
Someone suggested mirroring my current code base and using something like MyGet or ProGet. For several reasons, that is not feasible at the moment.
Triggering a Visual Studio build after any NuGet dependencies is probably not quite what you really need - that's a job for CI. However, you can set the version ranges in your packages.config file to make VS (via nuget) pull newer NuGet packages when available.
To answer your specific points:
Why would you want to server 'random' loose DLLs whose origin you cannot be certain of? NuGet provides a mechanism to track the origin of code on which your own code depends, which makes tracking down bugs easier :) If you rely on NuGet packages containing DLLs which change 'hundreds of times a day' then you should likely just build those DLLs directly with your application.
See #1 - if you are re-building NuGet packages very often, then you likely have your package boundaries wrong. Consider how truly independent your packages are, and see if it would makes sense to bring some of the DLLs together, or even separate out (fork) code which is shared between multiple separate applications. If you create a new version of a NuGet package, then you should increase the version number - that's a fundamental premise of semantic versioning, and you'll get into a mess if you do not follow this pattern.
To bring down the latest NuGet dependencies, nuget update is your friend :)
Using MyGet or ProGet might be part of a solution, but it's not directly related to the patterns you mention above.