Ninject Kernel being disposed on startup after updating Microsoft.AspNet.Identity.Owin 2.2.0 - ninject

I am working on a WebApplication which uses MVC5 and WebApi 2 with Owin. I recently updated Microsoft Asp.Net NuGet packages (Microsoft.AspNet.Mvc, etc.) from version 5.2.2 to 5.2.3, and the Owin NuGet packages (Microsoft.Owin, etc.) from 3.0.0 to 3.0.1. I also updated Microsoft.AspNet.Identity.Owin from version 2.1.0 to version 2.2.0
I then updated the corresponding Ninject WebApi packages (Ninject.Web.WebApi, etc.) from 3.2.3 to version 3.2.4 in order to get it to compile, but did not update Ninject.Web.Common.OwinHost, since this was at the latest version (3.2.3).
When I try to run the application, I get the following error:
Error loading Ninject component ICache
No such component has been registered in the kernel's component container.
Suggestions:
1) If you have created a custom subclass for KernelBase, ensure that you have properly implemented the AddComponents() method.
2) Ensure that you have not removed the component from the container via a call to RemoveAll().
3) Ensure you have not accidentally created more than one kernel.
The Kernel that I am creating in the OwinStartup class using is being disposed from the Owin.AppBuilderExtensions.CreateOwinContext() method, which is indirectly from OwinBootstrapper.Execute().
This has only started happening since updating the Asp.Net NuGet packages to 5.2.3. Before updating the packages, OwinBootstrapper.Execute() is still called, but does not cause Owin.AppBuilderExtensions.CreateOwinContext() or KernelBase.Dispose() to be called.
I have not changed any of the code in OwinStartup, and my Ninject Kernel is still being created using:
public virtual void Configuration(IAppBuilder app)
{
app.UseNinjectMiddleware(CreateKernel);
app.CreatePerOwinContext(CreateKernel);
}
I have tried updating the NuGet packages one at a time, and the specific update that causes the issue is Microsoft.AspNet.Identity.Owin to 2.2.0 Are there any known compatibility issues with Ninject and AspNet.Identity.Owin 2.2.0?

This from Hao: I think that should be fine, so long as ninject takes care of disposing the per request objects somehow

By looking at the previous source code and current source code, it looks like they are expecting a IDisposable object and calls it immediately at the end of its life cycle (aka request).
I also noticed that other CreatePerOwinContext they provide when installing OWIN such as app.CreatePerOwinContext(ApplicationDbContext.Create); was never disposed (in 2.1.0)? This seems like a big memory leak as they instantiate some classes every time there is a request.
To go around the problem when using CreatePerOwinContext with Ninject StandardKernel, I tried with the following code:
app.CreatePerOwinContext(
(Microsoft.AspNet.Identity.Owin.IdentityFactoryOptions<IKernel> options, IOwinContext context) => kernel,
(Microsoft.AspNet.Identity.Owin.IdentityFactoryOptions<IKernel> options, IKernel instance) => {}
);
Basically, I do nothing in the dispose callback.
I do not know if this will lead to some memory leak but it definitely makes the app work again.

Related

getClassPath() method in the WebLogic context class loader does not consider package preferences in weblogic.xml

