I just got the following question from a developer. I know Nexus can manage this through Maven, but don't have experience with .Net applications. Maybe it's managed by NuGet?
I just want to ensure that Nexus can resolve dependencies multiple
levels deep.
So for example... I have a project, which depends on dll "A". This
has two dependencies itself, dlls "B" and "C". "B" then also depends
on "D", which itself depends on "E".
I need to know that when our project references dll "A", that Nexus
will not only install the correct version of this, but also dlls "B",
"C", "D" and "E".
Essentially, it must know how to resolve the entire dependency tree,
infinite levels deep, not just the immediate dependency, which in this
example would just be "A". I do believe Nexus can do this,
Artifactory made a point of mentioning this in the demo, so I simply
want to ensure that Nexus does indeed have the same functionality.
Yes. When you install a NuGet package from Nexus, your nuget client (e.g. the nuget cmdline client, or Visual Studio) makes a request to Nexus repository, and then it makes follow-up requests for all of the dependencies, which Nexus will also supply.
Related
I have a few issues:
When I want to add 'Google dependency' I can simply open project
dependencies and choose proper library dependency, but this is not
working for all 3rd party libraries (ex. Retrofit). So I have to go
to their website copy URL and figure out the required version and
combine proper URL- it would be nice to have some kind of auto
completion here, to make this process faster.
Is there a simple way to check for newer versions? Ex. I have 10
dependencies in my project and I would like to know if some of them
should be updated (I know I may update versions automatically, but I
don't always want this)
Android Studio highlights outdated dependencies in your app build.gradle file. If you mouse over the highlighted dependency, it will tell you the newest version.
To update the dependency, just replace the current version (e.g. 'com.android.support:appcompat-v7:25.4.0') with the new version (e.g. 'com.android.support:appcompat-v7:26.0.0'
When updating a project to use current Catel version (4.0) I am getting this warning:
All projects referencing MyInfrastructureProject.csproj must install nuget package Microsoft.Bcl.Build. For more information, see http://go.microsoft.com/fwlink/?LinkID=317569.
The error is reported for projects that references MyInfrastructureProject.csproj.
I find it odd that I need to add additional libraries to other project especially when it is concerned with nuget (if I am getting the picture correctly) and not with actual functionality of my code (or maybe even Catel). But in any case, I don't really understand the issue.
I searched a little for this issue but didn't find relevant details or explanations.
Should I go ahead and add the Microsoft.Bcl.Build reference everywhere in my project?
Thanks,
Tomer
If you don't know what is Microsoft.Bcl.Async you should study it.
Catel uses this feature pack so as to use async/await on .NET 4 and Silverlight 5. So if you use Catel in a .NET 4 project, you inherit the same dependencies, which is what the warning says.
Thus, yes, please go ahead and add the NuGet package to the necessary projects, or simply upgrade your projects to .NET 4.5 and reapply the NuGet packages.
What is the best way to handle specific version of libraries while using MonoDevelop (precisely - use ServiceStack v3 instead of ServiceStack v4)?
Unfortunately, MonoDevelop's addin NuGet does not allow specifying package version (no Package management console support). I've tried hacking it in .csproj and package.config file but it does not work entirely well and it seems to be smelly solution.
One obvious solution is to get rid of NuGet and reference libraries locally after manually downloading them.
How would you solve this problem?
Thanks for all responses :)
Being able to add a specific version of a NuGet package with the MonoDevelop addin is on the todo list.
If you have access to Windows you could use SharpDevelop to add a specific version using its Package Management console.
Or as you have suggested, edit the packages.config file, then restore the packages. However you will need to add the required assembly references by hand. This option is not that bad if there are not that many assembly references and you are not going to be updating the NuGet package very often. Although the benefit of this approach over downloading the NuGet package, extracting it, and directly referencing the assemblies is equivalent and the same amount of work. Also doing it this way you can more easily update the references by simply dropping the new binaries into your lib folder.
Or you could change the source code of the addin. I thought about adding a simple text box where you could specify a particular version. Ideally the dialog would give you a list of available versions.
I would probably just download the ServiceStack assemblies you need and directly reference them.
Our small, distributed team uses a NuGet package in a project. That package has a bug in the current release. Unfortunately the package does not publish debug symbols and source, so I grabbed & built the latest source, removed the project via NuGet and added a (temporary) reference to the project I just built locally.
Turns out, the issue is fixed in the latest code base.
This particular project only seems to release updates on NuGet every 6 months or so.
Until that next release, our team needs to use the code version where the bug is fixed.
One option certainly is to check the source code into our source code repository and keep the project reference (rather than a NuGet reference), essentially treating it as an internal utility project.
That feels "old school" though.
Is there a better way to manage this situation, using the NuGet infrastructure?
One option is to create your own NuGet package with the updated code. Then add a new Local Package source (just create a file share and place the .nupkg file there). Move the local package source up higher in priority than the official one so NuGet will use your package before looking online.
In fact I recommend copying all NuGet packages to a local repository, especially if you use package restore. This way you are not dependent on nuget.org to be up all the time (there have been several instances of downtime).
The one drawback is that when an updated package is finally published to nuget.org, Update-Package will not pick up the new one unless you specify the package source.
Anyway this will allow you to continue to use NuGet while waiting for your updated package.
We're building a set of several services, each service has it's own solution with associated projects. Many of these services rely on the same NuGet packages.
All the solutions have "Package Restore" enabled.
Some of the solutions refer to assemblies owned by other solutions, this is one obvious reason why we need all the solutions to refer to exactly the same versions of different NuGet Packages.
All of the services need to work together to achieve an end result. They're packaged and installed as part of a single product, which is another reason we'd like everything to be running off the same versions of the NuGet Packages
We're having trouble keeping package versions consistent between Solutions.
Currently we're manually checking and updating package versions, we're also getting occasional compilation errors because projects in one solution end up referring to different versions of the same package.
Is there a recommended way of doing this (hopefully an automatic process)?
Would we be better off without Package Restore?
Anyone have any general advice on the subject?
Thanks
Update: I created an issue for this on the NugGet project http://nuget.codeplex.com/workitem/2623
To solve this:
Create your own private NuGet server (see 1 and 2) that hosts the correct versions of the packages you use.
Configure each build system to use that server and auto update to the latest version.
Although this requires a server, it not only ensures everyone has the correct version but speeds up the downloads for build servers as well.
You could configure your TFS builds to update all NuGet packages in the solution to their latest versions using the nuget update command.
The latest versions could be from nuget.org, a local NuGet server or even a network share. Use the source parameter to define the sources you want to update from.
You can perform the build configuration via MsBuild proj files or via a TFS template.