The following problem does not exist in VS2013 (Premium),I can only reproduce it in VS2015 (Enterprise)
I've added a custom NuGet package source.
If that source if not available I cannot install any package (for example EntityFramework)
I get a message
Attempting to gather dependency information for package
'EntityFramework.6.1.3' with respect to project 'ConsoleApplication9',
targeting '.NETFramework,Version=v4.5.2'
Exception'System.AggregateException' thrown when trying to add source
'http://XXX/FeedService.svc/'.
Please verify all your online package sources are available.
From the last line of the message I assume that this is not a bug but as I said it works on VS2013
Any idea why this has changed?
Can I do anything about this?
This is by design. Since we support searching across multiple sources for the packages that you need, we need to be able to reach all sources and get the package results before restoring these packages, to be deterministic and consistent in the way we do restore.
However, we understand that some users go into offline/online modes and we are investing in building a feature set that will enable you to temporarily disable some sources while you are working offline. In the meantime you can look into creating a custom nuget.config that does not contain the offending source and using that to restore when you are in the offline mode.
This is an old question so I'm surprised the workaround from the bug report wasn't added here. To save reader a click:
From within Visual Studio, open Tools -> Options -> NuGet Package
Manager -> Package Sources
Untick all of the package sources that are unavailable, leaving just
the public NuGet entries.
Install your packages as normal
Once you're back in your office follow steps 1 and 2 again but this time make sure everything is checked.
Related
I created my own Nuget Server following the documentation and I got it, but I cannot access the packages from Visual Studio 2019 Community Nuget Package Manager.
So, when I do it through a browser I get this, which seems fine:
When I click on "here" to view the packages I see the test one I added, and if I click it I can even download it:
However, when I access by Visual Studio I get this:
The full error says:
[Nuget Server] The V2 feed at
'http://mywebsite.com/NugetServer/Packages/Search()?$filter=IsLatestVersion&searchTerm=''&targetFramework=''&includePrerelease=false&$skip=0&$top=26&semVerLevel=2.0.0'
returned an unexpected status code '404 Not Found'. But I can't figure
out why.
This is how I added it to the Nuget Manager:
This is the folder structure of the site:
As you can see the package test.1.0.0.nupkg is where the NugetServer project told me to put it.
I tried several things:
Giving Everyone FullControl of the folder (because at the beginning I got 403 Forbiden instead of 404)
Changing the folder structure, puting the nupkg package inside a folder named nuget, put the whole Packages folder inside the nuget folder and other things I saw as solutions in other Stackoverflow threads.
Transforming everything to VB as this Stackoverflow thread suggested.
Changing IIS parameters
Nothing worked for me, so I need a bit of help to find the way.
Maybe I need something for the "Search()" to work? I'm lost.
If you need more info I can provide, just ask, please.
Please go to Tools > Nuget Package Manager > Package Sources and check the resource is https://api.nuget.org/v3/index.json as below:
Nothing worked for me, so I need a bit of help to find the way.
Maybe I need something for the "Search()" to work? I'm lost.
If you need more info I can provide, just ask, please.
First, since you can get the nuget package and view the package on your local website according to this document, I'm sure you have no problem with the steps to create your own nuget server.
The main reason is that you use the wrong link such as the view package in the Package Source. Instead, you should use the Repository URLs which is specified. The error is just it cannot
Repository URLs
In the package manager settings, add the following URL to the list of Package Sources:https://xxxxxxxxx/NugetServer/nuget.
Adding packages
To add packages to the feed put package files (.nupkg files) in the folder D:\xxxxx\xxxx\NugetServer\Packages
So please refer to the related info in your PC.
Update 1
Sloution
1) put the nuget packages into your local path like D:\xxxxx\xxxx\NugetServer\Packages so that you can access the packages through your links.(do not create any other new folders and put packages into them)
2) change the package source to http://xxxxxx/NugetServer/nuget as Repository URLs in your PC saids.
Update 2
In addition, please do not forget to run the instance of the NugetServer project at the same time and when the first screenshot that you provided shows, you should follow the guidance of it.
Hope it could help you.
Sorry - still scratching my head when it comes to NuGet. So I generated a bunch of packages and put them all on a network share. Things worked for a while, but then I started noticing that the versions that showed up in the NuGet Package Manager console didn't match what was on disk. (The version numbers didn't match what was on disk nor did the ID and description). Then I realized that there were additional .dlls needed in my package so I regenerated a new package with all of the necessary .dlls. In my testing I had been using versions 2.2, 2.4, 2.5 and 2.7, so I decided to start from scratch and created the new package as 2.0 with the title being "All Library Files". So I created a new .nuspec file in a new folder and packed it and then cleared out my network share that had all of the prior versions and then published it to the network share using nuget init. So I can go to the network share and all that's there is is a single folder with the name of my package and under that there are two folders: 2.0 and 2.1 (I created 2.1 later), but now when I open NuGet Package Manager at either the solution or the project level nothing shows up. I used Uninstall-Package to get rid of the initial ones and now whether I go to Installed Packages or Updates (or Online for that matter) I don't see anything. I expected to see the two new versions that I put in the folder. I've tried clearing the cache (both from the UI and the command line: nuget locals all -clear).
What could I possibly be doing wrong?
UPDATE 8/11/17 2:19pm:
I created a new folder on a local machine and copied all of my packages there and then added a new reference to it in the NuGet Package Manager and suddenly I can see all of my new packages. So somewhere it's gotta be caching that info. But now when I try to add one of my packages I get the error: Item has already been added. Key in dictionary: 'lib/net40/ Library.dll. I've used file explorer to search all files on disk for the string "lib/net40" and nothing is found. AAAUUUUGGGHHHH!!!!
I've now resorted to deleting and re-getting the entire code-base (all 91,717 files) :-(.
On some host, when using nuget.exe restore solution.sln
to force package restoration before build, I observe that command does not behave in identicall way compare to Nuget visual plugin.
On some host the command version append the build number (default value 0) to the version number,
causing the path in package folder to contain that build number.
So for example instead of having:
/packages/my_package.1.57.0/...
I have instead :
/packages/my_package.1.57.0.0/...
In the end it cause the build to fail, because internally,
target that are stored inside the .vcxproj are looking for the first path that do not contain the build number.
I don't know if it's relevant to the observered behavior, but those package are native C++ package build using CoApp
If instead of using nuget.exe on the same host, I am using the package manager restore functionnality from visual 2013, it works wells, and package are properly copied with path that don't include the build number.
And then build is ok.
As nuget.exe work on some host and not on some other, I am suspecting either a different version of a component or a different default setting.
For the component I have checked:
nuget version: 2.8.50926.602
visual 2013 version: 12.0.31101.00 Update 4
And they are identical on both host that work and that don't.
So what's left ?
Finally it end up to the following simple scenario (unfortunately I cannot reproduce the issue):
package in trouble where homemade package of boost library.
some of these package may have been available with the same name, but
different content and version numbering on nuget.org
On a workstation having the issue I was able to solve it by:
disabling nuget.org from the list of repos
and most importantly => CLEARING the nuget cache !
Even if I was not able to reproduce : I am quite confident about this scenario, because when looking inside the package I saw that the content was different from the one I had built. So this package have been downloaded from elsewhere.
How can Update be enabled even though the version number has not changed?
I'm developing a Nuget package. We're in the early stages, beta/testing. We don't change the version until testing is complete but we want to pass on the changed package for testing purposes.
But the Package Manager does not see the change, allow Update, unless the version has changed, I can reinstall but I'd prefer the testers to be able to Update.
How can this be done while the version number stays the same?
Resurrecting this as we are in the same boat (converting a monolithic solution to a Nuget-ified microservices architecture). This method works, though its a bit tedious:
Go to NuGet options and click 'Clear All NuGet Cache(s)'
Do a Nuget package restore on the solution. If this ends up failing due to (e.g. Newtonsoft.json being 'in use by another process') close all instances of Visual Studio & end task on all instances of MSBuild.exe + VBCSCompiler.exe. Restart VS and it should work.
Note that removing and re-adding the package will not work as it will still use the old cached version.
I just faced the same problem and my search brought me to here.
Normally we are using the AssemblyInformationalVersion field to specify prerelease suffixes, e. g.:
0.9.5-beta00001
0.9.5-beta00002
...
When enabling prerelease versions in the NuGet package manager, these packages are offered as well. As long as the suffix expression "increases", the package manager treats subsequent prerelease versions as update. It's important therefore to start with a well-thought suffix, as e. g. the following will not work: beta9 > beta10 (beta9 is treated higher, as the fifth character is higher).
As soon as the suffix is removed, the package is treated as release and is offered as update to all prerelease packages of the same version.
But as life gambles with us, sometimes we identify a small bug or improvement in a just released library. It's always really annoying to increase the version number again for such a microchange, if the just released library even wasn't used anywhere, cause its release is minutes ago only.
For this case I tried the procedure outlined by Simon Storr, but it wasn't enough. I encountered the old version in the packages directory of our solution. After manually deleting it from there, it took the current package from somewhere.
I am not sure if it downloaded the current package at this step, or took it from a more global packages directory that is located in the parent directory of the solution.
Note that there are multiple packages directories!
The properties of the NuGet package in the Visual Studio references view of the project displayed the global packages directory only. But there was the new version already (checked this with ILSpy), while still the old version was copied to the bin directory.
When I try and apply a minor upgrade to my application, I launch the installer and (depending upon the combination of settings I try) I get either a:
repair/remove dialog
prompt for the install directory
I don't believe I should get either of these prompts. I'm mostly expecting the installer to automatically apply the upgrade and not prompt for anything. I think I'm doing everything correctly in the Visual Studio setup project:
upgraded the version from 1.0.0 to 1.1.0
left the product code the same
updated the package code
left the upgrade code the same
launch the installer with the parameters REINSTALLMODE=vomus REINSTALL=ALL
I've tried just about every combination of codes/flags and techniques, but cannot seem to get the update applied.
Any ideas of what else I can try?
To get it to work I:
upgraded the version from 1.0.0 to 1.1.0
left the product code the same (said No when prompted by Visual Studio)
updated the package code (Visual Studio did this automatically)
did not change the upgrade code
launch the installer with the parameters REINSTALLMODE=vomus REINSTALL=ALL
Just as I had indicated in my question, and it seems to be working. I can successfully apply an upgrade. However, when I run the installer I am still prompted with a repair/remove option. But, that's a different question I guess.
Just first things first: Are you sure you haven't re-used the package GUID in both MSI files, or at some point during deployment work and testing?
Try rebuilding both MSI files with new GUIDs to "de-couple" them from any existing cached versions and then try test installing again. Change both the package code and product code. Better yet: test these new versions on a clean virtual machine to ensure a proper test environment unaffected by past sins. Your developer system could have gremlins in its Windows installer database due to package guid clashes. If this is the case package installation becomes total XFiles - the strangest things can happen.
More details:
If the package GUID is the same for two MSI files, Windows Installer will treat them as the same file by definition - no matter what they contain. This can cause all kinds of strange problems that are hard to clean up and debug. Note that this can happen even if you just forgot to update it once since installation of an MSI will cause it to be cached on the system in the C:\Windows\Installer folder (this folder is hidden and protected). This cached copy will be re-used if an MSI file with the same GUID is launched (at least this was the case for earlier versions of Windows Installer - there could be fixes for this now).
If you are using Installshield you should enable the "always generate packaging GUID" feature to ensure this never happens. Package GUID should always change for every single build - there is no reason whatsoever to keep it hard coded. I believe WIX takes care of generating the package GUID automagically, unless you specifically override it.