A related problem: Get the class path from the context class loader (of WebLogic for instance)
This is already solved in How to set up the context class loader's classpath for runtime compilation?.
Current problem: Get the same (proper) class path used to run a web app
Reflectively calling the "getClassPath()" method works but it returns a dirty classpath containing unanted modules from $ORACLE_HOME/oracle_common/modules directory.
Problematic scenario:
Deploy a web app "Parent" in WebLogic // <- works
Get the context class path (it's a String object) by reflexively calling "getClassPath()" // <- works
Fork a process out of the main "Parent" process and run it using the context class path // <- fails
04:36:45,238 [Thread-41] ERROR ChildProcess - Exception in thread "main" java.lang.NoSuchMethodError: com.fasterxml.jackson.databind.ObjectMapp
er.configOverride(Ljava/lang/Class;)Lcom/fasterxml/jackson/databind/cfg/MutableConfigOverride;
Explanation
While the context class path contains the necessary dependencies for the child process to run, they are overshadowed by WebLogic's own dependencies. The result is runtime failures such as the one shown above.
Workaround
a) Use a new version of WebLogic server that hopefully would use newer versions of the artifacts needed by the child process // risky endeavour
b) Manually process the context class path and remove any artifact that would shadow their more-recent counterparts
Solution b) looks more practical, but I don't like it for meany reasons:
The reflexive call to "getClassPath" returns a String, and looking for artifact's names in Strings feels frail and weak
I wouldn't know what shadows what. WebLogic prepends its weird artifacts at the start of the string before listing the web app's own dependencies.
Only weblogic.xml has info on the web app's package preferences. I wish I could mimic how WebLogic processes this file to run the web app (Parent) and use that to properly run the child process
It seems to me that forking a process out from a web app running in WebLogic does not enjoy the same package preferences expressed in "weblogic.xml" that the web app (Parent) enjoyed when it was deployed and started running.
Other than the above suggestions, I am welcoming of any stronger solutions

GlobalConfiguration.Configuration.UseNinjectActivator does not exist with Hangfire.Ninject

I have been using Ninject and Hangfire for a while and just added the Ninject.Hangfire package. However the following extension method just doesn't seem to be loading despite having updated both all 3 of these packages.
Restarting Visual Studio triggered it to work.
I think it could be because Hangfire and Hangfire.Ninject both use the Hangfire namespace (which is where UseNinjectActivator is defined).
So something just isn't refreshing.

Ember.js testing component with service dependency

I'm trying to write tests for my addon, but encountering some weird behaviour.
I have created a service (via ember-cli generate), which is used inside a component.
When an actual application is running everything is working fine.
However, when testing the component I get an error saying that the service is undefined when trying to access any of its properties/methods.
In the test i've put the service in "needs" like so:
needs: ['service:my-service']
"Needing" other components (e.g. child ones used inside) works as expected, services strangely fail.
Are there any additional steps that need to be done?
Running ember-cli 0.1.12.
When you generate a service, it also generates an initializer whose job it is to inject the service into the various places that you need it.
So, when you run acceptance tests your app will have booted and initializers will have been run, therefore the services will be available.
However, when unit testing components you get a clean container (better for testing). You just need to inject what you need:
moduleForComponent('foo-bar', null, {
setup: function(container) {
container.register('service:foo', FooService);
container.injection('component', 'fooService', 'service:foo');
}
});
I managed to get this working by using the new Ember.inject API available in the latest (as of writing) 1.10 release.
Apparently the new inject API is intended to replace needs in the future, it also works great with unit tests.
We just managed to get one working using needs: ['service:myService'] instead of needs: ['service:my-service'].

Unity.MVC4 Doesn't Dispose()

