It seem i can't get this to work. I made a custom MembershipProvider and i want to inject a repository inside but the [Inject] property just doesnt work.
public class PyrosphereMembershipProvider : MembershipProvider
{
[Inject]
protected IDepositoireUtilisateur DepositoireUtilisateur { get; set; }
[Inject]
protected IDepositoireProfile DepositoireProfile { get; set; }
...
I think this is because this class are created way before the MVC application is running which cause the actual problem. I am getting more problem trying to use the membershipprovider than making my own system.
About my ninject configuration i am using the App_Start directory method. All my binding are correct ive looked so that nothing to do with my bindings.
Any help is appreciated!
The ASP.NET Providers aren't designed for proper dependency injection. There are only workarounds for them.
Either you have to setup a binding for them and resolve atleast one instance before using them. E.g. by injecting an instance into the Global.asax or you have to Inject an instance manually before the first use (kernel.Inject(...)). Again most likely in the global.asax application start method.
Related
I have a simple ASP.Net Core app which uses razor. The user forms are generated by model and data annotation attributes. The error message of wrong input values are English by default. I knew that I can translate default message with help of 'ModelBindingMessageProvider'.
Below you can find a working way (in Startup.cs) by update the 'DefaultModelBindingMessageProvider':
public void ConfigureServices(IServiceCollection services)
{
services.AddMvc(o =>
{
// see: https://stackoverflow.com/questions/40828570/asp-net-core-model-binding-error-messages-localization
o.ModelBindingMessageProvider.SetValueMustNotBeNullAccessor(u => "My custom validation error message");
});
}
I would prefer not to configure the translation directly in the startup.cs. One way to do that is using a custom class which inherits from 'ModelBindingMessageProvider'.
public class MyModelBindingMessageProvider : ModelBindingMessageProvider
{
public override Func<string, string> ValueMustNotBeNullAccessor => o => "My custom validation error message";
}
Here is my question:
Where register My own class?
Is this a good way? What is best practice at the moment?
(the real app uses string resources of course)
Unfortunately it looks like it's not possible to provide a custom implementation of ModelBindingMessageProvider in ASP.NET Core 3.1.
The constructor of MvcOptions sets the ModelBindingMessageProvider property to an instance of DefaultModelBindingMessageProvider.
ModelBindingMessageProvider = new DefaultModelBindingMessageProvider();
And the property itself has no setter and is not of type ModelBindingMessageProvider.
public DefaultModelBindingMessageProvider ModelBindingMessageProvider { get; }
tl;dr Even though the option of having an own implementation would make sense here, you have to configure the messages in the Startup class.
This one is driving me mad. I've read the Ninject docs, I've read the docs for the Ninject MVC extension, I've lost count of how many related SO questions I've read, and I have no idea where the problem is with my code.
I'm building a webapp in ASP.NET MVC 4, and I'm using Ninject to bind repository interfaces. The docs say that if you add Ninject using NuGet (which I did), then it wires everything up for you so you don't need to have your application inherit from NinjectHttpApplication (so I haven't) and you just need to add your bindings in NinjectWebCommon.RegisterServices(), (which I have). I have an IRepository<T>, and a Repository<T>. The user repository has a few extra methods for login and registration, so there's a separate UserRepository which implements IRepository<User>. My bindings therefore look like this:
kernel.Bind(typeof(IRepository<>)).To(typeof(BaseRepository<>)).InRequestScope();
kernel.Bind(typeof(IRepository<User>)).To(typeof(UserRepository)).InRequestScope();
The docs, and a couple of SO questions, also mention that if you added Ninject though NuGet (which I did) then it sorts out the controller factory for you and you don't need to implement your own Ninject-y controller factory (so I haven't). My controllers inherit from a BaseController, which has a constructor that accepts a set of IRepository-compatible repositories. Now, from what I've read, when I try to use a controller, Ninject should recognise the IRepositoriy parameters and provide them. It doesn't. Even if I put the [Inject] attribute on the constructor, it still gets ignored - the parameterless constructor gets called instead. If I remove the parameterless constructor, I get a compile error complaining that there isn't one.
What have I missed? How do I get Ninject to provide my repositories?
Weird, I am unable to reproduce the problem you are describing.
Steps:
Create a new ASP.NET MVC 4 application using the Internet template
Install the Ninject.MVC3 NuGet
Define some classes:
public interface IRepository<T>
{
}
public abstract class BaseRepository<T> : IRepository<T>
{
}
public class User
{
}
public class UserRepository : BaseRepository<User>
{
}
public abstract class BaseController<T>: Controller
{
protected BaseController(IRepository<T> repository)
{
this.Repository = repository;
}
protected IRepository<T> Repository { get; private set; }
}
public class HomeController : BaseController<User>
{
public HomeController(IRepository<User> repository): base(repository)
{
}
public ActionResult Index()
{
return Content(this.Repository.GetType().ToString());
}
}
And wire them up in ~/App_Start/NinjectWebCommon.cs:
private static void RegisterServices(IKernel kernel)
{
kernel
.Bind(typeof(IRepository<User>))
.To(typeof(UserRepository))
.InRequestScope();
}
Run the application and the proper instance of the repository gets injected into HomeContorller.
My current setup is using Ninject for simple IoC, everything goes fine, but I'm not able to resolve one of the classes I need inside my AuthorizeAttribute. I need to access a class that does ClaimsVerification:
Here's my code:
IoC Config:
var kernel = new StandardKernel(); // Ninject IoC
// These registrations are "per instance request".
// See http://blog.bobcravens.com/2010/03/ninject-life-cycle-management-or-scoping/
kernel.Bind<RepositoryFactories>().To<RepositoryFactories>()
.InSingletonScope();
kernel.Bind<IRepositoryProvider>().To<RepositoryProvider>();
kernel.Bind<ISmartDocumentorUow>().To<SmartDocumentorUow>();
kernel.Bind<IClaimsVerification>().To<ClaimsVerification>();
// kernel
//kernel.BindFilter<MyAuthorizeAttribute>(FilterScope.Controller, 0).WhenControllerHas<RequireRolesAttribute>();
// Tell WebApi how to use our Ninject IoC
config.DependencyResolver = new NinjectDependencyResolver(kernel);
MyAuthorizeAttribute:
public class MyAuthorizeAttribute : AuthorizeAttribute
{
[Inject]
IClaimsVerification clamisverify { get; set; }
public MyAuthorizeAttribute()
{
//var x = System.Web.Mvc.DependencyResolver.Current.(typeof(IClaimsVerification));
}
Yap, sorry, the problem was injecting the iClaimsverification that isn't working in web api..
I tryed with the public property and still it didn't work.
the bindfilter is commented out, because it doesn't exist in the core NInject api (dll), it does exists in the MVC dll of ninject but it works for Action filters in the web mvc, and not in the api mvc for what i can tell..
i do solved the issue like this, though i don't like a lot of this fix:
private IClaimsVerification verifier
{
get
{
return (GlobalConfiguration.Configuration.DependencyResolver.GetService(typeof(IClaimsVerification)) as IClaimsVerification);
}
}
The property you have marked with Inject is private - you need to initialize Ninject with a custom configuration to opt into what would be a much less efficient process
(You didnt state the problem in your question. I see you were trying BindFilter, but it's commented out (why?) - this is the correct approach. I recommend reading the Ninject.MVC3 wiki article on BindFilter for an example)
I am trying to create an IOC container in Castle Windsor that's configuration is shared across assemblies.
(What follows is an example of how this works in Unity. What I want to do is to make it work the same way using Castle Windsor)
I have the following project configuration...
TestCompany.Services.Host
(Web project hosting a number of .svc files)
PrintService.svc
Web.Config
Unity.Config
TestCompany.Services.PrintService
IPrintService.cs
PrintService.cs
The actual implementation of my "PrintService" is not implemented inside my Services.Host but in the TestCompany.Services.PrintService assembly.
As part of my shared project code (not shown) I have a container helper which is responsible for loading the unity configuration...
public static IUnityContainer GetContainer()
{
// Checks for existance of container (_container == null) ommitted.
var section = ConfigurationManager.GetSection("unity") as UnityConfigurationSection;
section.Configure(_container, name);
...
...
}
This method loads the unity configuration section from the Unity.Config and uses it to configure the container.
The advantage of this method is that one Unity.Config loaded inside (I presume) the AppDomain can service a number of assemblies. Simply calling GetContainer() from any of the assemblies consumed by my service host will return a container populated with the same type resolution's etc.
I really want to use the fluent configuration in Castle Windsor but I dont see how without this "shared" configuration file that can be acheived. PrintService and any future services will all need to resolve the same dependencies and I dont want to have to repeat my fluent configuration between these services.
Ideally I need some sort of container configured in the service host app that can "flow" into all of the assemblies that it makes use of.
Thanks.
I think I may not be understanding your question but I think I understand your scenario and here is how I do something similar, if it helps at all...
My Philosophy:
Each part of the application should be in charge of registering what
it knows about and nothing more, so there is no need for a single
central configuration file and things that are shared between
components are registered in one place and their interfaces are
available everywhere via a common library.
So let's take an example...
First of all, let us just say (for the purposes of my example) that IPrintService is something that you want to register an implementation of once and use throughout the application and that we have some other component that needs to be implemented by some external module from the main application. We, therefore, create an assembly called Common like so:
Common
public interface IPrintService
{
void Print();
}
public interface IMyService
{
void DoSomething();
}
Now let us think about the main part of the application (maybe it is an ASP .NET application, maybe justa console application, does not really matter). Here we construct the container and ask it to find all the possible components. We can do that like so:
Main Application
// Could be the Global.asax code behind but for simplicity this is
// just a console application
class Program
{
private static readonly IWindsorContainer Mycontainer
= BootstrapContainer();
// Allow access to the raw container - this is probably a bad idea but
// in the rare case that you need it you can get it from here
public static IWindsorContainer Container { get { return Mycontainer; } }
private static IWindsorContainer BootstrapContainer()
{
// Here we will just install every IWindsorInstaller found in any
// assembly in the same folder as the application (so no need for
// references or anything).
var c = new WindsorContainer();
string folder = Path.GetDirectoryName(
Assembly.GetExecutingAssembly().Location);
c.Install(FromAssembly.InDirectory(new AssemblyFilter(folder)));
return c;
}
}
// Here is the print service implementation
public class MyPrintService : IPrintService
{
public void Print()
{
// Print!
}
}
// This is the installer for the main module - here we are saying exactly
// what is implementing the interface
public class MainApplicationInstaller : IWindsorInstaller
{
public void Install(IWindsorContainer container,
IConfigurationStore store)
{
container
.Register(Component
.For<IPrintService>()
.ImplementedBy<MyPrintService>());
}
}
So now we have a common library with our shared inetrfaces and a main application that will register an implementation for our shared interface and also load up any other modules in the system.
The only thing, therefore, left to do is to consume that print service and use it. We can do this anywhere that is using the container so let's create a third assembly that references only Common (we will call it test module.
Test Module
// This installer installs just the things inside this module since that
// is all it knows about but those things can use things that are
// registered in the container by anybody.
public class TestModuleInstaller : IWindsorInstaller
{
public void Install(IWindsorContainer container,
IConfigurationStore store)
{
container
.Register(Component
.For<IMyService>()
.ImplementedBy<MyServiceThatDoesSomething>());
}
}
public class MyServiceThatDoesSomething : IMyService
{
private readonly IPrintService _printService;
public MyServiceThatDoesSomething(IPrintService printService)
{
_printService = printService;
}
public void DoSomething()
{
// Use the print service!
_printService.Print();
}
}
Finally compile everything and copy the test module to the same folder as the main application and then from the main you can do this:
Container.Resolve<IMyService>().DoSomething();
And then the magic happens! Well, some code runs and you find that the print service is called by the class from the module even though it knows nothing about it.
Anyway, maybe that helps a little bit, maybe not, good luck!
I've created a Web Api filter (using System.Web.Http.Filters.ActionFilterAttribute) but I am unable to get it to work inside of ASP.Net MVC 4. I tried adding it to the RegisterGlobalFilters() method but that didn't work.
So if one is using Web Api hosted in ASP.Net MVC how does one register filters?
The following code, in my Global.asax, works for me:
public static void RegisterWebApiFilters(System.Web.Http.Filters.HttpFilterCollection filters)
{
filters.Add(new MyWebApiFilter());
}
protected void Application_Start()
{
RegisterWebApiFilters(GlobalConfiguration.Configuration.Filters);
}
note that this answer holds true up to MVC 5/Web API 2
Short answer: MVC and Web API filters are not cross compatible, and if you want to register them globally, you must use the appropriate configuration classes for each.
Long answer: ASP.NET MVC and Web API are purposely designed to work in a similar way, but they are in fact different creatures.
Web API lives under the System.Web.Http namespace, whereas MVC lives under the System.Web.Mvc namespace. The two will happily live side by side, but one does not contain the other and despite the similarities in the programming model, the underlying implementations are different. Just as MVC controllers and Web API controllers inherit different base controller classes (MVC's is simply named Controller and Web API's is named ApiController) MVC filters and Web API filters inherit from different FilterAttribute classes (both share the same name in this case, but are separate classes which live in their respective namespaces).
Web API global filters are registered through the HttpConfiguration object available to you in the Register method WebApiConfig.cs if you're using a project template with WebActivator:
public static void Register(HttpConfiguration config)
{
//stuff before
config.Filters.Add(new MyWebApiFilter());
//stuff after
}
or otherwise in the global.asax.cs:
GlobalConfiguration.Configuration.Filters.Add(new MyWebApiFilter());
Mvc global filters are registered by way of a GlobalFilterCollection object, which is available to you through the RegisterGlobalFilters method of FilterConfig.cs for projects that are using WebActivator:
public class FilterConfig
{
public static void RegisterGlobalFilters(GlobalFilterCollection filters)
{
//stuff before
filters.Add(new MyMvcFilter());
//stuff after
}
}
or in the global.asax.cs file by way of GlobalFilters.Filters collection for those without WebActivator:
GlobalFilters.Filters.Add(new MyMvcFilter());
It's worth noting that in both cases you do not need to inherit from the appropriate FilterAttribute type. Web API Filters need only implement the System.Web.Http.IFilter interface, while MVC filter registration checks to ensure that your class inherits one of a handful of filter interfaces defined in the System.Web.Mvc namespace.
As of MVC 4 RC, the correct class name is HttpFilterCollection:
public static void RegisterWebApiFilters(System.Web.Http.Filters.HttpFilterCollection filters)
{
filters.Add(new MyWebApiFilter());
}
protected void Application_Start()
{
RegisterWebApiFilters(GlobalConfiguration.Configuration.Filters);
}
Instead of using global filters I prefer to do this :
[MyWebApiFilter]
public class CustomizedApiControllerBase : ApiController
{
...
}
And after that inherit all of api controllers from CustomizedApiControllerBase
This approach is more expressive in comparison with global filters in global.ascx file.