problems registering types with structuremap for generic repository - entity-framework

My source is at https://github.com/tonyeung/generic-repo
I want to create a generic repository that I can reference in different projects. Most generic repository implementations that I've seen make that difficult. I stumbled across http://blog.damianbrady.com.au/2012/07/24/a-generic-repository-and-unit-of-work-implementation-for-entity-framework/ and found that it would work great for what I have in mind. Each of my projects can have a context defined in it, then I just need to reference a generic repository project or dll and pass in the context and I'm ready to go.
The only thing I'm trying to get my head around is how do I wire structuremap since there are a few nested dependencies that need to get resolved. Unfortunately, the blog doesn't really address how to implement dependency injection with the generic repository. I tried to tinker around with the implementation (see above referenced git hub repo), but I'm doing something wrong while configuring structure map.
The dependencies work out like this:
the repository takes a context in the constructor, and the context in turn gets a connection string. The constructor parameters are all interfaces which match the default convention of IType maps to Type. My assumption is that since I have auto registration, all I need to do is explicitly define the registration for the context to tell structuremap that it should get the connection string from the app.config, I should be good to go.
However, structuremap is not able to work out the registrations like I thought it would:
StructureMap Exception Code: 202
No Default Instance defined for PluginFamily Generic_Repository_Test.IGenericRepository`1
[[ViewModel.Customer, ViewModel, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null]],
Generic Repository Test, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"
The registration code
//This is commented out since it should not be necessary.
//I tried to put this in for grins
//and see if it would resolve the issue but it doesn't.
//For<IGenericRepository<Customer>>().Use<GenericRepository<CustomerContext, Customer>>();
For<ICustomerContext>()
.Use<CustomerContext>()
.Ctor<string>("connectionString")
.EqualToAppSetting("ConnectionString");
//I've tried moving scan to the top but it didn't make a difference
Scan(x =>
{
x.AssembliesFromApplicationBaseDirectory();
x.WithDefaultConventions();
});

The problem did in fact turn out to be a configuration issue.
The issue was that the app.settings connectionstring setting was returning null, I'm not sure why that happens but I hardcoded the connection string just for grins. Will figure that issue out later.
With that resolved, I still had to manually configure the repo and the context, since another error popped up.
With that resolved, it looks like structuremap was trying to resolve itself, so I had to add a namespace exclusion.
The completed code looks like this:
public class DependencyRegistry : Registry
{
public DependencyRegistry()
{
For<ICustomerContext>()
.Use<CustomerContext>()
.Ctor<string>("connectionString")
//.EqualToAppSetting("ConnectionString");
.Is(#"Data Source=(localdb)\Projects;Initial Catalog=EventStorage;Integrated Security=True;Connect Timeout=30;Encrypt=False;TrustServerCertificate=False");
For<IGenericRepository<Customer>>().Use<GenericRepository<ICustomerContext, Customer>>();
Scan(x =>
{
x.AssembliesFromApplicationBaseDirectory();
x.ExcludeNamespace("StructureMap");
x.WithDefaultConventions();
});
}
}

Related

Autofac RegisterAssemblyTypes tries to resolve all public types

Quick question: I've been using autofac with asp.net core in a project and I've noticed that it tries to resolve all types during configuration after updating it to the latest nuget package (going from Autofac.Extensions.DependencyInjection 5.0.1 to 7.0.2). Btw, here's the code that was being used to register the types:
builder.RegisterAssemblyTypes(typeof(Utilizador).Assembly)
.AsImplementedInterfaces()
.AsSelf();
Until now, I wasn't seeing this behavior. The problem with this new approach is that it will try to resolve types that will never be injected through DI. For instance, it complains about public classes that don't have public constructors event though those classes will never be created through DI.
Can someone point me to when this change happened?
Does this mean that now I must filter the types I need explicitly?
Thanks.
This is nothing new.
You can filter those out with something like below:
builder.RegisterAssemblyTypes(ThisAssembly)
.Where(type => type.GetConstructors(BindingFlags.Public).Any())
.AsImplementedInterfaces();

Resolve Views through IoC or MEF instead of using SelectedAssemblies() method

I use Caliburn.Micro with Spring.net instead of the default simple IoC. My custom Bootstrapper (derrived from Caliburn's BootstrapperBase) is working and I can define the ViewModels within Spring.net. But the the Views are still resolved by reflection (name convention) from the execution assembly. I used the following method of the Bootstrapper to add Assemblies for resolving the Views for the ViewModels.
protected override IEnumerable<Assembly> SelectAssemblies()
{
// hmm, want to change the way how the view is resolved... how to do this?
// ... use IoC or MEF for this task instead?
return new[]
{
// don't want to add every dll here
this.GetType().Assembly,
Assembly.Load("MyViewModels.Assembly")
};
}
How to change the behaviour of resolving views and using IoC or MEF for this task?
The Problem is that the Bootstrapper has no virtual method to override which resolves a requested view. What is the starting point to change this behaviour? I thought there must exist something like
protected virtual Control ResolveViewForModel(Type modelType) {...}
Thanks for any hints.
First of all, I don't know caliburn.micro so this might be wrong.
Looking at the ViewLocator method LocateTypeForModelType it seems that it asks the AssemblySource for available types which should be checked against the View-naming conventions.
Since all of the above are static classes I suspect there is no way to inherit and override that behaviour. Since they are static, one could just add assemblies to the public observable dictionary - which feels a little bit of a hack and SelectAssemblies seems like the proper way.
However, it seems to me that since there are conventions for resolving Views and ViewModels one could do the same for assemblies which brings us to the question: how do you decide which assemblies to scan for ViewModels/Views.
That strategy can be built into the SelectAssemblies method.
If you want to change how caliburn.micro finds the right views in those assemblies, effectively changing/adding to the exisiting conventions, there is an explanation in their wiki.
To finally answer your question: "Resolve Views through IoC or MEF instead of using SelectedAssemblies() method": Imo this kind of defeats the philosophy of Caliburn.Micro:
Caliburn.Micro uses conventions to resolve views from given assemblies - trying to use an IoC container instead of a name / namespace based convention contradicts that approach.

Sharprepository Autofac InstancePerApiRequest in Webapi environment not working

Does anyone have a working example of sharprepository intergration with autofac using InstancePerApiRequest for DbContext?
I am registering my dbcontext thusly:
builder.RegisterType<AuditTestEntities>().As<DbContext>().InstancePerApiRequest();
If I remove the InstancePerApiRequest, sharprepository is able to get a dbcontext. But with the InstancePerApiRequest, I get the error message pasted below. Basically the crux of the error is, I suspect, the way sharprepository makes the call:
No scope with a Tag matching 'AutofacWebRequest' is visible from the scope in which the instance was requested. This generally indicates that a component registered as per-HTTP request is being requested by a SingleInstance() component (or a similar scenario.) Under the web integration always request dependencies from the DependencyResolver.Current or ILifetimeScopeProvider.RequestLifetime, never from the container itself.
The full error stack:
iisexpress.exe Error: 0 : Operation=DefaultHttpControllerActivator.Create, Exception=System.InvalidOperationException: An error occurred when trying to create a controller of type 'AccountController'. Make sure that the controller has a parameterless public constructor. ---> Autofac.Core.DependencyResolutionException: An exception was thrown while invoking the constructor 'Void .ctor()' on type 'AccountRepository'. ---> Could not resolve type 'System.Data.Entity.DbContext' using the 'AutofacDependencyResolver'. Make sure you have configured your Ioc container for this type. View the InnerException for more details. (See inner exception for details.) ---> SharpRepository.Repository.Ioc.RepositoryDependencyResolverException: Could not resolve type 'System.Data.Entity.DbContext' using the 'AutofacDependencyResolver'. Make sure you have configured your Ioc container for this type. View the InnerException for more details. ---> Autofac.Core.DependencyResolutionException: No scope with a Tag matching 'AutofacWebRequest' is visible from the scope in which the instance was requested. This generally indicates that a component registered as per-HTTP request is being requested by a SingleInstance() component (or a similar scenario.) Under the web integration always request dependencies from the DependencyResolver.Current or ILifetimeScopeProvider.RequestLifetime, never from the container itself.
Okay found the issue. There is a problem with using the SharpRepository AutofacDependencyResolver when using the MVC or Web API integration and trying to use the scope InstancePerApiRequest or InstancePerHttpRequest. Autofac expects those items to be resolved from the System.Web.DependencyResolver.Current instead of from the Autofac IContainer directly as the AutofacDependencyResolver is currently doing.
Here is how you can fix the issue right now until we make an overload for AutofacDependencyResolver that fixes the issue.
You will need to create your own dependency resolver within your project like this one:
public class CustomAutofacDependencyResolver : BaseRepositoryDependencyResolver
{
private readonly IDependencyResolver _resolver;
public CustomAutofacDependencyResolver(IDependencyResolver resolver)
{
_resolver = resolver;
}
protected override T ResolveInstance<T>()
{
return _resolver.GetService<T>();
}
protected override object ResolveInstance(Type type)
{
return _resolver.GetService(type);
}
}
And then register it with SharpRepository so it will use it to resolve the DbContext and then it will work as expected.
RepositoryDependencyResolver.SetDependencyResolver(new CustomAutofacDependencyResolver(DependencyResolver.Current));
** Update**
I was testing with MVC and able to replicate the error and fix it but that doesn't work with Web API. I am used to using StructureMap where it works fine using the GlobalConfiguration.Configuration.DependencyResolver.
It seems the issue is that Autofac needs a IDependencyScope that you can access from the HttpRequestMessage but I'm not seeing a way to get to that outside of the ApiController. This describes the issue and the reason: https://groups.google.com/forum/#!msg/autofac/b3HCmNE_S2M/oMmwFE5uD80J
Unfortunately right now I'm at a bit of a loss on the best way to handle this. But I'll keep thinking about it.
So, I was able to get mine working by changing the lifetime scope to InstancePerLifetimeScope. I don't know whether this has any unforeseen consequences or not. Everything appears to be working fine for me so far.

XmlSerializer can't find EntityObject even though its referenced

I hope that someone can help me with this problem that I've been having with XmlSerializer.
I've already looked through this thread: http://social.msdn.microsoft.com/Forums/en-US/asmxandxml/thread/551cee76-fd80-48f8-ac6b-5c22c234fecf/
The error I am getting is:
System.InvalidOperationException: Unable to generate a temporary class (result=1).
error CS0012: The type 'System.Data.Objects.DataClasses.EntityObject' is defined in an assembly that is not referenced. You must add a reference to assembly 'System.Data.Entity, Version=3.5.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'.
I've made sure that my unit test has a reference to System.Data.Entity, so it is able to compile at least. I've also in the app.config made an assembly binding to System.Data.Entity.
Here's my rough class structure
[Serializable]
[XmlRoot(Namespace = XmlSupport.MyNamespace, ElementName = XmlSupport.WantToSerialize)]
[XmlInclude(typeof(WantToSerializeBaseClass)]
[XmlInclude(typeof(EntityObject)]
[XmlInclude(typeof(MyEntityObjectSubClass)]
public class WantToSerialize : WantToSerializeBaseClass, IXmlSerializable (I've tried putting this on the baseclass and the current class)
{
// methods and classes
// I've included XmlIncludes for all the classes that this class has a reference too
// even though in the WriteXml it just uses .NET base classes
}
The WantToSerializeBaseClass makes use of some generics, but I've decorated it with XmlIncludes for (EntityObject, and any other classes it makes reference to as well).
the calling code:
var serializerWrite = new XmlSerializer(typeof (WantToSerialize), XmlSupport.ITNNamespace);
fails
However if I do:
var serializerWrite = new XmlSerializer(typeof (WantToSerialize), new Type[] {typeof(EntityObject)});
it is succesfull.
Any thoughts would be most helpful.
UPDATED
I've tracked the problem down to a method in the WantToSerializeBaseClass
public abstract void ConvertFromEntity<TtoCopy>(TtoCopy toCopy) where TtoCopy : MyEntityObjectSubClass;
Where MyEntityObjectSubClass is a subclass of EntityObject, that adds a few methods that I want on my entity objects. The MyEntityObjectSubClass looks like this:
[Serializable]
[XmlInclude(typeof(EntityObject))]
public abstract class MyEntityObjectSubClass : EntityObject, IMyEntityObjectSubClass
Again any thoughts would be great
If you don't have any code that requires a reference at compile time then that reference won't be included in the built assembly. You can use a tool like Reflector to check whether the reference is making it into your assembly.
One thing you can try is adding a static method to WantToSerialize that creates the XmlSerializer. The assembly containing WantToSerialize must already have a good reference to EntityObject, so this should solve the problem.
I have this same problem too (in VB). what I found is that you can use the generic parameter, but it errors because the type MyEntityObjectSubClass is in another assembly. If you remove the type restriction on the generic parameter it will work fine.
I believe this to be an error in the framework itself. I've submitted a feedback ticket to microsoft. I attached a VB.net
I ended up removing the generic code and it worked fine.
I realize this is an older question but for posterity's sake set the CopyLocal parameter on the .dll reference to True.

Windsor Container: How to specify a public property should not be filled by the container?

When Instantiating a class, Windsor by default treats all public properties of the class as optional dependencies and tries to satisfy them. In my case, this creates a rather complicated circular dependency which causes my application to hang.
How can I explicitly tell Castle Windsor that it should not be trying to satisfy a public property? I assume there must be an attribute to that extent. I can't find it however so please let me know the appropriate namespace/assembly.
If there is any way to do this without attributes (such as Xml Configuration or configuration via code) that would be preferable since the specific library where this is happening has to date not needed a dependency on castle.
You can use the Castle.Core.DoNotWireAttribute attribute to stop a property from being wired up by the IoC container (this is in the Castle.Core assembly, which means your library only needs to take a dependency on the lightweight Castle.Core assembly - if for example you want to use the code without an inversion of control container altogether, or in a different IoC container).
I don't believe there's any way to prevent wiring from occurring in the Xml configuration, but it would be reasonably easy to add support for this - if I had to do this I would probably:
Introduce some kind of attribute on the property declaration in the xml: <myprop wire="false" />
Inherit from PropertiesDependenciesModelInspector, overriding the InspectProperties method to apply some additional logic to identifying which properties should be added as dependencies to the components model (inspecting the model.Configuration for the wire="false" attribute/value pair).
Inherit from DefaultComponentModelBuilder and override the InitializeContributors to include your replacement PropertiesDependenciesModelInspector - or just remove the existing properties contributor and add your own at run time via the AddContributor/RemoveContributor methods.
Replace the ComponentModelBuilder service instance assigned to the kernel of your container.
Another approach which could work for you is to just manually remove the dependencies from the model before any instances of the service are requested ie.
kernel.GetHandler(typeof(MyComponent)).ComponentModel.Dependencies.RemoveAll(d => d.DependencyKey == "PropertyThatShouldNotBeWired");
YMMV with that approach though - especially if you have startable services or other facilities which may be eagerly instantiating your component after it's registered.
I created a facility to help with this:
Castle.Facilities.OptionalPropertyInjection
I do not know which version of Castle you guys were using at that time, but none of the solution mentioned were working. Plus, there is a lot of dead links.
With castle 3.1, here the solution I came up with (thanks to some castle source code digging):
container.Register(Component.For(type)
.LifestyleTransient()
.Properties( propertyInfo => propertyInfo.PropertyType != typeof(MyOtherType)));
The 'Properties' function adds a property filter used by castle when constructing the ComponentModel. In my case, all properties dependency will be satisfied except the property type 'MyOtherType'.
Maybe it will be helpful for someone. In Windsor 4.1 there is PropertiesIgnore method during registration.
Component.For<Role>().LifestyleTransient().PropertiesIgnore((model, propertyInfo) => true)
DoNotWireAttribute
Class: http://svn.castleproject.org:8080/svn/castle/trunk/Core/Castle.Core/Attributes/DoNotWireAttribute.cs
Test: http://svn.castleproject.org:8080/svn/castle/trunk/InversionOfControl/Castle.Windsor.Tests/IgnoreWireTestCase.cs
This can be achieved by the following code:
var container = new WindsorContainer();
// We don't want to inject properties, only ctors
var propInjector = container.Kernel.ComponentModelBuilder
.Contributors
.OfType<PropertiesDependenciesModelInspector>()
.Single();
container.Kernel.ComponentModelBuilder.RemoveContributor(propInjector);
Source Castle Windsor Documentation
Posted this on the google groups forum too here: http://groups.google.com/group/castle-project-devel/browse_thread/thread/43aa513817bd057a