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.
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've been trying to install Enterprise Library 6, and it's been a pain. I tried following Enterprise Library 6: Installation and VS2012 Configuration, but I'm having issues with the powershell command. I also tried opening install-packages.ps1 and pasting in powershell, and I keep continue errors. I'm not sure if it's my machine and the restrictions it has, but I don't want to go through this installation process just for one call to a stored procedure.
I rarely use powershell, and I don't want to start learning it today. Is there a way to just download the dlls needed and add them as reference to my project?
I had already added Microsoft.Practices.EnterpriseLibrary.Data as reference, and the project builds well, but when it runs, I get an error with one of the methods. It seems that there are other dlls I need to add (Microsoft.Practices.EnterpriseLibrary.Common), among others.
I just want to download these dlls and add them as reference. I don't want to go through any installation process.
Is this possible? Thanks.
I downloaded Microsoft.Practices.EnterpriseLibrary.ConfigConsoleV6.vsix. Then I opened in winrar, copy/pasted Microsoft.Practices.EnterpriseLibrary.Common.dll to my bin folder, and added as reference to my project.
Then I downloaded enterpriselibrary.data.6.0.1304.nupkg from nuget.org and opened it with winrar. Then I copy/pasted Microsoft.Practices.EnterpriseLibrary.Data.dll to my bin folder, and added as reference to my project.
I've created a library on myget (part of ci), and I'm trying to push the symbol sources to symbolsource.org (this is a great service, and I love the idea). This is my first attempt. I've been using the instructions found on the myget site: http://docs.myget.org/docs/reference/symbolsource, but there are some gaps.
Here are the steps I go through. First, I create a nuspec file, and I use "nuget pack -symbol xxx" to create the X.symbols.nupkg and X.nupkg files. This works just fine. I then push them individually to myget and symbolsource. I used the nuget pkg explorer to examine the contents, and they look as I would expect (the src, pdb, and dll show up in the symbols). After doing the push, I can log into symbolsource and I see my packages up there using the instructions found on the myget page.
I used the following command to push to symbolsource:
nuget push X.symbols.nupkg $ApiKey -Source http://nuget.gw.SymbolSource.org/MyGet/rootdotnet/
I then configure visual studio as instructed: make sure to turn off "enable just my code" and also to turn on symbol servers. I then add to the list of symbol servers the following URL:
http://srv.SymbolSource.org/pdb/MyGet/gwatts/XXXXX
Where XXXX is a GUID I read off the sumbolsource "Your Account"/"Authentication" "Visual Studio" table entry (myget wasn't at all clear this is what I was supposed to do).
I then try to debug. When I hit something in that library, I get the "No Symbols Loaded" page in VS2012. Under details, there is a dump VS2012's attempt to find the pdb file. I see the following:
C:\Users\Gordon\Documents\Code\HVQCDCorrelationStudy\CalcSimpleCorrelationTestNumbers\bin\x86\Debug\LINQToTTreeLib.pdb: Cannot find or open the PDB file.
c:\TeamCity\buildAgent\work\44463130cd7383cb\LINQToTTree\LINQToTTreeLib\obj\x86\Release\LINQToTTreeLib.pdb: Cannot find or open the PDB file.
C:\WINDOWS\LINQToTTreeLib.pdb: Cannot find or open the PDB file.
C:\WINDOWS\symbols\dll\LINQToTTreeLib.pdb: Cannot find or open the PDB file.
C:\WINDOWS\dll\LINQToTTreeLib.pdb: Cannot find or open the PDB file.
C:\Users\Gordon\AppData\Local\Temp\SymbolCache\LINQToTTreeLib.pdb\9c883e0fa93245c99efd2b92dbfc6dfc1\LINQToTTreeLib.pdb: Cannot find or open the PDB file.
C:\Users\Gordon\AppData\Local\Temp\SymbolCache\MicrosoftPublicSymbols\LINQToTTreeLib.pdb\9c883e0fa93245c99efd2b92dbfc6dfc1\LINQToTTreeLib.pdb: Cannot find or open the PDB file.
C:\Users\Gordon\Documents\Code\HVQCDCorrelationStudy\LINQToTTreeLib.pdb: Cannot find or open the PDB file.
SYMSRV: C:\Users\Gordon\AppData\Local\Temp\SymbolCache\LINQToTTreeLib.pdb\9C883E0FA93245C99EFD2B92DBFC6DFC1\LINQToTTreeLib.pdb not found
SYMSRV: http://srv.SymbolSource.org/pdb/MyGet/gwatts/XXXXX/LINQToTTreeLib.pdb/9C883E0FA93245C99EFD2B92DBFC6DFC1/LINQToTTreeLib.pdb not found
http://srv.SymbolSource.org/pdb/MyGet/gwatts/XXXXX: Symbols not found on symbol server.
SYMSRV: C:\Users\Gordon\AppData\Local\Temp\SymbolCache\LINQToTTreeLib.pdb\9C883E0FA93245C99EFD2B92DBFC6DFC1\LINQToTTreeLib.pdb not found
SYMSRV: http://msdl.microsoft.com/download/symbols/LINQToTTreeLib.pdb/9C883E0FA93245C99EFD2B92DBFC6DFC1/LINQToTTreeLib.pdb not found
http://msdl.microsoft.com/download/symbols: Symbols not found on symbol server.
In short, it looks like it correctly contacts symbolssource.org. But something is failing up there. The 9C883E0FA93245C99EFD2B92DBFC6DFC1 is obviously a hash. I have no idea (??) what hash symbolssource assigned to that library - though I'd love to try to figure it out, as that might be a first step to understanding what is going on.
Basically. I don't know how to proceed with debugging at this point. Any help would be appreciated!
Update: As mentioned in the answers below, build something small that can be tested. I've done that, and it works just fine. In doing that I discovered there are some debugging tools up on SymbolSource.org - specifically, when you look at a package in your feed, you can find the "Compilations" link. Click on it. It should show a line for each build type you've uploaded. My packages have nothing associated with that - so I've messed up my nuspec file somehow for symbol generation.
Try to isolate a reproducible scenario (rule out as many other factors as you can). Sounds like your Visual Studio set up is correct, so I'm suspicious for package or compilation issues (e.g. symbols and sources out of sync). Feel free to contact MyGet support for further assistance.
The answer, it turns out, is a slice of humble pie. Turns out on my build server there was an environment variable conflict. The result was that local build scripts built a symbols file just fine and the build server built one without PDB's in it. Without pdb's, of course, the source server was not able do very much.
One thing I did learn on the way is the NuGet PackageExplorer (https://npe.codeplex.com/). Want you can do is use it to load up the nugget symbols package. Then use the plug-in manager to load in the SymbolesSource plug-in (you'll have to use the market place, but it is all free). This utility would have caught the problem in my packages had I submitted the proper ones to it (my local packages passed with flying colors).
I updated an installer file (.ism) for major upgrade in which I made the following changes:
updated product code,
updated package code,
updated versionmin and max in upgrade,
updated product version,
few strings in which old version was mentioned.
Now when I am upgrading my product using this setup, few files get removed automatically.
I did not make any changes in those files in target machine and the same files (no change in content) are in my new setup.
Also I did not add any entry in "RemoveFiles" table to remove them.
Also checked the installation log in which I am just seeing this:
Action 14:14:59: RemoveFiles. Removing files
RemoveFiles: File: CapibilityDemo.htm, Directory: C:\Program Files\Server\Printing\
RemoveFiles: File: HTTP.js, Directory: C:\Program Files\Server\Scripts\OpenLayers\lib\OpenLayers\Protocol\
RemoveFiles: File: Script.js, Directory: C:\Program
Files\Server\Scripts\OpenLayers\lib\OpenLayers\Protocol\
Can anyone please help me in resolving this issue ?
Thanks
Taran
Dynamic components are probably the problem.
This link is someone who was having a similar problem while patching (which is like a minor update)
Basically what is happening is that MSI has determined that the 'old' components have been removed (since they are dynamically generated, the GUIDs change every build). So in your upgrade it is removing the components you 'removed'. However it isn't laying down the new components, likely because it has determined there isn't a need for it to do so. You should examine your MSI file in Orca and look for the files/components that didn't get installed in your upgrade, and then search the install log for that GUID. That should give you a clue as to the next steps.
Also, here is the installshield best practice recommendations for Dynamic file linking.
I'm new to NuGet -- just started using it and got myself a copy of WatiN.
I'm trying to trim down the size of the folder that was pulled back before I put it into version control. I noticed that WatiN.2.0.50.nupkg is about 12mb. I noticed from this link that the .nupkg is essentially a compressed version of the package contents. Is it OK to delete it, or might doing so cause any issues in the future?
If you delete it we can't update/uninstall since we use that file as a record of what is currently installed. We're looking at a feature that would allow people to restore the packages from packages.config so you could avoid putting packages in source control altogether. More info here http://nuget.codeplex.com/workitem/165