unity-container | 易学教程

How to remove(unregister) registered instance from Unity mapping?

阅读更多关于 How to remove(unregister) registered instance from Unity mapping?

问题 I meet one problem that i can't solve now. I have the following: UnityHelper.DefaultContainer.RegisterInstance(typeof(IMyInterface), "test", instance); where UnityHelper.DefaultContainer is my helper for getting unity container with loaded configuration. here I registered instance as an instance of IMyInterface . So anywhere( some time after using) I want to remove this mapping. Remove it at all. How I can do it? I have tried: UnityHelper.DefaultContainer.Teardown(instance) but is was

Resolving IEnumerable<T> with Unity

阅读更多关于 Resolving IEnumerable with Unity

问题 Can Unity automatically resolve IEnumerable<T> ? Let's say I have a class with this constructor: public CoalescingParserSelector(IEnumerable<IParserBuilder> parserBuilders) and I configure individual IParserBuilder instances in the container: container.RegisterType<IParserSelector, CoalescingParserSelector>(); container.RegisterType<IParserBuilder, HelpParserBuilder>(); container.RegisterType<IParserBuilder, SomeOtherParserBuilder>(); can I make this work without having to implement a custom

Cannot Inject Dependencies into ASP.NET Web API Controller using Unity

阅读更多关于 Cannot Inject Dependencies into ASP.NET Web API Controller using Unity

问题 Has anyone had any success running using an IoC container to inject dependencies into ASP.NET WebAPI controllers? I cannot seem to get it to work. This is what I'm doing now. In my global.ascx.cs : public static void RegisterRoutes(RouteCollection routes) { // code intentionally omitted } protected void Application_Start() { AreaRegistration.RegisterAllAreas(); RegisterGlobalFilters(GlobalFilters.Filters); RegisterRoutes(RouteTable.Routes); IUnityContainer container = BuildUnityContainer();

How to inject ApplicationUserManager with unity

阅读更多关于 How to inject ApplicationUserManager with unity

问题 I have ApplicationUserManager defined like this: public class ApplicationUserManager : UserManager<ApplicationUser, int> { public ApplicationUserManager(IUserStore<ApplicationUser, int> store) : base(store) { } public override Task<IdentityResult> CreateAsync(ApplicationUser user, string password) { var result = base.CreateAsync(user, password); //... Repository.DoSomething(...); //Repository is null here //.. } [Dependency] public IRepository Repository { get; set; } } For some reason my

Using ASP.NET Session for Lifetime Management (Unity)

阅读更多关于 Using ASP.NET Session for Lifetime Management (Unity)

问题 I am considering using Unity to manage the lifetime of a custom user class instance. I am planning on extending the LifetimeManager with a custom ASP.NET session manager. What I want to be able to do is store and retrieve the currently logged in user object from my custom classes, and have Unity get the instance of User from the session object in ASP.NET, or (when in a Win32 project) retrieve it statically or from the current thread. So far my best solution is to create a static instance of

MEF vs. any IoC

阅读更多关于 MEF vs. any IoC

Looking at Microsoft's Managed Extensibility Framework (MEF) and various IoC containers (such as Unity), I am failing to see when to use one type of solution over the other. More specifically, it seems like MEF handles most IoC type patterns and that an IoC container like Unity would not be as necessary. Ideally, I would like to see a good use case where an IoC container would be used instead of, or in addition to, MEF. When boiled down, the main difference is that IoC containers are generally most useful with static dependencies (known at compile-time), and MEF is generally most useful with

Can Unity be made to not throw SynchronizationLockException all the time?

阅读更多关于 Can Unity be made to not throw SynchronizationLockException all the time?

The Unity dependency injection container has what seems to be a widely known issue where the SynchronizedLifetimeManager will often cause the Monitor.Exit method to throw a SynchronizationLockException which is then caught and ignored. This is a problem for me because I like to debug with Visual Studio set to break on any thrown exception, so every time my application starts up I'm breaking on this exception multiple times for no reason. How can I prevent this exception from being thrown? Wherever this issues is mentioned elsewhere on the web, the advice usually involves changing the debugger

Can I register my types in modules in Unity like I can in Autofac?

阅读更多关于 Can I register my types in modules in Unity like I can in Autofac?

问题 I am fairly familiar with Autofac and one feature that I really love about Autofac is the registering of modules. Does anyone know how I can do this with Unity? I'm having a hard time finding which terms to use in Google to come up with the unity equivalent if there is one. public class Global : HttpApplication, IContainerProviderAccessor { private static IContainerProvider _containerProvider; protected void Application_Start(object sender, EventArgs e) { var builder = new ContainerBuilder();

Comparing Castle Windsor, Unity and StructureMap

阅读更多关于 Comparing Castle Windsor, Unity and StructureMap

In a follow up to Krzysztof’s statement that Windsor does a lot more than other IoC’s, I wanted to understand how these IoC’s stack up against each other and the benefits/additional facilities that castle Windsor provides. Are there any comparisons? Can someone help me understand the additional features that Castle Windsor provides over other IoC’s Mauricio Scheffer See here and here for a pretty thorough technical comparison of several IoC containers, although somewhat outdated by now (they're from before Windsor 2.0) However, I don't think there are really any vital features that Windsor

ASP.NET MVC inject per request

阅读更多关于 ASP.NET MVC inject per request

问题 I need to inject EF context per request. Is there any way to implement it? 回答1: The solution proposed in the Unity Discussion list is to create a child container per request, have that child container create the EF context as ContainerControlledLifetime, then have the child container disposed at the end of the request. By doing so you don't have to create a custom LifetimeManager. I'm not very familiar with Unity but the principle would be something like this: Application_BeginRequest(...) {