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) :-(.
Related
I had a NET45 project published to NuGet. For internal reasons (this is not a production application), I REQUIRE it to be Version 1.0.1 always no matter what. I am using my own private NuGet Server that is currently fully up to date, and TeamCity as my Build Server.
-See TeamCity edit/addition at the bottom-
So after 4 years, I had to make a slight update to this NuGet Package. I did so and Re-Published it as 1.0.1. I do indeed have allowOverrideExistingPackageOnPush set to true, and I am fairly confident the code was overwritten.
Apart from the one tiny code change, I also changed the project to .NET 4.7.2, as well as updating the nuspec From This, To This...
<!-- From this -->
<file src="bin\Release\....dll" target="lib\net45\....dll" />
<!-- To this -->
<file src="bin\Release\....dll" target="lib\net472\....dll" />
When I check on my Server, my nupkg looks like this:
Previously it said net45, but now it says net472. Success?
However, my consuming application (Also not a production app), it its Packages/ folder, Only Includes a ...1.0.1/lib/net45 folder.
I tried every way I could think to wipe, restart, clear-cache, and otherwise obliterate that 1.0.1 package from everything. But still, when I push it, it always ends up with ONLY a net45 folder.
Finally to ease my madness, I allowed my very first ever push of 1.0.2 and, MUCH to my surprise, there was a net472 folder. It was perfect.
So how do I TRULY delete package 1.0.1 and/or alter any lingering records so it isn't stuck as net45?
In TeamCity there is a "Caches" page in the Diagnostics menu. I searched around for the definitions and reasons to Reset some of those caches, but nothing jumped out at me related to this. Also, it says not to touch it unless a TeamCity team member tells you to. Not sure if this is related, but if so, somebody with that expertise would be appreciated.
This was indeed a Caching issue for me. But the cache was a local cache, specifically through Visual Studio, but could also be the NuGet local cache. Though the entire infrastructure was correct, my local machine kept giving me the old version.
In VS, Tools > NuGet Package Manager > Settings > Clear All NuGet Caches.
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.
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.
I'm using Visual Studio 2010 for two applications, installing to IIS 7.5 on another server. Project A is a web forms web application, and Project B is an MVC 4 web application. During an attempt to set up StateServer between the two applications, I had added a reference to each's .dll in the other's References list. StateServer was abandoned in favor of using a cookie, and the project .dlls were deleted (I did not notice until the installation process that Project B's references were probably also in the list. VS seems to have deleted them from the References when the Project B.dll was deleted, since I did not delete those refs manually).
The problem is, the deployment package is still including them. (I'm just troubleshooting Project A, at the moment.) They are no longer listed in the project's References list, they do not appear in the folder contents under the obj/Release/Package folder, but they DO appear in the installed location after using Deploy -> Import Application in IIS! This includes Project B.dll, as well as many of it's references, such as DotNetOpenAuth.OAuth.dll.
I've run a search through my entire solution on Project A, and have no references to the Project B.dll. I've tried setting up a brand new site in IIS, and deploying to that. I've tried deploying under Staging (QA) and Release configurations, to make sure it wasn't just one of them that was messed up. Under Package/Publish Web, the settings you may be interested in are "Only files needed to run this application", and "Create deployment package as a zip file".
Running the site gives the error, "Could not load file or assembly 'System.Web.WebPages.Razor, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies". This dll is not in the References list of the project, nor the deployment Package folder, nor the installed location's bin folder. It runs with no error, locally.
If I simply remove the extra .dlls manually out of the installed location, I get a compilation error when running the site, complaining a variable is not declared: var lotid = <%=defaultLotID %>; However, this variable is very much declared in the code behind: Public Shared defaultLotID As Integer = 0. And like I said, it runs fine locally. So it seems like a bogus error; just a canary in the mine, maybe.
Seriously, what am I missing? I had no idea how hosed I would be after making a reference to another type of web application. Thank you to whoever takes on the challenge of troubleshooting this one! I'm two days in and coworkers are baffled.
I ended up undoing all my changes, putting my code back to the TFS last check in version. I reintroduced the just the cookie code, built and deployed, I no longer saw the other project's dlls in the installation location. I guess it wasn't going to work to move forward through the reference and subsequent backout. Had to rollback to the prior TFS version, and start over.
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.