I've installed the NuGet Unity.MVC4 package http://nuget.org/packages/Unity.Mvc4/ and have hooked it up the same as I would if I were using the Unity.MVC3 package.
My dependencies are getting resolved correctly, but when using the HierarchicalLifetimeManager, my object's Dispose() method is not called at the end of the request.
I've actually set up a simple project using Unity.MVC3 and Unity.MVC4, with the exact same Bootstrapper.cs code in both projects. On the MVC3 version, Dispose() is called; on the MVC4 version, it is not.
I'm registering my type like so
container.RegisterType<ITest, Test>(new HierarchicalLifetimeManager());
with a very simple Test class
public interface ITest
{
void Foo();
}
public class Test : IDisposable, ITest
{
public Test()
{
}
public void Foo()
{
}
public void Dispose()
{
}
}
I don't think I'm doing anything incorrectly, but there appears to be some bug in the Unity.MVC4 package.
If anyone is successfully using that package, I'm curious how you got it to work.
The best solution to this issue is to upgrade to Unity3 and install the Unity Bootstrapper for ASP.NET MVC package. The Bootstrapper package includes PerRequestLifetimeManager which should be used in place of HierarchicalLifetimeManager. Once the integration is complete, Dispose() is called at the end of every HTTP request just as expected.
Note that the newest Unity documentation suggests that PerRequestLifetimeManager should not be used at all unless absolutely necessary. (I believe, however, that it is still needed in some cases - for example, where you want to share a DbContext across all objects used during a single request.)
With this solution, Unity.MVC4 is no longer needed and can be uninstalled.
I have had a look at the code. We simply ported the Unity.MVC3 code from codeplex (http://unitymvc3.codeplex.com/) and re-bundled it up for MVC4.
We have not made any alterations to the code.
Unity.MVC4 makes use of the Unity package managed by Microsoft (http://nuget.org/packages/Unity/). The majority of the code is in Unity.
Are you running different Dot.Net versions? i.e 4.0 vs 4.5? There seems to be a pre-release Unity for DotNet 4.5.

VS2012 Entity Framework Error

I have a MCV 4.5 solution with 3 projects. Site, Testing and Model. Site and Model are referencing EF 5.0. I have searched all solution files for a reference to 4.3.1 and have come up empty. I have deleted and recreated all references to EF 5.0
I have a HomeControllerTest.cs that runs just fine.
using this as a test
[TestMethod]
public void Index()
{
// Arrange
HomeController controller = new HomeController();
// Act
ViewResult result = controller.Index() as ViewResult;
// Assert
Assert.AreEqual("Modify this template to jump-start your ASP.NET MVC application.", result.ViewBag.Message);
}
I Created a new LOBControllerTest.cs to support the LOBController.cs in the Site Project. This test class fails with the error 'Could not load file or assembly 'EntityFramework, Version=4.3.1.0' using the following test
[TestMethod]
public void Index()
{
// Arrange
LOBController controller = new LOBController();
// Act
ViewResult result = controller.Index() as ViewResult;
// Assert
Assert.IsNotNull(result);
}
If I change the above test to execute the HomeController as in the following, it runs just fine.
[TestMethod]
public void Index()
{
// Arrange
HomeController controller = new HomeController();
// Act
ViewResult result = controller.Index() as ViewResult;
// Assert
Assert.IsNotNull(result);
}
This is a brand new clean install of VS2012 on a clean install of Windows Server 2012.
Any Thoughts?
Update, I forgot to mention I am also using ReSharper 7.1. I'm wondering if that has a setting that I was missing.
I found that there is a documented bug with RS7 stackoverflow.com/questions/12357696/… so I disabled the RS7 testing suite and tried running it directly from VS2012 interface with the same result. So it's not isolated to RS7.
Update:
here's a link https://www.dropbox.com/sh/740w2jsp8i1mslg/pWiwnSewHQ to access this project for anyone who want's to take a look at it. It's nothing special it's just a Template project. We are starting on a new project at work and I'm new to MVC and Test Driven Development so I'm trying to get a head start.
Update 9/21/2012
I believe I've found it. After talking to the Dev who put the original Wholesale template solution together I found that the Repositories folder in the Wholesale.Admin is references a NUGet code package. I checked the package site and found that the latest release is dependent on EF 4.3.1
Update:
This is confirmed. I no longer get the error after downloading and upgrading the solution from the site. I get another error but the 4.3.1 is no longer an issue. Hope the dev will update his NuGet solution, he hasn't updated it in 7 months.
Obviously your LOBController references EF 4.3 somehow, somewhere. Check your references in the class library containing this controller, or maybe a dll that's still in the bin folder or in the GAC...
Hope this helps
After talking to the Dev who put the original Wholesale template solution together I found that the Repositories folder in the Wholesale.Admin references a NUGet code package. I checked the package site and found that the latest release is dependent on EF 4.3.1. I downloaded the source and recompiled referencing EF 5.0 and that cleared the 4.3.1 error