For some reason Nuget ignores the default project I select from the drop down and always installs packages into my startup web project. I have a utility project, specifically for things like library dependencies and want Nuget to install packages there, but it always goes for the web project.
EDIT:
I eventually figured this out. It turns out that the solution file was under one particular projects directory. This was not how I normally create a solution, but I didn't create this originally so it didn't occur to me that this was the cause.
Try using command with project name
PM> Install-Package EntityFramework -ProjectName DataProvider
or Just right click on the Solution and select Manage NuGet Packages.
when you install it allows selecting the set of projects to install the package into.
Related
I have a multi-project solution with Prism Nuget packages installed in several projects. I then attempted to add a Prism Mef extensions package to one of the projects using the Nuget Package Manager UI (I have already added it to one of the other projects).
The first time I attempted to add the package, it failed to install one of the dependencies, no specific error reason, just "failed". So, I installed it a second time, all seemed to be fine, no errors reported, but a few of the references did not resolve.
So, I uninstalled the package and all dependencies and installed it again. Again all appeared fine, but more references do not resolve.
I have tried uninstalling and installing the package more times but get the same result every time now.
I have had this problem many times and I know its not specific to the Prism package as I've had it with loads of different packages.
I think its just a major bug with Nuget, but I'm hoping somebody will know an easy way to fix it. I think I usually have better success with the Nuget console, but I find it more effort to use.
I've done some searching online and not really found a good explanation of the cause of the problem or a way to resolve it.
Somebody at work completely refuses to have anything to do with Nuget as he has so many of these issues, but I am determined to make it work!
Within the Package Manager Console run the following command:
Update-Package -reinstall
This will reinstall each nuget package within that project which should resolve any missing references.
If you know you're missing a specific reference:
Update-Package -reinstall <Package-Name>
I just closed Visual Studio and reopened it and references are resolved...!
You need to follow this procedure.
1. Update-Package -reinstall
2. Restart visual studio.
You may want to check the .NET version of the package vs. your project.
I had an instance where my project was .NET 4.6.1, and the package I was attempting to install was using version 4.6.2. After updating my project to the same .NET version, the reference showed up.
I recently encountered this error on visual studio 2012, solution for me was to delete .nupkg file from nuget cache. Nuget cache location can be found from nuget settings > general > browse.
Note: I did not clear cache, I just deleted a specific file from cache directory and reinstalled the nuget package.
Delete all the <assemblyBinding> references from your .config file, then run this command from the Nuget Package Manager:
Get-Project -All | Add-BindingRedirect
This is how I fixed it.
I was working on a legacy .NET framework project (using <Reference Include... rather than PackageReference). The .dlls were referenced with a relative path that wasn't being resolved.
Fixed by changing to absolute paths, building, then changing back to the original relative paths.
For example:
<Reference Include="My.Package">
<HintPath>..\..\packages\My.Package.dll</HintPath>
</Reference>
Changed to:
<Reference Include="My.Package">
<HintPath>C:\Users\will\Documents\MySolution\packages\My.Package.dll</HintPath>
</Reference>
Then built and changed back to the relative path and the build still worked.
In our case, on one machine VS was holding onto an old version of a dependency, so references to newly added methods in the dependency were not resolving (even when package manager was reporting the latest version installed). The solution was to restart visual after uninstalling the dependency, then install again.
I have a library of nuget packages we use throughout our solutions, hosted in Azure Artifacts. These nuget packages are built with debug enabled so symbols are created and included in nuget packages.
Our projects in Visual Studio (mainly Net Core 3.1) reference these nuget packages in the normal way using Nuget Package Manager.
Each solution has SourceLink enabled so if I have any debugging requirements which require stepping into code within the referenced nuget package, I can set a breakpoint and do so quite nicely as Visual Studio downloads the sourcecode directly from Azure Artifacts.
That all works perfectly.
The issue is a productivity one. If code within the nuget package needs to be changed, I have to open the solution for the nuget package, change it, push it and wait for Azure to build. When built, I go to Nuget Package Manager, update the package, restart the app and 'hopefully' have resolved the issue. For something tricky, I can loop this process a few times which is a productivity killer.
Is there any way to debug directly in the solution for the nuget package from the solution referencing it? Or does anybody have a better process they use which is more productive?
You may try to use floating version that can resolve to the latest version in nuget. In this way, when there is updated package, your solution will load the latest version of the package during build.
<ItemGroup>
<PackageReference Include="NuGet.Packaging" Version="*" />
</ItemGroup>
Is there any way to debug directly in the solution for the nuget package from the solution referencing it?
Using project reference instead of the nuget package when you need to frequently modify and debug the source code in the nuget package.
When you consider production efficiency, please consider using project reference, when you consider portability, please try to use nuget. You could check my previous thread for detailed explanation.
For your situation, you could add the project for the nuget package to your referencing solution by the option Existing project：
Then select the project file .csproj for the nuget package.
After adding that project into your solution, you could add that project as project reference for your referencing project. Now, you could directly modify and debug the project for the nuget package.
When you finish this stage of work, you can return to the solution where the project for the nuget package is located, pack the new version of the nuget package and publish it.
I am working in an ASP.NET website (Website-A) code base which consumes an in-house NuGet package dependency.
Website-A consumes a pre-release of a NuGet dependency (Dependency-A). Opening Website-A and looking at "NuGet packages for solution" shows that Dependency-A is currently installed. Running "Restore NuGet packages" runs normally with no errors.
Rebuilding this .NET solution should result in a directory being created in one of the projects. (This directory will not be "included" in the project of Website-A, but the folder should be visible. I have clicked the "show all files" button.)
The issue is that this directory does not appear after rebuilding, nor after re-installing the dependency in NuGet package manager and then rebuilding.
We have discovered that if we manually delete the "packages" folder in the solution, and then "Restore NuGet packages", then rebuild the solution, the dependency will now create the directory like it should. It seems to need the "packages" folder to not exist in order to work like it should.
My question is: Is there something I am missing as far as a setting to automatically delete the packages folder? I would like to avoid having to manually delete this folder every time I need to update to a new pre-release of a NuGet package (we do a lot of this). I am using Visual Studio Enterprise 2017.
My question is: Is there something I am missing as far as a setting to
automatically delete the packages folder?
I'm afraid the answer is negative. AFAIK, VS doesn't have the option to delete the packages folder in Solution directory since it's not a normal way to do package update or package restore.
In addition: Do the pre-release packages have different names like packageName.1.2.0-beta1.nupkg,packageName.1.2.0-beta2.nupkg?
If your pre-release packages have different versions, and you update them using Update button in VS Package Manager UI, I think this strange issue you shouldn't encounter this issue. And if you have both projects in your local machine, it's not a good choice to develop locally with nuget packages...
Im making a nuget package for work that will be included in some of our projects. My question is this:
Is there a way to get the name of the project that the nuget package will be included in?
So far, I've tried this:
Assembly.GetCallingAssembly().GetName().Name
but when I run it, that gives me the name of the project in the Nuget package, rather than the name of the project the Nuget package is included in.
Edit----
The reason I for this is to make a network call to a centralized service from multiple different projects. Getting the project/solution name will be how the calls are differentiated.
Using the EntryAssembly works for me from my nuget package.
Assembly.GetEntryAssembly().GetName().Name
https://learn.microsoft.com/en-us/dotnet/api/system.reflection.assembly.getentryassembly?view=netcore-3.0
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.