Upgraded simple nuget web server to 1.7, fails to load due to Ninject error

Apr 24, 2012 at 6:55 AM

Hi,

  I just updated my nuget custom server to the latest of the various packages it has (nuget 1.7), and I'm getting the following error when I try to load the feed. Is there something I have missed? This is (was?) a pretty simple project build - just build the package and off I go...

The server encountered an error processing the request. The exception message is 'Method not found: 'Ninject.Syntax.IBindingWhenInNamedWithOrOnSyntax`1<!0> Ninject.Syntax.IBindingToSyntax`1.To()'.'. See server logs for more details. The exception stack trace is: 

Server stack trace: at NuGet.Server.Infrastructure.Bindings.Load()
 at Ninject.Modules.NinjectModule.OnLoad(IKernel kernel) in c:\Projects\Ninject\ninject\src\Ninject\Modules\NinjectModule.cs:line 85 at Ninject.KernelBase.Load(IEnumerable`1 m) in c:\Projects\Ninject\ninject\src\Ninject\KernelBase.cs:line 217
 at Ninject.KernelBase..ctor(IComponentContainer components, INinjectSettings settings, INinjectModule[] modules) in c:\Projects\Ninject\ninject\src\Ninject\KernelBase.cs:line 100
 at Ninject.KernelBase..ctor(INinjectModule[] modules) in c:\Projects\Ninject\ninject\src\Ninject\KernelBase.cs:line 57
 at NuGet.Server.Infrastructure.NinjectBootstrapper.<.cctor>b__0()
 at System.Lazy`1.CreateValue()
 Exception rethrown at [0]: at System.Lazy`1.get_Value() at NuGet.Server.DataServices.Packages.get_Repository()
 at NuGet.Server.DataServices.Packages.CreateDataSource()
 at System.Data.Services.DataService`1.CreateDataSourceInstance()
 at System.Data.Services.DataService`1.CreateProvider()
 at System.Data.Services.DataService`1.HandleRequest()
 at System.Data.Services.DataService`1.ProcessRequestForMessage(Stream messageBody)
 at SyncInvokeProcessRequestForMessage(Object , Object[] , Object[] )
 at System.ServiceModel.Dispatcher.SyncMethodInvoker.Invoke(Object instance, Object[] inputs, Object[]& outputs)
 at System.ServiceModel.Dispatcher.DispatchOperationRuntime.InvokeBegin(MessageRpc& rpc)
 at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage5(MessageRpc& rpc)
 at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage41(MessageRpc& rpc)
 at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage4(MessageRpc& rpc)
 at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage31(MessageRpc& rpc)
 at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage3(MessageRpc& rpc)
 at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage2(MessageRpc& rpc)
 at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage11(MessageRpc& rpc)
 at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage1(MessageRpc& rpc)
 at System.ServiceModel.Dispatcher.MessageRpc.Process(Boolean isOperationContextSet)
Apr 24, 2012 at 7:06 AM

Ok - so I removed all packages from my project, and then added in nuget.server..., built, and deployed. Now it crashes on just the top level directory (Not even the ../nuget package). Something, again, to do with Ninject:

[FileLoadException: Could not load file or assembly 'Ninject' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)]

[FileLoadException: Could not load file or assembly 'Ninject, Version=3.0.0.0, Culture=neutral, PublicKeyToken=c7192dc5380945e7' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)]
   System.Reflection.RuntimeAssembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks) +0
   System.Reflection.RuntimeAssembly.nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks) +39
   System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(AssemblyName assemblyRef, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection, Boolean suppressSecurityChecks) +132
   System.Reflection.RuntimeAssembly.InternalLoad(String assemblyString, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection) +144
   System.Reflection.Assembly.Load(String assemblyString) +28
   System.Web.Configuration.CompilationSection.LoadAssemblyHelper(String assemblyName, Boolean starDirective) +46

[ConfigurationErrorsException: Could not load file or assembly 'Ninject, Version=3.0.0.0, Culture=neutral, PublicKeyToken=c7192dc5380945e7' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)]
   System.Web.Configuration.CompilationSection.LoadAssemblyHelper(String assemblyName, Boolean starDirective) +618
   System.Web.Configuration.CompilationSection.LoadAllAssembliesFromAppDomainBinDirectory() +209
   System.Web.Configuration.CompilationSection.LoadAssembly(AssemblyInfo ai) +130
   System.Web.Compilation.BuildManager.GetReferencedAssemblies(CompilationSection compConfig) +178
   System.Web.Compilation.BuildManager.GetPreStartInitMethodsFromReferencedAssemblies() +94
   System.Web.Compilation.BuildManager.CallPreStartInitMethods() +332
   System.Web.Hosting.HostingEnvironment.Initialize(ApplicationManager appManager, IApplicationHost appHost, IConfigMapPathFactory configMapPathFactory, HostingEnvironmentParameters hostingParameters, PolicyLevel policyLevel, Exception appDomainCreationException) +677

[HttpException (0x80004005): Could not load file or assembly 'Ninject, Version=3.0.0.0, Culture=neutral, PublicKeyToken=c7192dc5380945e7' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)]
   System.Web.HttpRuntime.FirstRequestInit(HttpContext context) +9089964
   System.Web.HttpRuntime.EnsureFirstRequestInit(HttpContext context) +97
   System.Web.HttpRuntime.ProcessRequestNotificationPrivate(IIS7WorkerRequest wr, HttpContext context) +256

 


Apr 24, 2012 at 7:16 AM

Ok. When I installed Nuget.Server, it didn't bring all the packages as up to date. When I updated all the packages, I got back to the point where the root page worked again (I get the usual message about what http link is to put into the nuget VS web pages config, etc.). And when I add the "nuget" onto it, I get the bomb above.

Developer
Apr 24, 2012 at 5:10 PM

Could try updating NuGet.Server? I pushed a newer release to the gallery.

Apr 25, 2012 at 8:22 AM

Thanks! No longer crashing! :-)

Just out of curiosity - was the long-start up time (and race condition) fixed? I have about 60 packages in my list, a few of them are quit large. To extract the meta-data the server has to unzip them all - this can take longer than a client (like the nuget dialog in VS2010) is willing to wait. Thus sometimes you get multiple requests. This used to cause a race condition (and was reported). Do you know if that is now fixed? It would also be nice to know if there was any caching mechanism so once one of those large files was unpacked, it wouldn't have to be unpacked again, even if IIS spun down the app pool... :-)

Developer
Apr 25, 2012 at 5:30 PM

I'm pretty sure we haven't addressed the race condition as yet. NuGet does have an in-memory cache, however every time Asp.Net spins up a new AppDomain we end up having to recreate it. Plus the kind of queries that get invoked result us in having to crack open all the zips the first time around.

Ideally, if you have a large enough repo, you should switch to the gallery implementation (https://github.com/NuGet/NuGetGallery). Its not a package (as yet), but its certainly better optimized for serving a larger set of packages and gets more love from the NuGet team these days. 

Apr 25, 2012 at 8:51 PM

Thanks! I didn't realize that was something I could "install" myself. I'll take a look at it.

ANother thing I've noticed - I copied (by hand) all hte packages back into the Packages directory - however the server hasn't picked them up - despite my resetting the app a few times. Is there something I need to do to trigger a scan of that directory?

Developer
Apr 25, 2012 at 10:26 PM

Are the packages nested under sub-directories? There's a bug in our implementation of this but I don't think it should affect the listing on <site>/nuget.

Apr 25, 2012 at 11:07 PM
Edited Apr 25, 2012 at 11:08 PM

Nope - they are all at the top level. And they are the identical packages from 1.6 (all of them, actually, were built with 1.5 or 1.6 - none of them have been packaged with 1.7 - but I wouldn't have expected that to make a difference, right?)

Thanks for your continued help!

Developer
Apr 25, 2012 at 11:31 PM

What happens when you do "nuget.exe list -Source <path to packages dir>"? Trying to understand if there's a regression involved here

 

Apr 26, 2012 at 2:25 AM

Listed all the packages - it was actually quite fast too - faster than I was expecting it to be. Just dumped the packages one after the other:

PS C:\Users\gwatts\Desktop> .\NuGet.exe list -Source C:\inetpub\wwwroot\rootNuGet\Packages
LINQToTTree-v5.28.00.win32.vc10 0.41.0.4
LINQToTTree-v5.28.00.win32.vc10.debug 0.41.0.4
LINQToTTree-v5.28.00f.win32.vc10 0.41.0.4
LINQToTTree-v5.28.00f.win32.vc10.debug 0.41.0.4
LINQToTTree-v5.30.01.win32.vc10 0.41.0.4
LINQToTTree-v5.30.01.win32.vc10.debug 0.41.0.4
ROOTNET-All-v5.28.00.win32.vc10 2.2
ROOTNET-All-v5.28.00.win32.vc10.debug 2.2
ROOTNET-All-v5.28.00f.win32.vc10 2.2
ROOTNET-All-v5.28.00f.win32.vc10.debug 2.2
ROOTNET-All-v5.30.01.win32.vc10 2.2
ROOTNET-All-v5.30.01.win32.vc10.debug 2.2
ROOTNET-Core-v5.28.00.win32.vc10 2.2
ROOTNET-Core-v5.28.00.win32.vc10.debug 2.2
ROOTNET-Core-v5.28.00f.win32.vc10 2.2
ROOTNET-Core-v5.28.00f.win32.vc10.debug 2.2
ROOTNET-Core-v5.30.01.win32.vc10 2.2
ROOTNET-Core-v5.30.01.win32.vc10.debug 2.2
ROOTNET-Graphing-v5.28.00.win32.vc10 2.2
ROOTNET-Graphing-v5.28.00.win32.vc10.debug 2.2
ROOTNET-Graphing-v5.28.00f.win32.vc10 2.2
ROOTNET-Graphing-v5.28.00f.win32.vc10.debug 2.2
ROOTNET-Graphing-v5.30.01.win32.vc10 2.2
ROOTNET-Graphing-v5.30.01.win32.vc10.debug 2.2
ROOTNET-PROOF-v5.28.00.win32.vc10 2.2
ROOTNET-PROOF-v5.28.00.win32.vc10.debug 2.2
ROOTNET-PROOF-v5.28.00f.win32.vc10 2.2
ROOTNET-PROOF-v5.28.00f.win32.vc10.debug 2.2
ROOTNET-PROOF-v5.30.01.win32.vc10 2.2
ROOTNET-PROOF-v5.30.01.win32.vc10.debug 2.2
ROOTNET-Tree-v5.28.00.win32.vc10 2.2
ROOTNET-Tree-v5.28.00.win32.vc10.debug 2.2
ROOTNET-Tree-v5.28.00f.win32.vc10 2.2
ROOTNET-Tree-v5.28.00f.win32.vc10.debug 2.2
ROOTNET-Tree-v5.30.01.win32.vc10 2.2
ROOTNET-Tree-v5.30.01.win32.vc10.debug 2.2
Apr 26, 2012 at 2:26 AM
Edited Apr 26, 2012 at 2:37 AM

This got me to looking a little more carefully - it looks like in the web.config file the "packagesPath" setting is empty... should it be the relative path in there? Ok, according to the docs, it should default to "~/Packages", if that is the Packages directory off the web service root, then that should have been working.

I tried a custom folder as well - and that doesn't seem to have worked any better either.

Apr 27, 2012 at 6:58 AM

Ok. This is now working. Part of the problem, it turns out, is that when you look at the feed directly you don't see any packages there. I seem to remember being able to look at a list of packages w/out having to specify any search parameters. For example, if you point your web browser at:

  http://deeptalk.phys.washington.edu/rootNuGet/nuget/

you'll see nothing. I seem to remember the list of packages being there. When I point VS at it, it responds (though after a very long start-up time).

Thanks for your help - sorry to get confused in my debugging. BTW, it looks like the more robust version of the server is more than I need. I think I have 2-3 users, and this thing gets hit once or twice a week (if that some weeks!). I use it partly to move and distribute my own analysis libraries to myself. It sits in a small VM, and is "free" - which is good because the NSF keeps cutting our budgets. It looks like the proper gallery requires DB and other access - so isn't quite as turn-key as this one is.

Developer
Apr 27, 2012 at 4:13 PM

We'd been meaning to add some sort of indexing to folder based repositories but we inevitably end up ignoring it each release.

If hosting packages outside of your university network is permitted, you could certainly have a look at a myget (http://myget.org) feed. It would be less maintenance for you to deal. Glad we could help though :)

May 3, 2012 at 9:21 PM

I'm actually working on a branch of Nuget.Server that uses a Lucene.Net index to speed up search and list operations and keeps a more durable index of calculated metadata like PackageHash. It also keeps proper track of DownloadCount, VersionDownloadCount and IsLatestVersion (although I'm still foggy on what IsAbsoluteLatestVersion is supposed to mean).

My changes are basically ready but I need to run the code through our legal team before releasing it as open source. I'll update here when it becomes available.

Aug 6, 2012 at 7:24 AM
Hi,
I just wanted to say that I did a lot of work on how my libraries were built and managed to shrink there size by about 60%. The result is they now fit on the NuGet server. I plan to now abuse that thing until they tell me I’ve put up too many copies! :-)
Cheers, Gordon.
From: chriseldredge
Sent: Thursday, May 3, 2012 5:22:00 PM
To: gordon@gordonandpaula.net
Subject: Re: Upgraded simple nuget web server to 1.7, fails to load due to Ninject error [nuget:353324]

From: chriseldredge

I'm actually working on a branch of Nuget.Server that uses a Lucene.Net index to speed up search and list operations and keeps a more durable index of calculated metadata like PackageHash. It also keeps proper track of DownloadCount, VersionDownloadCount and IsLatestVersion (although I'm still foggy on what IsAbsoluteLatestVersion is supposed to mean).

My changes are basically ready but I need to run the code through our legal team before releasing it as open source. I'll update here when it becomes available.