As I add and remove references sometimes I don't always "uninstall" a package which appears like a reference. So it remains "installed" in the Nuget package explorer. It seem like I could really use something that cleans up the .csproj and the packages.config file -- is there something that does this?
This would be useful for both Visual Studio (VS) 2010 and VS 2012.
Uninstalling a package should be done as an explicit gesture.
If you want to know if a particular reference is part of a package, you can check the Path of the reference. If the hint path is something like "..\Packages\.." , you will know that the reference is part of a package.
I'm also looking for a tool to help with cleaning up the packages and at least identify unused Nuget packages for me. For now the manual way to check that a package is used or not is to uninstall the package and compile the project. If everything is still passing that means the package is not used. If things failed you can simply revert the changes in your source control system. You will need to repeat these steps for each package installed in your Visual Studio solution.
Related
I have two solutions. Both call extension method "AddDbContext" on an object of type IServiceCollection. Both solutions are .NET 5.
It works fine in one project, but the other project doesn't know about the extension method. Is there an easy way to determine which Nuget package I need to install? Short of Googling (which I can do), is there a simple way in Visual Studio to determine which package contains the extension method?
In the working solution I right click on the call to "AddDbContext" and go to definition. It's in namespace "Microsoft.Extensions.DependencyInjection" in file EntityFrameworkServiceCollectionExtensions.cs. Both solutions have package Microsoft.Extensions.DependencyInjection version 5.0.2 installed on the only project.
The solutions don't have all the same packages installed, but from their names I can't decipher which package installed might be adding IServiceCollection.AddDbContext.
I can Google this, of course, I just wonder if there is some menu in Visual Studio which can just tell me which package contains the extension method?
In this particular case, installing package Microsoft.EntityFrameworkCore v5.0.10 fixed the issue. But why was that package needed, and how could I have determined that using Visual Studio?
If you choose "Peek definition" instead of "Go to definition", then you see the full path of the assembly inside the region at the top of the definition. In the path you see what package it is from.
Some decompiler extensions (such as ILSpy or dotPeek) might also show it in the "Go to definition" view.
I am trying to use some references in Visual Studio, I have installed NuGet to use some libraries.
Is there a way to use only part of the package installed with NuGet? For example, if I am using TeklaOpenApi and the following .dll files are installed with this package:
TeklaModel
TeklaDialog
TeklaDrawing
Use for example just TeklaModel, could I do this using NuGet?
Is there a way to use only part of the package installed with NuGet?
I am afraid that you cannot get what you want. It is designed by nuget package. Usually, when the nuget package contains other dlls which means they are probably depended on a master DLL, or used at runtime.
All of them play an important role in this nuget, so we cannot easily remove them.
Although we can use Assembly Reference format(Right-click on References-->Add Reference--> choose one Dll) to reference the specific dll, but there is a risk that if the DLL depends on other corresponding DLL, an error will be reported. So we don't recommend it.
The best way is to install the whole nuget package with all the related dlls.
Hope it could help you.
In my solution some projects reference the "MahApps" NuGet package, which includes 'System.Windows.Interactivity.dll' 4.5.0.0. Some projects also reference the "Prism" NuGet package, which includes 'System.Windows.Interactivity.dll' 4.0.0.0.
The app.config has a binding redirect of "0.0.0.0-4.5.0.0" to "4.5.0.0" by the way.
A handful of projects reference both NuGet packages, and looking in their "References" lists some of them have S.W.I v4.5.0.0 while others have v4.0.0.0. (I'm guessing this randomness is down to the order in which the packages were installed to the projects).
Sometimes the solution will build and run fine, but if only make a code change in one of the projects referencing S.W.I 4.0.0.0 then I get a runtime error along the lines of "v4.5.0.0 could not be found". v4.0.0.0 is being copied to the build output folder but my binding redirect is telling it to expect 4.5.0.0.
Any thoughts on a solution? I could try uninstalling and reinstalling the packages in the projects causing the issue, to see if I can get them to reference the 4.5.0.0 in the MahApps package, but my concern is that this may not be guaranteed to work during a package restore, screwing it up for another developer (or the build server).
I ended up upgrading to Prism 6, which includes no DLLs other than its own. Thankfully it was a straightforward job.
I also had to remove the MahApps package then add it again, to get Visual Studio to add that package's System.Windows.Interactivity.dll (4.5.0.0).
When I add a nuget package reference via the Nuget Package Manager the installed dll references an old dll that was included in the solution directory.
I've seen this problem before in Visual Studio 2013 and it was fixable by editing the project file and changing the HintPath to the correct package location. Since upgrading to Visual Studio 2015 the HintPath is pointed to the correct package folder, so the fix no longer works.
Anyone have any suggestions on how to fix this?
I've tried searching the project for the bad dll path but can't find it. It has to be stored somewhere in the project. Sooo frustrating! Any ideas? Thanks
Update
I'm trying to reference the YouTube api dll package
We've just switched from SVN to TFS 2013, and I'm trying to set up a new gated build.
The project I'm currently working on has a couple of "referenced assemblies": DLL's it's dependent on which are fixed in place and don't have a nuget reference. As soon as I tried to compile my new build, it failed complaining it couldn't find these DLLs.
I assumed the answer was to include them in the solution somewhere. Which is fine, except that using solution folders appears to be a flaky, error-prone and rather rubbish way to fix things, as per Storing referenced Dlls in visual studio solution folder
However, that dates from 2011. Are there any better and more reliable ways of achieving this?
Don't discount the nuget option so quickly :) If there is no publicly available nuget package available you can wrap your assemblies in your own nuget package using the nuget package explorer:
https://npe.codeplex.com
Does the fact that you mention nuget mean you're already using nuget for other references? If so mdkes sensd to stick with it. Also are these reference assemblies third party or built internally?