I am fairly new to C# development and my organization has a location on one of their servers that contains nuget packages that were created by a past developer. I have the location of the packages mounted on my machine as a network location, when I try and add a new package source and browse to the location of the directory containing all of the .nupkg files and then browse for the packages in the NuGet Package Manager it comes up with no results. I have even downloaded the packages to my local machine and tried adding the source to the directory that is on my C: drive and still I get no packages to pick from. What am I doing wrong?
NuGet has documentation on installing packages and adding sources in Visual Studio.
Although, I'm not a fan of using the Visual Studio options page to add sources. When you add a source there, it's added to your user profile's nuget.config file, which means that all solutions on the same computer will use that source (unless the solution has it's own nuget.config file that uses <clear /> to remove all inherited sources). It also means that if you share the project/solution, anyone else using the solution will not have the correct sources. So, it's best to add an nuget.config file next to the solution and set up the correct sources there. A quick way to get started is to use dotnet new nugetconfig from a command line, assuming you have the .NET Core SDK installed.
Related
Warning, wall of text ahead. tl;dr I can step into a local nuget package on my computer I developed, coworkers can't. help?
I developed a nuget package on my main dev machine and pushed it to our local nuget server. I was surprised to find on my computer, I am able to step into the nuget package once referenced in other projects. My coworkers (and my other PC) are not able to step into the nuget package. I've done a lot of searching and people referncing things like setting up a symbol server or pulling pdb files etc. I'm not opposed to doing that, BUT, I didn't do any of that on my main machine where I can step into the nuget package. Literally the only thing I did is build / compile the nuget pkg and push it to the server and then open another instance of Visual Studio with a differnet project and I can step in. Can anyone help fiure out why I can step in and others can't?
I don't fully understand what happened other than perhaps it's visual studio caching symbols, but doing the following has allowed my other machine and a coworker's PC to step into our nuget package. I initially published the nuget package with this command dotnet nuget push GenRepo.1.0.10.nupkg -s http://10.10.10.30/nuget
Close all instances of Visual Studio
Pull nuget package source code onto coworker machine
Build and compile nuget package code and ensure the option to create .nupkg on build is selected
Open another Visual Studio instance with the other project that is referencing the nuget package
All of the sudden coworker can step into the nuget package
As I said, I don't fully understand what's happened here as I didn't set up a symbol server or anything of that nature.
EDIT
One thing to note, we had to move the file paths for the solution files on my coworkers computer to match mine before it worked
I have a C# project on Git that uses libraries from NuGet. Everything works fine, but when I pull on a fresh new machine and open the solution in Visual Studio it won't compile because of broken references. If I click on the references under the project I can see the classic warning sign with the yellow exclamation mark.
Nuget restore won't do anything (and I still haven't found any use of this feature...), files repositories.config are fine. If I right click on solution and then 'Manage NuGet packages for solution' no installed package is shown.
To this day I solved it this way: run
Install-Package package_name
it says:
'package_name' already installed.
My_project already has a reference to 'package_name'.
...and after that it shows the packages on the Manager, already assigned to the correct project.
NOTHING HAS BEEN CHANGED in the code ANYWHERE, I can see that because there are no differences on Git.
I have to do it only once on new machines, but it's really annoying. Any idea?
NuGet version: 2.8.60318.667
UPDATE 27/07
I tried the procedure from scratch on another PC, with windows 10, and everything works... same version of Visual Studio, NuGet, etc... I'm baffled
This is probably because of the incorrect path of the .dll in your .csproj. The package restore downloads the packages to the local directory. It doesn't change the reference path of the assembly in the .csproj, meaning that the project will still try to locate dlls on the local directory. The yellow mark means the project is unable to locate the assembly.
Unload the project, right click on project and select "Edit .csproj", and verify the path of missing dlls. For example - If you have NUnit,
<Reference Include="nunit.framework">
<HintPath>..\packages\NUnit.3.6.1\lib\net45\nunit.framework.dll</HintPath>
</Reference>
verify if the dll is present inside "\packages\NUnit.3.6.1\lib\net45" directory.
From the top of my head I can think of a few reasons the packages are not being downloaded, ideally you would have to share a few more details.
First the install-package command won't work. Your packages are already installed VS is just unable to download them, so it makes sense that you are getting that error.
First and foremost is this a public package hosted in nuget.org like
System.MVC.Web? Because if this is in a new machine, using a private nuget server, you need to
configure that source in Tools > Options > Nuget Package Manager >
Package Sources. (See https://learn.microsoft.com/en-us/nuget/tools/package-manager-ui for more details)
Check if you have added the folders to your git repo but at the same
time set the exclusion for its contents. To check that when you do a
clean checkout see if the folders exist but are empty. If thats the
case just remove the folders, the git ignore should do its job from
now on, and everyone new clone will do the proper check.
If the two above which are the most likely ones to be the reason do
not work. Try and restore the packages from the Package Manager
Console and update your post with the details.
You can open the Package Manager Console and type:
Update-Package -reinstall
or
Update-Package -reinstall -Project YourProjectName
FYI there's comprehensive document from Microsoft - https://learn.microsoft.com/en-us/nuget/consume-packages/package-restore - on the multiple ways of restoring nuget packages
try removing your package from below nuget cache folder so that NUGET is forced to download from source
C:\Users\<< your user name >>\.nuget\packages
I experienced this issue today, and upgrading to the latest version of VS 2017 (15.8.7) didn't help at all.
Check your packages.config file(s) to see if your packages tag looks like this:
<packages xmlns="urn:packages">
If it does, remove the xmlns attribute so it's just:
<packages>
That fixed it for me!
I have solved this problem. Follow this steps
In Visual Studio, click Tools > Extension and Updates.
Navigate to Online, search for "NuGet Package Manager for Visual
Studio" and click Update.
(If there is no button Update, navigate to Updates > Visual
Studio Gallery, find the "NuGet Package Manager for Visual
Studio" and click Update.)
Then restart Visual Studio.
Even after you've installed it at the Solution level, depending on your default you may have to pick which projects you want it to be available in. That was my problem.
I have a solution in Visual Studio 2015 that uses several NuGet packages. When I build in Visual Studio 2015, the packages are restored properly and the build succeeds. However, when I push that same project to Visual Studio Online, even though I have "Restore NuGet Packages" checked, the build fails because MSBuild cannot find the referenced binary.
I have looked at the build log and see that my packages are all being restored. Why, even though the package is restored, is the referenced binary not found during the build?
I found that the problem was not in the NuGet package restore, but in the way that the hint path was written in my .csproj file. To the fix the problem, change the hint path to point to the solution directory using the $(SolutionDir) variable.
For example, the NuGet restore pulled the Microsoft.WindowsAzure.Storage.dll binary, but it could not be found on the build of the project. To fix this, I had to open the .csproj, find the reference to the dll, and change the path from
..\packages\WindowsAzure.Storage.6.1.0\lib\net40\Microsoft.WindowsAzure.Storage.dll
-- to --
$(SolutionDir)\packages\WindowsAzure.Storage.6.1.0\lib\net40\Microsoft.WindowsAzure.Storage.dll
By using the $(SolutionDir) variable, Visual Studio Team Services was able to find my referenced dll and build my project properly.
You might also consider checking if the file packages.config, which surely resides on you local system, also gets checked in and is under version control.
First, you might want to see if it's present at the build server (image below is from VS Team Services but it's the same general idea in on-site environment.
Secondly, verify that the file's under version control. As a test, see if it appears under Pending Changes if you add a package.
I made a project with a working build start to fail when I added nUnit. Then, as I checked in the package.config file, it started to restore the packages on the server. When I removed the file from the server, the builds starter to fail again. Details are described in this post.
I have a .NET Web Application, and I include some 3rd party references in a folder called references. That folder is in the same directory as the Visual Studios solution, but not the same directory as the Project File. Now, when I first create this project, add my references, and build - everything works perfectly. However - once I check in to TFS and then try pulling down the code, the references cannot be found. They still exist in the "references" folder that I created, but they are not showing up in the bin folder. Any suggestions on what I can do to fix this? I'm using Visual Studios 2012.
When you checkin to TFS, make sure you checkin those DLLs. By default, TFS excludes binary files during checkin.
Also, if those 3rd party Dlls are hosted on Nuget, then use Nuget packages to add/manage references. That way, you do not have to bother checkin them into TFS. You can simply enable Nuget's package restore on build (right click on Solution -> Enable Nuget Package Restore). More info here.
I'm trying to install a custom test adapter via NuGet, but it seems like VS isn't recognizing it. I've looked through the code in Microsoft.VisualStudio.TestWindow.VsAdapters.UnitTestExtensionDiscoverer, so I've realized the dll has to end with *.TestAdapter.dll. Using that name makes vstest.console work for me when I specify /TestAdapterPath, so I'm not sure why the VS2013 test window isn't showing my tests.
The adapter does work when installed by copying the relevant files to C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\CommonExtensions\Microsoft\TestWindow\Extensions.
Are there any other path or filename conventions I need to follow for VS2013 to load my test adapter? Without any logging or error messages I'm really not sure how to gather more information to debug this.
The issue seems to have been that I was trying to debug by overwriting my dlls in the packages directory. This doesn't work because VS copies your package directory to something like:
%TEMP%\VisualStudioTestExplorerExtensions\My.TestAdapter.1.0.0.23
essentially caching it with the key being the version number. If you copy the file into the project packages directory VS won't copy it because the folder number didn't change. So, to update your extension you have to keep publishing NuGet packages.
At least that's how I understand it.
Edit: I've also noticed that when you upgrade your test adapter through NuGet, it won't start using the new version until you restart VS, or kill vstest.*