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
Related
I recently added an NUnit 3 Unit Test project for Xamarin.Android into my app's solution in Visual Studio 2019. I was able to configure it and get it running (successfully with some tests, even!), but as soon as I checked the project into our repository and pulled it to a new machine, I'm unable to get it working in any capacity that I've tried. Every time I try to build, I'm presented with the error "This project references NuGet package(s) that are missing from this computer." The packages are definitely available in the project directory, and NuGet Package Manager seems to recognize that they are there.
So far, I have tried:
Uninstalling and reinstalling the packages through NuGet Package Manager
Trying Update-Package -Reinstall in the PM console
Trying Update-Package -Reinstall -ProjectName myProject in PM console and specifically targeting the test project.
Trying Update-Package -Reinstall -Safe in PM console
Manually modifying .csproj with .dll directories for package references.
After each of these, I was presented with the same error. "This project references NuGet package(s) that are missing from this computer." I know for a fact they aren't. What am I missing here? In addition, am I going to have to go through this process every time that the project is pulled to a new machine?
Update:
After some trial and error, I was able to build the test project, deploy it to a virtual device and run it successfully by following these steps:
In the Explorer view of the project in Visual Studio, I deleted the 'packages' folder in the root directory of the project.
I opened a Package Manager Console window to try Update-Package -Reinstall again, but this time the PM console window had a prompt telling me that Visual Studio noticed that there were referenced packages missing, and if I wanted to Restore them. I clicked 'Restore' and waited for the task to complete.
At this point I was able to build successfully, but when attempting to deploy to a virtual Android device, I was presented with an error: "The LinkAssemblies task has failed unexpectedly."
I installed the latest available Android SDK (API 28, Android Pie), and changed the Target Framework of the test project to match.
This has me successfully running my NUnit test app on the Android emulator, but my concern now is that if I push any changes to origin, the next machine that tries to pull the project down will encounter the same issues I did. I suppose this updates the focus of my original question to: what have I done wrong to cause myself this problem, and how can I prevent it from carrying over to other machines that need to pull the project?
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.
We are moving our package management from manually updating files to NuGet. I am trying to install older versions of packages to match the one we already have in source control. There is no way to do this from the UI so I use the command line to get the proper version.
For some reason, Install-Package keeps on telling me that the nuget gallery is unreachable.
The source at nuget.org [https://www.nuget.org/api/v2/] is unreachable. Falling back to NuGet Local Cache
This happens only in one of our solutions. If I create a new solution or use another one in the same repository, packages will install as expected. I can even install the packages in a dummy solution to fill the local cache and then install them successfully in the faulty solution. I have tried to Invoke-WebRequest on the url from the NuGet Console and I get an HTTP 200.
What can cause this? Is there a way to override the package sources on a per solution/project basis?
Even though my Package Source was set to nuget.org in Package Manager Console, explicitly adding the -Source nuget.org argument fixed this for me.
So an example of use would be:
Install-Package Akka.net -Source nuget.org
Akka.net being your package that you want to install, its just an example here.
I had to copy the default NuGet source in Visual Studio's options. With the copied source, I changed the URL from https to http. This resolved the problem for me.
Credit for this suggestion belongs here: https://nuget.codeplex.com/discussions/561075#PostDetailsCell_1354351, to "jpharris4".
You can change NuGet source from UI as well. Just change NuGet source to older version and it should work fine.
There seems to be still few bugs in VS 2015 related to api.nuget.org (v3).
I'm not sure what can cause your issue, but there is indeed a way to override package sources on a per-solution basis, but only if you've enabled NuGet Package Restore on the given solution.
Once a solution has enabled NuGet Package Restore a folder called ".nuget" gets added to the solution. Under this will be a file called "NuGet.targets" that has an ItemGroup whose Condition is " '$(PackageSources)' == '' " like the one you'll see in the attached image.
If the ItemGroup is empty (or completely commented out, as in the illustration) then the solution will use a specific file that should be the same as the sources listed under TOOLS >> OPTIONS. But if you uncomment or add PackageSource items to that ItemGroup the solution will search the package sources listed and ONLY the ones listed.
In my Package Manager Console i could not see any sources
Going to:
Tools -> Options -> Nuget Package Manager -> Package Sources
I found the sources. Unchecking them, and them checking them back made the re-appear in my Package Manager Console
I had to provide the comman along with the full url as Install-Package MySql.Data.Entity -Version 6.9.8 -Source http://www.nuget.org/api/v2
In my case the cause was that the package had an agreement.
Through the UI - "Manage NuGet Packages" dialog you have the option to accept and continue.
The Package Manager Console in VS 2013 seems to have an issue with this.
As others have said restarting VS 2013 might resolve it for the console.
This is worked for me in VS 2015 prof: Tools -> Options -> Nuget Package Manager -> Package Sources
Press Add button
Edit in Name label: nuget.org
Edit in Source label: https://www.nuget.org/api/v2/
Press OK
Hope it helps ;)
I had the same issue with the same message. But the reason of my problem was lost connection to TFS. My TFS server was hosted in other network and I used VPN for access to it. When I tried to install the package without established connection to TFS (VPN was turned off) I got the same problem.
Be aware of this TFS behavior.
Happens because you work offline mode, when you reconnect the network will need to log off and log back. Package manager will smoothly re-initialize.
I have faced this issue VS2013 and wasted 3 hours of time.
Not Sure what was the cause of the issue. But none of the above solutions worked for me.
Re-Installtion of Nuget Package Manager console worked for me.
Tools - > Extensions and Updates -> Under All Look for Nuget Package Manager for Visual Studio and hit uninstall.
Go to https://marketplace.visualstudio.com/items?itemName=NuGetTeam.NuGetPackageManagerforVisualStudio2013 and download the extension.
enter image description hereMay be yours office/home firewall blocking nuget.org so try to connect different internet network for example from your mobile or wifi .I was able to solve through this method.
None of these solutions worked for me with VS2013. Yes I know it's the year 2020.
In the end I downloaded the nuget package to a local folder, added the folder to the nuget settings, and then voila!, was able to install the package.
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.*