I have a web forms application in the Global.asax of which I am buiding the Simple Injector container like below. The reason I am doing two is because I am using Hangfire to schedule recurring jobs and it does not take the Scoped lifestyle which I currently have for the application since it runs as a background worked thread. I am getting the below error when I am creating two instances of the container for my EF entities.
The relationship between the two objects cannot be defined because they are attached to different ObjectContext objects
Can someone please tell me how I can have two containers with different lifestyles registered in my web forms applictaion.
ContainerConfig.BuildContainer();
var container = ContainerConfig.BuildContainerJobs();
public static Container BuildContainer()
{
var container = new Container();
container.Options.DefaultScopedLifestyle = new ExecutionContextScopeLifestyle();
container.Register<TraceTimer>(Lifestyle.Scoped);
container.Register<Entities>(() => new Entities(), Lifestyle.Scoped);
container.Register<ReferenceDataCache>(
() => ReferenceDataCacheFactory.Create(), Lifestyle.Scoped);
var adapter = new SimpleInjectorAdapter(container);
ServiceLocator.SetLocatorProvider(() => (IServiceLocator)adapter);
ExecutionContextScopeManager.Current = (IExecutionContextScopeManager)adapter;
return container;
}
public static Container BuildContainerJobs()
{
var container = new Container();
container.Options.DefaultScopedLifestyle = new ExecutionContextScopeLifestyle();
container.Register<Entities>(() => new Entities(), Lifestyle.Transient);
container.Register<ReferenceDataCache>(
() => ReferenceDataCacheFactory.Create(), Lifestyle.Transient);
var adapter = new SimpleInjectorAdapter(container);
ServiceLocator.SetLocatorProvider(() => (IServiceLocator)adapter);
ExecutionContextScopeManager.Current = (IExecutionContextScopeManager)adapter;
return container;
}
Global.asax code for registering
ContainerConfig.BuildContainer();
var container = ContainerConfig.BuildContainerJobs();
var options = new SqlServerStorageOptions
{
QueuePollInterval = TimeSpan.FromMinutes(5) // Default value
};
GlobalConfiguration.Configuration
.UseSqlServerStorage("Jobs",options);
GlobalConfiguration.Configuration.UseDefaultActivator();
GlobalConfiguration.Configuration.UseActivator(new SimpleInjectorJobActivator(container));
GlobalJobFilters.Filters.Add(new SimpleInjectorAsyncScopeFilterAttribute(container));
JobsHelper.SetRecurringJob();
_backgroundJobServer = new BackgroundJobServer();
This exception is not thrown by Simple Injector but by Entity Framework. This exception is typically caused by using instances of entities that are created with one DbContext inside another DbContext.
Unfortunately I can't be more specific and pinpoint where you are going wrong and how to fix this, because your question does not contain the appropriate details.
Related
I have an ASP.NET 5 application which still uses EF6 and I register my services with Autofac as follows:
builder.RegisterType<UnitOfWork>()
.As(typeof(IUnitOfWork))
.InstancePerDependency();
builder.RegisterAssemblyTypes(assemblies)
.Where(t => t.FullName.StartsWith("MyApp") && t.Name.EndsWith("Service"))
.AsImplementedInterfaces()
.InstancePerDependency();
Then in controllers I'm doing:
//Save object of type SomeObject
using (var scope = itemScope.BeginLifetimeScope())
{
var someService = itemScope.Resolve<ISomeService>();
var savedObject = await someService.SaveAsync(objectToSave);
}
The above runs in a loop in a background thread.
Originally I was not using child scopes. But then, using the diagnostic tools, I noticed that the SomeObject references are increasing and not being removed from the data context.
So I decided to add child scopes to have new instances every time. But this doesn't the problem. It stays as is.
If I'm using a child scope why does this happen, and how can I solve it?
You are still using itemScope to resolve the service. Note that scope was not used inside the using at all.
//Save object of type SomeObject
using (var scope = itemScope.BeginLifetimeScope())
{
//var someService = itemScope.Resolve<ISomeService>();
var someService = scope.Resolve<ISomeService>();
var savedObject = await someService.SaveAsync(objectToSave);
}
How to get an instance of bushealth using Unity container IoC in Prism or without using a IoC container? Mass Transit relies on Microsoft Dependency Injection, however I am using Bus Factory to create an instance of the bus and its always not feasbile to use DI for legacy code.
_busControl = Bus.Factory.CreateUsingRabbitMq(sbc =>
{
sbc.Host(host, h =>
{
h.Username(username);
h.Password(password);
h.RequestedConnectionTimeout(timeout);
});
sbc.ReceiveEndpoint(e =>
{
...
});
You can either create an instance of BusHealth passing the bus instance on the constructor or you can register IBusHealth as a service in your container, with the BusHealth implementation type (which will require IBus to also be registered, as it is a required constructor dependency).
Then you can use the IBusHealth interface in your application to check bus health.
var busHealth = new BusHealth("bus");
_busControl = Bus.Factory.CreateUsingRabbitMq(sbc =>
{
sbc.ConnectBusObserver(busHealth);
sbc.ConnectEndpointConfigurationObserver(busHealth);
sbc.Host(host, h =>
{
h.Username(username);
h.Password(password);
h.RequestedConnectionTimeout(timeout);
});
sbc.ReceiveEndpoint(e =>
{
// ...
});
});
Of course, this doesn't explain how the bus/health objects get into your container, but I think you get the idea.
At first I did confidentially suppose that I could understand it, but via some simple example with Autofac, it appeared that I might understand it wrong, here is the code that I've tried:
//register the service
autofacBuilder.RegisterType<MyService>()
.As<IMyService>().InstancePerLifetimeScope();
//testing code
void _test1()
{
var myService = autofacContainer.Resolve<IMyService>();
}
void _test2()
{
_test1();
var myService = autofacContainer.Resolve<IMyService>();
}
Test it by running _test2() and you can simply check the instances resolved in the 2 methods.
So with the code above, I understand the myService in _test1 and myService in _test2 should be different. Because I think the lifetime scope of myService in _test1 should be just in that method while the lifetime scope of myService in _test2 should be in _test2 as well. So we have 2 different scopes here, but somehow the resolved instances of myService are the same one.
So could you please explain that issue to me, what does lifetime scope exactly mean here? inside one same class? or something even larger?
You're confusing c# scopes and autofac's scopes. It's like comparing apples and a fence. :) They are just different and have nothing to do with each other.
So, to clarify it please look at basic examples below. Please pay attention that the scopes should actually be destroyed by you if you are the one who started them as it is done in example 1. In other examples I skipped that for brevity.
// example 1
autofacBuilder.RegisterType<MyService>().As<IMyService>().InstancePerLifetimeScope();
var container = autofacBuilder.Build();
void _test1(IComponentContext scope){
var myService = scope.Resolve<IMyService>();
}
void _test2(IComponentContext scope){
// the same scope is used here and in _test1()
// this means that the service instance will be the same here and there
_test1(scope);
var myService = scope.Resolve<IMyService>();
}
// it's only here that DI lifetime scope starts
using (var scope = container.BeginLifetimeScope()) {
_test2(scope);
}
// example 2
autofacBuilder.RegisterType<MyService>().As<IMyService>().InstancePerLifetimeScope();
var container = autofacBuilder.Build();
void _test1(IComponentContext scope){
var myService = scope.Resolve<IMyService>();
}
void _test2(IComponentContext scope){
// now new scope is used in _test1() call
// this means that instances will be different here and there since they are resolved from different scopes
_test1(scope.BeginLifetimeScope());
var myService = scope.Resolve<IMyService>();
}
var scope = container.BeginLifetimeScope();
_test2(scope);
// example 3
// NOTE THIS!
autofacBuilder.RegisterType<MyService>().As<IMyService>().InstancePerDependency();
var container = autofacBuilder.Build();
void _test1(IComponentContext scope){
var myService = scope.Resolve<IMyService>();
}
void _test2(IComponentContext scope){
// the same scope is used here and in _test1()
// but now service instances will be different even though they are resolved from the same scope
// since registration directs to create new instance each time the service is requested.
_test1(scope);
var myService = scope.Resolve<IMyService>();
}
var scope = container.BeginLifetimeScope();
_test2(scope);
// example 4
autofacBuilder.RegisterType<MyService>().As<IMyService>().SingleInstance();
var container = autofacBuilder.Build();
void _test0(IComponentContext scope){
var myService = scope.Resolve<IMyService>();
}
void _test1(IComponentContext scope){
_test0(scope.BeginLifetimeScope());
var myService = scope.Resolve<IMyService>();
}
void _test2(IComponentContext scope){
// all the scopes used here and in other calls are different now
// but the service instance will be the same in all of them even though it is requested from different scopes
// since registration directs to get the same instance each time the service is requested regardless of the lifetime scope.
_test1(scope.BeginLifetimeScope());
var myService = scope.Resolve<IMyService>();
}
var scope = container.BeginLifetimeScope();
_test2(scope);
Context: Owin (self-host) + WebApi + UseAutofacMiddleware + UseAutofacWebApi
What I'm trying to do is:
Register an ILog instance in the app startup container.
For each request, register a new ILog instance wrapping the "root" instance, so that each middleware and/or per-request services can use it.
var containerBuilder = new ContainerBuilder();
containerBuilder.RegisterInstance(log).As<ILog>();
containerBuilder.Register(ctx => {
var rootLog = ctx.Resolve<ILog>();
return new PrependStringLog(rootLog, "request: ");
}).InstancePerRequest();
However, Autofac complains about circular dependencies when instancing middleware having an ILog in their constructors.
If I name the "root log", and resolve with the given name, everything works as expected.
containerBuilder.RegisterInstance(log)
.Named("root", typeof(ILog));
containerBuilder.Register(ctx => {
var rootLog = ctx.ResolveNamed<ILog>("root");
return new PrependStringLog(rootLog, "request: ");
}).InstancePerRequest();
Am I forced to use a named instance to make it work?
Autofac uses the latest registered service when a component request for a service.
In your case, the latest ILog registered is a lambda expression :
containerBuilder.Register(ctx => {
var rootLog = ctx.Resolve<ILog>();
return new PrependStringLog(rootLog, "request: ");
}).InstancePerRequest();
This lambda expression request an ILog which is what Autofac is trying to build : that's why it detects a circular dependency.
The easiest way to avoid the circular dependency is to make your registration not rely on itself. This is what you do by resolving a named ILog and this is the solution I recommend.
In your case, you can also directly use the root log without resolving it :
containerBuilder.RegisterInstance(rootLog).As<ILog>();
containerBuilder.Register(ctx => {
return new PrependStringLog(rootLog, "request: ");
}).InstancePerRequest();
Messenger.Default.Register<OpenWindowMessage>(this, message =>
{
var adventurerWindowVM = SimpleIoc.Default.GetInstance<AdventurerViewModel>();
adventurerWindowVM.Adv = message.Argument;
var adventurerWindow = new AdventurerView()
{
DataContext = adventurerWindowVM
};
adventurerWindow.Show();
});
This code is fairly simple; it just opens a new window and sets the DataContext of the new window. The problem I'm having is that if I execute this twice, the content of the first instance will be overwritten and be set to that of the second since adventurerWindowVM is the DataContext of both windows and it is overwritten each time this code is called. I'm looking for a way to prevent this; I'd like to be able to open multiple windows using this message and have each of them be unique, but thus far I haven't figured out a way to do so. Any advice would be greatly appreciated. I apologize for the vague title; I was unsure of what to name this question. (Also, I know that this isn't a method. What would this block of code be called?)
Update: I'm using MVVM Light and my code is based off of an example somebody provided for me in this answer: https://stackoverflow.com/a/16994523/1667020
Here is some code from my ViewModelLocator.cs
public ViewModelLocator()
{
_main = new MainViewModel();
ServiceLocator.SetLocatorProvider(() => SimpleIoc.Default);
SimpleIoc.Default.Register<GameViewModel>();
SimpleIoc.Default.Register<AdventurerViewModel>();
}
Having given the other answer, I guess I can say the IoC container used here is just SimpleIoC from MvvmLight and to get a new instance of the VM on every GetInstance(...) all you need to do is pass in a unique key every time when trying to resolve an instance of the VM.
So you can switch
var adventurerWindowVM = SimpleIoc.Default.GetInstance<AdventurerViewModel>();
to
var adventurerWindowVM = SimpleIoc.Default.GetInstance<AdventurerViewModel>(System.Guid.NewGuid().ToString());
However as mentioned by the author of MVVMLight Here these VM's will get cached and we need to get rid of them when no longer needed. In your case probably when the Window is closed.
Thus I'd have that entire lambda something like:
Messenger.Default.Register<OpenWindowMessage>(this, message =>
{
var uniqueKey = System.Guid.NewGuid().ToString();
var adventurerWindowVM = SimpleIoc.Default.GetInstance<AdventurerViewModel>(uniqueKey);
adventurerWindowVM.Adv = message.Argument;
var adventurerWindow = new AdventurerView()
{
DataContext = adventurerWindowVM
};
adventurerWindow.Closed += (sender, args) => SimpleIoc.Default.Unregister(uniqueKey);
adventurerWindow.Show();
});
Note:
While this is somewhat longer 3 lines compared to just creating a new VM yourself with (new AdventurerViewModel()) I still favor this because if you use an IoC container to manage LifeTime of your VM's, then have it manage them completely. Don't really like mix-n-match when not needed. Rather keep the IoC Container doing what it's meant to do.
If you need more control over VM injection and Life-time management look at more sophisticated Ioc controllers such as Unity. SimpleIoC was just meant to be a simple get your feet "wet" in IoC kind of container and it does a very good job in that regard.
I think you are trying to use the same instance of your ViewModel with multiple views. So the views will obviously overwrite each others viewmodel contents.
What if you do this;
Messenger.Default.Register<OpenWindowMessage>(this, message =>
{
var adventurerWindowVM = new AdventurerViewModel();
adventurerWindowVM.Adv = message.Argument;
var adventurerWindow = new AdventurerView()
{
DataContext = adventurerWindowVM
};
adventurerWindow.Show();
});
It's a method call, passing in an anonymous method using a lambda expression.
It looks like you are getting your AdventurerViewModel from some sort of IoC container. How is the IoC container configured? In particular, what is the scope of the objects it gives you back? If you have the IoC configured to create objects in singleton scope, for example, then you will always get back a reference to the same object each time. You may need to configure the scope of the object in your IoC container so that it gives you back a fresh copy every time.
How you do that will depend on your IoC container. Without knowing which IoC framework you are using or seeing its configuration, it's impossible to make any further comment.
My advice would be to create an extension method for SimpleIOC. Something like this:
public static T CreateInstance<T>(this SimpleIoc simpleIoc)
{
// TODO implement
}
You already know the method to get the same instance; extended SimpleIoc with a method to create a new instance:
T instance = SimpleIoc.Default.GetInstance<T>();
T createdInstance = SimpleIoc.Defalt.CreateInstance<T>();
If you are not familiar with extension methods, see Extension Methods Demystified
The implementation:
Of type T, get the constructor.
If there is more than one constructor: either throw exception, or decide which constructor to use. Simple method: use the same method that is used in SimpleIoc.GetInstance, with an attribute. More elaborate method: try to find out if you can find registered elements that match one of the constructors. This is not explained here.
Once you've found the constructor that you need, get its parameters.
Ask SimpleIoc for instances of this parameter, or if they should be new also, ask SimpleIoc to create new instances.
CreateInstance
.
public static T CreateInstance<T>(this SimpleIoc ioc)
{
return (T)ioc.CreateInstance(typeof(T));
}
public static object CreateInstance(this SimpleIoc ioc, Type type)
{
ConstructorInfo constructor = ioc.GetConstructor(type);
IEnumerable<object> constructorParameterValues = ioc.GetParameters(constructor);
constructor.Invoke(constructorParameterValues.ToArray());
}
To decide which constructor to use:
private static ConstructorInfo GetConstructor(this SimpleIoc ioc, Type type)
{
ConstructorInfo[] constructors = type.GetConstructors();
ConstructorInfo constructorToUse;
if (constructorInfo.Length > 1)
{
// Decide which constructor to use; not explained here
// use Attribute like SimpleIoc.GetInstance?
// other method: use SimpleIoc.IsRegistered to check which Parameters
// are registered: use ConstructorInfo.GetParameters()
constructorToUse =
}
else
constructorToUse = constructoInfo[0];
return constructorToUse;
}
To get the values of the parameters in the constructor, we need to decide whether we want existing values from Ioc, or create new values:
public static IEnumerable<object> GetParameterValues(this simpleIoc ioc,
ConstructorInfo constructor)
{
IEnumerable<Type> parameterTypes = contructor.GetParameters()
.Select(parameter => parameter.ParameterType);
return ioc.GetInstances(parameterTypes);
}
public static IEnumerable<object> GetInstances(this SimpleIoc ioc,
IEnumerable<Type> types)
{
// TODO: decide if we want an existing instance from ioc,
// or a new one
// use existing instance:
return types.Select(type => ioc.GetInstance(type));
// or create a new instance:
return types.Select(type => ioc.CreateInstance(type));
}
This seems like a lot of code, but most of it is comment and most methods are one liners.