My Web2 solution is failing to compile because some of the packages were hosted in a different directory structure to the rest of the solution, and I deleted this structure and the corresponding "packages" folder.
I used Update-Package -reinstall
Hoping that this would fix it... however it still kicks out this error message on build:
This project references NuGet package(s) that are missing on this computer. Use NuGet Package Restore to download them. For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is ..\packages\Microsoft.Net.Compilers.1.0.0\build\Microsoft.Net.Compilers.props
Now as far as I can tell all the references should be OK, packages.config says:
<package id="Microsoft.Net.Compilers" version="1.0.0" targetFramework="net45" developmentDependency="true" />
And the directory structure exists
--Solution Dir
|-- packages
|--Microsoft.Net.Compilers.1.0.0
I tried updating the package and got version 1.3.2, but the error message remained the same, ie version 1.0.0 was missing.
Theres' clearly some reference to this floating around somewhere - but I don't know where to start looking. I'm assuming the ..\packages in the path indicates its looking for the package in the external directory location (as one up was where the original packages were)
Any ideas?
UPDATE:
I copied the packages folder back to its original location outside the solution directory and .... the issue isn't resolved. So maybe that was never the issue in the first place.
However the error message is still reporting a missing NuGet package that to all appearances is actually there.
This StackOverflow answer got me started on the right track, once I Googled the error message without the ..\ in front of the package location
https://stackoverflow.com/a/32296184/1286358
Then I had to go through and add serveral missing references - presumably because in my hacking attempts to fix the issue I had removed them then not re-referenced them.
Related
I have build a nuget package at published it to a nuget.server site. But when I try to use the package form the server the .targets file from build folder is not in the file. But if I use the package from a local folder it works as it should. How do I get it to work ?
If i look in the package in the folder on the server it looks ok.
It's not clear to me if you mean using (referencing and restoring) a package, or building (packing) a package.
If the problem is with packing the nupkg, NuGet requires the props and targets files to have specific filenames in specific folders, but if you got it to work at least once, you probably already know that. If this is not the problem with packing, you need to give us more information because not using the correct filename convention is the most common problem and I can't guess what else the problem could be. In particular, if the package is being packed differently on your local machine compared to when it is packed on the server, it means there is something different between how you pack on the two computers, so we need more information about how the build and pack work with your project.
If the problem is with using (restoring) the package, there are a few possibilities. My best guess is that you once had a package without the targets file working correctly, and you restored the package on the server. By design, NuGet packages are immutable which means it's invalid for the contents of a package (same ID and version) to change. This allows NuGet to download the package from a remote feed once, save it in the global package folder (not a cache; they never expire) and the next time NuGet needs to restore the same package (id + version) it uses the one in the global package folder, it does not download again. This means if you once built a bad nupkg and restored it on a machine, then fix the nupkg and kept the same version number, that machine will never get the fixed nupkg. You need to delete it from the global packages folder. I'm not 100% sure, but I think if you have a local file feed and you restore a project that uses packages.config, the nupkg does not get saved in the global packages folder, so doesn't have the same problem. In short, I think the problem is that you changed the nupkg contents once without changing the version number, and one of the machines has the old copy in its global packages folder that it keeps using.
If that's not the problem, the next most likely cause is that the nupkg on the server feed has different contents to the nupkg in the local feed. I've never used NuGet.Server, but some nuget respositories (like nuget.org) do not allow overwriting nupkgs. So, if you pushed a nupkg to your server, fixed a problem in your nupkg without changing the version, then tried to push again, the second push might have failed.
In summary, your question doesn't provide enough information for us to help you, but I wrote about the most common issues above. If it doesn't help, you need to provide us with more information. An example of the problem is the best way to give us enough information to help you.
I have a .NET Core 2 application and I'm trying to reference a NuGet package which contains static files and have them copied to my application similarly to how the "content" directory worked in the past.
According to the following https://blog.nuget.org/20160126/nuget-contentFiles-demystified.html this looks to be supported under a "contentFiles" directory.
I've found the following package which looks to support the new schema:
https://www.nuget.org/packages/ContentFilesExample/
And added a reference to it by adding the following to my .csproj file:
<PackageReference Include="ContentFilesExample" Version="1.0.2" />
Now when I run dotnet restore it doesn't copy anything to my application. I've been searching through the GitHub issues but it's hard to follow what is outdated and what is supported.
I'd appreciate it if someone could let me know if this is supported and what I could possibly be doing wrong. If it's not supported please could you point me in the direction of the correct GitHub issue to follow. Thanks
With PackageReference, the files are never copied over to the project. Rather the content files live in the global packages folder as immutable entities. You can still refer to these files as if these were expanded in your project.
If you use Visual Studio 2017, you can see these as refs as shown below. You can refer to .csproj.nuget.g.props file in the obj directory to find out the details of the files refs/links.
Have you looked at NuGet pkg Microsoft.AspNetCore.StaticFiles (2.0.0) ?
Okay this is a derivative of Could not load file or assembly 'NuGet.Server, Version=2.11.1.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies seeing as though I couldn't find a solution to that.
I am publishing my Nuget Server project to my Windows 2012 R2 server and pointing to the applicable directory where the files live. The package files exist, as shown below in the screenshot however I keep on getting the below error:
Severity Code Description Project File Line Suppression State
Error Copying file Packages\PackageName.1.0.0.nupkg to obj\Release\Package\PackageTmp\Packages\PackageNameJson.1.0.0.nupkg failed. Could not find file 'Packages\PackageName.1.0.0.nupkg'. nuget_server_02 0
I have NuGet Server v2.11.3 installed and my project targets .NET Framework 4.6. One thing to note is that the packages themselves are from an earlier version of .NET - most likely 3.5.
This is my web.config file:
<add key="packagesPath" value="D:\RootFolder\SubFolder\SolutionNameFolder\ProjectNameFolder\Packages"/>
Even after several Restore NuGet Packages attempts I am still faced with this dilemma. The one thing I am really struggling to understand is if I point the packagesPath to a local directory, it works and does retrieve the packages however, when I point to the very same project on my server I get this headache.
Previously, in the included link to the related SO question, I could publish but now I can't even get through that stage even though I never made any changes to the project since last working on it. I decided to revisit it today.
UPDATE:
I have deleted the bin folder and rebuilt my solution as per Could not load file or assembly 'someProject' or one of its dependencies. Access is denied But it still can't find the file.
You can run your nuget server and it will show an html file as output (Default.aspx). You can, of course, modify this file to make it look like anything you want and otherwise change it. You can't change the way the nuget server service behaves because that is run from a dll. You should be able to show your repository files using the output page of your nuget server.
I encountered a similar set of errors, and monitored the Event Viewer while I was trying to show the contents of my repository.
The Event Viewer showed that an error was being thrown every time my Nuget Server attempted to list the contents of the packages folder.
Keeping in mind that nuget packages are zip files, and to display the details on the information contained in the nuget packages, the nuget server must unzip them. If the file is corrupted, the server will throw an error and stop attempting to list the contents of any further files. This error results in a w3wp.exe crash. It will be recorded as an ASP.NET error in the Windows->Applications section of the event log.
The cure for me was to delete the contents of the packages folder on my nuget server, and re-up them.
This may be impractical if you have a lot of files in your repository, so any files that were uploaded near the first error shown in the event viewer should be chosen for upload first.
One of the files is likely corrupted.
I would recommend checking out the event viewer on your server, and making sure you have no corrupted files in your repository.
You can view (and edit, to a point) your repository contents with Nuget Package Explorer. If the file you want to view is corrupted, then it should show an error for that file. You can then re-up that file, and if the problem is a file problem, this will cure it.
You can also reinstall your nuget server if that fails. It is somewhat unlikely that the code has been corrupted, but worth a shot.
Good luck.
So I've tried everything that was advised such has updating Nuget, ticking nuget.org in Nuget Packege manager and I still get the error of:
Does anybody know what to do ? Thanks.
It looks like your project path is long enough that when the package is restore, restore the package folder fails because it reached the qualified name length limit. See the NuGet issue for this.
Could you try to move you project to root drive?
Move your project to a shorter path location (a root drive will be much better; Example: D:\) and have a try.
I had a package repository (cache) set to some place on disk, centrally, using the repositoryPath NuGet.config setting.
Then I changed my mind about using that, since the path gets added to the HintPath in the proj file uses a relative path that won't work on colleagues' machines.
Trouble is, now the HintPaths need fixing to ..\packages\etc so I thought I'd just run Update-Package Whatever -Reinstall with the package source in the Package Manage Console set to our TeamCity feed.
That reinstalls them all, sure, but the HintPaths didn't get updated!
Why not?
It did.
I just hadn't saved all! So the diff tool didn't see any changes.