Ninject.Web.PageBase still resulting in null reference to injected dependency - asp.net

I have an ASP.NET 3.5 WebForms application using Ninject 2.0. However, attempting to use the Ninject.Web extension to provide injection into System.Web.UI.Page, I'm getting a null reference to my injected dependency even though if I switch to using a service locator to provide the reference (using Ninject), there's no issue.
My configuration (dumbed down for simplicity):
public partial class Default : PageBase // which is Ninject.Web.PageBase
{
[Inject]
public IClubRepository Repository { get; set; }
protected void Page_Load(object sender, EventArgs e)
{
var something = Repository.GetById(1); // results in null reference exception.
}
}
...
//global.asax.cs
public class Global : Ninject.Web.NinjectHttpApplication
{
/// <summary>
/// Creates a Ninject kernel that will be used to inject objects.
/// </summary>
/// <returns>
/// The created kernel.
/// </returns>
protected override IKernel CreateKernel()
{
IKernel kernel =
new StandardKernel(new MyModule());
return kernel;
}
..
...
public class MyModule : NinjectModule
{
public override void Load()
{
Bind<IClubRepository>().To<ClubRepository>();
//...
}
}
Getting the IClubRepository concrete instance via a service locator works fine (uses same "MyModule"). I.e.
private readonly IClubRepository _repository = Core.Infrastructure.IoC.TypeResolver.Get<IClubRepository>();
What am I missing?
[Update] Finally got back to this, and it works in Classic Pipeline mode, but not Integrated. Is the classic pipeline a requirement?
[Update 2] Wiring up my OnePerRequestModule was the problem (which had removed in above example for clarity):
protected override IKernel CreateKernel()
{
var module = new OnePerRequestModule();
module.Init(this);
IKernel kernel = new StandardKernel(new MyModule());
return kernel;
}
...needs to be:
protected override IKernel CreateKernel()
{
IKernel kernel = new StandardKernel(new MyModule());
var module = new OnePerRequestModule();
module.Init(this);
return kernel;
}
Thus explaining why I was getting a null reference exception under integrated pipeline (to a Ninject injected dependency, or just a page load for a page inheriting from Ninject.Web.PageBase - whatever came first).

This is fairly puzzling because from what I can tell it appears that you have everything configured correctly. From the fact that you are getting a Null Reference Exception instead of an ActivationException, it would seem that the page level injection does not appear to be happening. Typically this is due to the protection level of the property being injected, but based on your code there is no issue there. Here are some things you can try to help track down what this issue is:
The call to Kernel.Inject(this), which initiates the property injection for Ninject is done in the OnInit method of the PageBase class. If for some reason this method is not getting executed it could result in the issue your seeing. You can do some further investigation by overriding the RequestActivation() method, which is the method called to do the actual injection (be sure to call base.RequestActivation()). If your override is never called, then there is an issue with the OnInit.
The InjectAttribute is set up in the default kernel configuration, so there should not be any need to specify it, however if you wanted to be extra certain, you could set up the attribute mapping in your kernel set up by doing something like:
IKernel kernel = new StandardKernel(new NinjectSettings { InjectAttribute = typeof(InjectAttribute) },new MyModule());
The kernel instance used by the PageBase class for the injection (and likewise the one that should be instantiated by your CreateKernel override in your Global.asax.cs) is stored in a service locator type object in Ninject.Web.KernelContainer. I would make sure you can see the Kernel property on KernelContainer and that it is not null from your Page_Load method.
Thats all I've got at the moment as far as insight. Like I said it appears from here that you have all of your ducks dressed and put in rows, so they should be working....
Good luck tracking down the issue.

This may not be specific to Ninject. I can get the same exception running in integrated mode with no IoC. I just have a simple asp.net app that just contains one aspx page with no logic.
In my global.asax file i have the following:
public class Global : HttpApplication
{
protected void Application_Start(object sender, EventArgs e)
{
this.EndRequest += new EventHandler(Global_EndRequest);
}
void Global_EndRequest(object sender, EventArgs e)
{
// do stuff
}
Basically subscribing to an event in the application_start causes this exception for me when running in integrated pipeline mode. Switching to classic pipeline or removing the event subscription and handler makes the error go away. I'm running IIS 7.5 on Win7 Enterprise 64bit.
This may not solve your specific problem but i'm posting here as this is the only page that came up when i pasted the exception into google! I'll move my answer into a separate question when i'm allowed to ask one. I have no stackoverflow kudos yet :(

Related

Structure Map Error Code 202

I am fairly used to using Structure Map IoC with MVC, but have recently had to adapt it to legacy web forms.
I have done this by providing a IoCContainer class that has a Configure() method on it such as the following that handles the registry.
public static void Configure()
{
var log = LogManager.GetLogger(typeof (Global1));
log.Debug("Initializing Container");
/*Initialize IoC Container*/
ObjectFactory.Initialize(x =>
{
x.For<ITokenService>().Use<TokenService>();
x.For<ILocalizationService>().Use<LocalizationService>();
log.Debug("Initializing Object Factory");
/*Setup Property Injection*/
x.SetAllProperties(p =>
{
p.OfType<ITokenService>();
p.OfType<ILocalizationService>();
});
});
}
I have provided a base control that contains the BuildUp() method BasePage.cs, such as the following.
public BasePage()
{
var log = LogManager.GetLogger(typeof (Global1));
log.Debug("Base Page Build Up");
/*Inject Dependencies*/
ObjectFactory.BuildUp(this);
}
In one of my classes I am using autowiring to inject the LocalizationService into an ILocalization Property.
Everything works perfectly fine on my local machine, but for some reason, when I deploy this code to our staging server, it is giving me the following StructureMap Exception:
StructureMap Exception Code: 202
No Default Instance defined for PluginFamily SuperShuttle.Web.Applications.Reservations.Interfaces.Services.ILocalizationService, SuperShuttle.Web.Applications.Reservations, Version=3.6.27.0, Culture=neutral, PublicKeyToken=null
Not quite sure why it would change when I deploy my application, especially since I am just copying and pasting the files.
Edit I am calling IoCContainer.Configure() in Application_Start() of Global.asax such as the following:
protected void Application_Start(object sender, EventArgs e)
{
log.Debug("In Application Start - Pre BuildUp");
/*Configure Ioc Container*/
IocConfigurator.Configure();
}

Handling application-wide events without Global.asax

My project has no "global.asax" for various reasons and I can't change that (it's a component). Also, I have no access to web.config, so an httpModule is also not an option.
Is there a way to handle application-wide events, like "BeginRequest" in this case?
I tried this and it didn't work, can someone explain why? Seems like a bug:
HttpContext.Current.ApplicationInstance.BeginRequest += MyStaticMethod;
No, this is not a bug. Event handlers can only be bound to HttpApplication events during IHttpModule initialization and you're trying to add it somewhere in the Page_Init(my assumption).
So you need to register a http module with desired event handlers dynamically. If you're under .NET 4 there is a good news for you - there is PreApplicationStartMethodAttribute attribute (a reference: Three Hidden Extensibility Gems in ASP.NET 4):
This new attribute allows you to have
code run way early in the ASP.NET
pipeline as an application starts up.
I mean way early, even before
Application_Start.
So the things left are pretty simple: you need to create your own http module with event handlers you want, module initializer and attribute to your AssemblyInfo.cs file . Here is a module example:
public class MyModule : IHttpModule
{
public void Init(HttpApplication context)
{
context.BeginRequest += new EventHandler(context_BeginRequest);
}
public void Dispose()
{
}
void context_BeginRequest(object sender, EventArgs e)
{
}
}
To register module dynamically you could use DynamicModuleUtility.RegisterModule method from the Microsoft.Web.Infrastructure.dll assembly:
public class Initializer
{
public static void Initialize()
{
DynamicModuleUtility.RegisterModule(typeof(MyModule));
}
}
the only thing left is to add the necessary attribute to your AssemblyInfo.cs:
[assembly: PreApplicationStartMethod(typeof(Initializer), "Initialize")]

ASP.Net MVC: How do you access the session from a different project within the solution?

I have 2 projects in my solution.
MVC Web application
Class library
The MVC Web application references the class library.
The class library contains a class that extends the default ASP.Net Controller.
I'm putting a variable in session in the application's Global.asax.
protected void Session_Start(object sender, EventArgs args)
{
HttpContext.Current.Session["DomainName"] = Request.Url.Host;
}
In the class library I'm trying to get the value from the HttpContext.Session, but HttpContext.Session keeps coming up null.
public class MyController : System.Web.Mvc.Controller
{
public MyController () : base()
{
//HttpContext.Session is always null at this point
ViewData["DomainName"] = HttpContext.Session["DomainName"];
}
}
HttpContext.Current.Session doesn't seem to be an option in controllers. Any ideas?
Two issues -- the HttpContext property in the Controller class is the current session. Unfortunately, it's not available in the constructor of the controller. Obviously because it's not passed in the constructor, it has to be set via the property afterwards. You might consider adding a property to hold the domain name and referencing the session from it -- that way it would be available for use when needed.
protected string DomainName
{
get { return this.HttpContext.Session["DomainName"] as string; }
}
The set it in ViewData in your actions or in OnActionExecuting/OnActionExecuted.
protected override void OnActionExecuted( ActionExecutedContext context )
{
ViewData["DomainName"] = this.HttpContext.Session["DomainName"];
// or ViewData["DomainName"] = this.DomainName; // if you used the property
}
If you're just trying to add ViewData from the session, try doing it in the OnActionExecuting method. This is where I typically add ViewData I want for every View.
You just use Session by itself (it's a property of Controller), but that just maps to Controller.HttpContext.Session (in other words, what you're already using), so it won't solve your problem, which must be elsewhere.
I'm not sure why you're putting this in the Session, though, as you can read Request.Url.Host directly during the Action.
When you create cookie then you must write
Response.AppendCookie("Your cookie name");
And if you want to get that then something like this
if (Request.Cookies["Your cookie name"] != null)
{
string value = Request.Cookies["Your cookie name"].Value;
}
and must if there are different solutions
then
machineKey
need to be same which is under
system.web
in web.config and then write
<httpCookies domain=".yourdomainname.com" />

Castle Windsor PerWebRequest LifeStyle and Application_EndRequest

I'm registering some components related to Linq2Sql using PerWebRequest lifestyle. I see them get created, but they get destroyed before my global's Application_EndRequest method gets called. Is that by design? Does anyone know a work around? I want to call commit on my UnitOfWork object to submitchanges() at the end of every request. In addition to using the Global.asax Application_EndResult, I've also tried an IHttpModule with the same results.
I'm using Castle 2.0.
Here's how I'm registering my stuff with PerWebRequest. I am creating a DataCOntextProvider object that holds onto a L2S DataContext. That object is injected into the UoW.
/// <summary>
/// Register the IUnitOfWorkManager to resolve to LinqToSqlUnitOfWorkManager per web request
/// </summary>
public void RegisterLinq2SqlUnitOfWorkPerWebRequest()
{
_container.Register(Component.For<IUnitOfWorkManager>()
.LifeStyle.PerWebRequest
.ImplementedBy<LinqToSqlUnitOfWorkManager>());
}
/// <summary>
/// Register the IDataContextProvider to resolve to DataContextProvider per web request
/// </summary>
public void RegisterDataContextProviderPerWebRequest()
{
_container.Register(Component.For<IDataContextProvider>()
.LifeStyle.PerWebRequest
.ImplementedBy<DataContextProvider>());
}
Now I am simply trying to pull the UoW from the container via the CommonServiceLocator (both CSL and Windsor Adapter are 1.0) from the EndRequest like this:
protected void Application_EndRequest(object sender, EventArgs e)
{
//ignore unless this is a page (.aspx) or handler (.ashx)
if (!RequestCanHaveContext())
return;
//get the IUnitOfWork manager
var uow = ServiceLocator.Current.GetInstance<IUnitOfWorkManager>();
//if we have one, commit changes at the end of the request
if (uow != null)
{
//don't explicitly dispose of uow or we'll get Disposed exceptions on the context
uow.Commit();
}
}
Thanks,
Corey
Try moving your Application_EndRequest code to a httpmodule and
register it before the PerWebRequestLifestyleModule.
your implementation of IUnitOfWorkManager should implement IDisposable and in Dispose call SubmitChanges. Alternatively use custom decommission submit changes concern.

Injecting Lower Layer Dependency in Presenter in an ASP.NET MVP Application

I recently read Phil Haack's post where he gives an example of implementing Model View Presenter for ASP.NET. One of the code snippets shows how the code for the view class.
public partial class _Default : System.Web.UI.Page, IPostEditView
{
PostEditController controller;
public _Default()
{
this.controller = new PostEditController(this, new BlogDataService());
}
}
However, here the view constructs the instance of the BlogDataService and passes it along to the presenter. Ideally the view should not know about BlogDataService or any of the presenter's lower layer dependencies. But i also prefer to keep the BlogDataService as a constructor injected dependency of the presenter as it makes the dependencies of the presenter explicit.
This same question has been asked on stackoverflow here.
One of the answers suggests using a service locator to get the instance of the BlogDataService and passing it along to the presenter's constructor.This solution however does not solve the problem of the view knowing about the BlogDataService and needing to explicitly get a reference to it.
Is there a way to automatically construct the presenter object using an IoC or DI container tool such that the view does not have to deal with explicitly creating the BlogDataService object and also injecting the view and service instances into the presenter's constructor. I prefer to use the constructor injection pattern as far as possible.
Or is there a better design available to solve the problem?. Can there be a better way to implement this If i am building a WinForms application instead of a ASP.NET WebForms application?
Thanks for any feedback.
Yes there is. For example using StructureMap in a webform constructor:
public partial class AttributeDetails : EntityDetailView<AttributeDetailPresenter>, IAttributeDetailView
{
public AttributeDetails()
{
_presenter = ObjectFactory.With<IAttributeDetailView>(this).GetInstance<AttributeDetailPresenter>();
}
....
}
and as you can see here presenter needs view and service injected
public AttributeDetailPresenter(IAttributeDetailView view, IAttributeService attributeService)
{
MyForm = view;
AppService = attributeService;
}
You can also use StructureMap BuildUp feature for webforms so that you can avoid using ObjectFactory directly in your view.
I did exactly this. The solution is based on Autofac, but can be implemented on top of any container.
First, define an interface representing the authority for presenting views in a request to the MVP system:
public interface IMvpRequest
{
void Present(object view);
}
Next, create a base page which has a property of that type:
public abstract class PageView : Page
{
public IMvpRequest MvpRequest { get; set; }
}
At this point, set up dependency injection for pages. Most containers have ASP.NET integration, usually in the form of HTTP modules. Because we don't create the page instance, we can't use constructor injection, and have to use property injection here only.
After that is set up, create event arguments representing a view which is ready to be presented:
public class PresentableEventArgs : EventArgs
{}
Now, catch the events in PageView and pass them to the request (present the page as well):
protected override bool OnBubbleEvent(object source, EventArgs args)
{
var cancel = false;
if(args is PresentableEventArgs)
{
cancel = true;
Present(source);
}
else
{
cancel = base.OnBubbleEvent(source, args);
}
return cancel;
}
protected override void OnLoad(EventArgs e)
{
base.OnLoad(e);
Present(this);
}
private void Present(object view)
{
if(MvpRequest != null && view != null)
{
MvpRequest.Present(view);
}
}
Finally, create base classes for each type of control you'd like to serve as a view (master pages, composite controls, etc.):
public abstract class UserControlView : UserControl
{
protected override void OnLoad(EventArgs e)
{
base.OnLoad(e);
EnsureChildControls();
RaiseBubbleEvent(this, new PresentableEventArgs());
}
}
This connects the control tree to the MVP system via IMvpRequest, which you'll now have to implement and register in the application-level container. The ASP.NET integration should take care of injecting the implementation into the page. This decouples the page entirely from presenter creation, relying on IMvpRequest to do the mapping.
The implementation of IMvpRequest will be container-specific. Presenters will be registered in the container like other types, meaning their constructors will automatically be resolved.
You will have some sort of map from view types to presenter types:
public interface IPresenterMap
{
Type GetPresenterType(Type viewType);
}
These are the types you will resolve from the container.
(The one gotcha here is that the view already exists, meaning the container doesn't create the instance or ever know about it. You will have to pass it in as a resolution parameter, another concept supported by most containers.)
A decent default mapping might look like this:
[Presenter(typeof(LogOnPresenter))]
public class LogOnPage : PageView, ILogOnView
{
// ...
}

Resources