One of the nuget packages that I am using have a minor problem that I have solved with a pull request. I would however want to include the fix in the build of my own application and I do not want to wait until the fix is released as part of a new version of the nuget package. Which procedure should I now follow to achieve this?
Can I keep my package reference and override the assembly provided by nuget with my own custom version of the assembly? I have tried to just copy the custom assembly to the corresponding location in nuget packages folder but it does not work.
Do I have to remove the nuget package reference and keep the custom library in my version control until the fix gets released?
Especiall when you're working with a team or using a build server, you'll want to not do an in-place replace of the same package version.
You can either add a direct reference to the custom-built assembly (and be sure to version it or to include the source in source control so your colleagues or the build server can compile it themselves), or create a new NuGet package with a higher version number and upgrade to that version.
If you don't have a private NuGet server, you can simply add a (shared) directory as package source for your custom built package, as explained in How to install a Nuget Package .nupkg file locally?.
It may work with the same package version, but then you'll have to remove and reinstall it, and make sure it isn't cached anywhere so the old package won't simply be added again. So you better just change the version number.
Related
I'm adding the PosGreSQL NuGet Package to my solution. As a part of this, there are list of other NuGet Packages that are getting installed automatically which I don't intend to install. How to get rid of this?
Below are the packages installed automatically along with PosGreSQL Nuget Package.
Microsoft.Bcl.AsyncInterfaces.7.0.0, Microsoft.Bcl.HashCode.1.1.1, Microsoft.Extensions.Logging.Abstractions.6.0.0, System.Buffers.4.5.1, System.Collections.Immutable.7.0.0, System.Diagnostics.DiagnosticSource.6.0.0, System.Memory.4.5.5, System.Numerics.Vectors.4.5.0, System.Runtime.CompilerServices.Unsafe.6.0.0, System.Text.Encodings.Web.7.0.0, System.Text.Json.7.0.0, System.Threading.Channels.7.0.0, System.Threading.Tasks.Extensions.4.5.4, System.ValueTuple.4.5.0
I tried deleting the additional Nuget packages manually but Build Solution again adds these NuGet Packages.
How to get rid of this?
You don't. Because those are dependencies of the package you want to install. The package you want to use needs those other packages to work.
You should basically just not worry about them, unless a dependency causes a very specific issue. You could potentially pick and choose between different versions of the package you want, to try to find a version with fewer dependencies, but that's not normally worth doing.
My Scenario:
I am writing one C# class library and I need to use one of the nuget package from a private feed. There may be a chance that new version of the dependent nuget package would have been released.
My requirement here is "I want to check the nuget feed for latest version and if available upgrade the nuget package with the latest version". Like deleting the existing version and install new version or any other way.
I was trying with NuGet.Client (https://learn.microsoft.com/en-us/nuget/reference/nuget-client-sdk), But not found exact solution.
Could you please suggest me a solution for my scenario.
I'm working on upgrading one of our WPF applications. During my upgrade, I converted the application from using the packages.config format for NuGet packages to using the PackageReference format.
Everything seemed to work fine locally, but our build agent started complaining about our NuGet packages:
Error MSB3188: Assembly
'C:\Users\tfs\.nuget\packages\Utils\1.0.0\lib\net45\Utils.dll' must be
strong signed in order to be marked as a prerequisite.
This sort of makes sense because the Utils package is not referenced directly anymore. When you utilize the packages.config format, every NuGet package is referenced by the project, but when you utilize the PackageReference format, only the top-level packages are referenced; package dependencies are not included. Additionally, any projects which are referenced which have a NuGet dependency not explicitly referenced by the WPF project are also affected.
Adding the package dependencies directly to the WPF project solves this issue, but it seems like it shouldn't have to be done that way.
What's strange is when I go into the publish settings / application files for the project, the assemblies are not listed as Prerequisite, but they are marked as Install (Auto) instead.
Short of adding the NuGet package dependencies (not simply the top-level packages), what are my options here? Is there some sort of setting or msbuild parameter, etc. which I can use that allows me to use the PackageReference format while still only referencing the top-level packages?
I am trying to make Newtonsoft.json available for use in my local Visual Studio 2010 projects. I installed NuGet.Tools on my system. Now I see an item in the Solution Explorer called Service References that wasn't there before, but I don't understand how to use that to reference the Newtonsoft package I also downloaded, which is currently in my Downloads folder. Do I need to move the package to a different location to reference it?
Thanks for your help.
You can right click on the project where you want to install newtonsoft nuget package.
You will find an option "Manage NuGet packages".
Then search online for "newtonsoft".
This would add a packages.config file in your project (depending on which framework you are targeting to ).
this new file contains all the nuget dependencies required for this project.
Refer this blog for more details
VS2010 is old and is unable to update to the latest NuGet version. This means that adding recent packages will often fail; however, you can often add an older version of a package that has a compatible NuGet version and it will work. This causes the suggested answer by #ManojChoudhari to fail for me. In the case of Newtonsoft.Json, the following worked using the Package Manager Console:
Install-Package Newtonsoft.Json -Version 9.0.1
I have an asp.net application using EF, MVC4 and some additional packages. Whenever I try to open the project on a different PC I have issues with the installed packages. My references are marked as missing, and the code is far from compilable. Last time I solved it by deleting references and packages and installing the needed packages one by one. I find the solution tedious. Is there any better, global solution for this? How is this supposed to be done? Shouldn't this be automated?
Thanks for the help and pointers!
UPDATE
I DO use NuGet Packages, (otherwise it would be very hard to get all these dlls) but somehow I always end up with uninstalling and reinstalling the packages to make my project work. I always end up with wrong versions and not compiling code.
I end up doing the following:
Delete package.config
Delete dependencies from the web.config file
NuGet Package Manager Console:
PM> Uninstall-Package A.B.C
PM> Install-Package A.B.C
Clean - rebuild project and hope for the best
I think Uninstall - Install can be replaced with Update-Package –reinstall A.B.C
I was hoping that there is a simpler solution for this.
If using visual studio; you can enable automatic package restore; this article outlines nuget in detail.
If you go to Tools -> Options -> NuGetPackage Manager you can make sure that the auto download is enabled. See the screenshot below.
Without knowing which references are broken, I would assume that you can at least use NuGet Packages to manage Entity Framework and additional framework references.
As lucian.jp said nuget it probably the way to go. At my company, we usually will go out of our way to find and use only packages that have maintained nuget packages, and even most of the core Microsoft ones have them, for example https://www.nuget.org/packages/Microsoft.AspNet.Mvc/
For the other ones, keeping a little thirdparty folder with external assemblies/dlls in the root of your repository and then reference from your project to that instead of from some random place on your hard-drive. I.e. check the third party assemblies into your project somewhere that is not your bin directories.
So if you have an existing project, here is what I suggest you do to avoid future issues:
For each of the assemblies, including your MVC ones, find the nuget equivalent, remove the dll from your project and add it back using the nuget package manager.
Get a copy of all the remaining assemblies and create a folder in the root of your repository and place them in there, then delete all of them and add them back in referencing the dlls from that folder.
If you are using git I'd also use .gitignore to not check in your bin directories. Which will force a new deployment of your code to get the assemblies from their respective sources.
Use Nuget for DLL packages like EF and MVC. But do not use Nuget for JS / CSS packages instead go for bower. Nuget packages for CSS and JS libraries are good but just their installation and uninstallation is tricky and may not match your project structure.