In NopCommerece MVC version, I am trying to move the mapping folder out of the DAL project to a seperate class library project, I am trying it to make the DAL more generic, so that it can be used in other projects as well.
But when I run the application, for every entity it says that "The entity type [EntityName] is not part of the model for the current context."
I think its happening because autofac is not finding IRepository for injection, any tips or ideas that where and what I am doing wrong?
Thanks in advance
OK! I found the solution to this issue, in the ObjectContext file, there is an overridden method named OnModelCreating, which was basically creating instances of mapping type objects in the assembly through reflection.
I have asked this method to look into a specific dll for those mapping entries and it started working.
Related
We have many projects based on the provider model/pattern. (Reading files from various sources, create reports from various sources, etc.) I have been unable to find anything equivalent to the ProviderBase in .net 5. We need an abstract interface/class that can be configured at runtime.
I suspect ProviderBase is something we will never see in ASP.NET 5 and beyond. Configuration is simpler in 5, and dependency injection is prevalent. Now you can create a class implementing your own custom interface and not have forced inheritance from ProviderBase. You can register the class or an instance of the class with a container and it will appear throughout the application. It might look like a bit more work at first, but I also suspect embracing DI will result in less code, and simpler code.
I have a BLL (Bussiness Logic Layer) project which is added in the main project with some structure (View-Controller-Model).
Do I have some way to accesss them from BLL?
I solved at the moment using reflection and passing the model to the entity, which I will work
I have been playing around the last couple of days with different solutions for mapping DTO's to entities for a VS2013, EF6, WCF Service App project.
It is a fairly large project that is currently undergoing a major refactoring to bring the legacy code under test (as well as port the ORM from OpenAccess to EF6).
To be honest I had never used AutoMapper before but what I saw I really liked so I set out to test it out in a demo app and to be honest I am a bit ashamed that I have been unable to achieve a working solution after hours of tinkering and Googling. Here is a breakdown of the project:
WCF Service Application template based project (.svc file w/code behind).
Using Unity 3.x for my IoC container and thus creating my own ServiceHostFactory inheriting from UnityServiceHostFactory.
Using current AutoMapper nuget package.
DTO's and DAL are in two separate libraries as expected, both of which are referenced by the service app project.
My goal is simple (I think): Wire up and create all of my maps in my composition root and inject the necessary objects (using my DI container) into the class that has domain knowledge of the DTO's and a reference to my DAL library. Anyone that needs a transformation would therefore only need to reference the transformation library.
The problem: Well, there are a couple of them...
1) I cannot find a working example of AutoMapper in Unity anywhere. The code snippet that is referenced many times across the web for registering AutoMapper in Unity (see below) references a Configuration class that doesn't seem to exist anymore and I cannot find any documentation on its deprecation:
container.RegisterType<AutoMapper.Configuration, AutoMapper.Configuration>(new PerThreadLifetimeManager(), new InjectionConstructor(typeof(ITypeMapFactory),
AutoMapper.Mappers.MapperRegistry.AllMappers())).RegisterType<ITypeMapFactory,
TypeMapFactoy>().RegisterType<IConfiguration, AutoMapper.Configuration>().RegisterType<IConfigurationProvider,
AutoMapper.Configuration>().RegisterType<IMappingEngine, MappingEngine>();
2) Where to create the maps themselves... I would assuming that I could perform this operation right in my ServiceHostFactory but is that the correct place? There is a Bootstrapper project out there but I have not gone down that road (yet) and would like to avoid it if possible.
3) Other than the obviously necessary reference to AutoMapper in the DTO lib, what would I be injecting into the instantition, the configuration object (assuming IConfiguration or IConfigurationProvider) and which class I am injecting into the constructor of the WCF service to gain access to the necessary object.
I know #3 is a little vague but since I cannot get AutoMapper bound in my Unity container, I cannot test/trial/error to figure out the other issues.
Any pointers would be greatly appreciated.
UPDATE
So I now have a working solution that is testing correctly but would still like to get confirmation that I am following any established best practices.
First off, the Unity container registration for AutoMapper (as of 11/13/2013) v3.x looks like this:
container
.RegisterType<ConfigurationStore, ConfigurationStore>
(
new ContainerControlledLifetimeManager()
, new InjectionConstructor(typeof(ITypeMapFactory)
, MapperRegistry.AllMappers())
)
.RegisterType<IConfigurationProvider, ConfigurationStore>()
.RegisterType<IConfiguration, ConfigurationStore>()
.RegisterType<IMappingEngine, MappingEngine>()
.RegisterType<ITypeMapFactory, TypeMapFactory>();
Right after all of my container registrations, I created and am calling a RegisterMaps() method inside of ConfigureContainer(). I created a test mapping that does both an auto mapping for like named properties as well as a custom mapping. I did this in my demo app for two reasons primarily:
I don't yet know AutoMapper in a WCF app hosted in IIS and injected with Unity well enough to fully understand its behavior. I do not seem to have to inject any kind of configuration object into my library that does the transformations and I am still reading through the source to understand its implementation.
As I understand it, there is a caching mechanism at play here and that if a mapping is not found in cache that it will create it on the fly. While this is great in theory, the only way I could then test my mappings that were occurring in my composition root was to do some sort of custom mapping and then call Mapper.Map in the library that performs mapping and returns the DTO.
All of that blathering aside, here is what I was able to accomplish.
WCF Service App (composition root) injects all of the necessary objects including my DtoConversionMapper instance.
The project is made up of the WCF Service App (comp root), DtoLib, DalLib, ContractsLib (interfaces).
In my ServiceFactoryHost I am able to create mappings, including custom mappings (i.e. map unlike named properties between my DTO and EF 6 entity).
The DtoConversionMapper class lives in the DtoLib library and looks like this: IExampleDto GetExampleDto(ExampleEntity entity);
Any library with a reference to the DtoLib can convert back and forth, including the Service App where the vast majority of these calls will take place.
Any guiding advice would be greatly appreciated but I do have a working demo now that I can test things out with while I work through this large refactoring.
Final Update
I changed the demo project just a little by adding another library (MappingLib) and moved all of my DTO conversions and mappings to it in a static method. While I still call the static method in my composition root after the Unity container is initialized, this gives me the added flexibility of being able to call that same map creation method in my NUnit unit test libraries, effectively eliminating any duplication of code surrounding auto mapper and makes it very testable.
I'm creating a custom Workflow activity for use within TFS2010. In the same assembly I have a XAML activity and a C# code activity. The XAML activity references the code activity.
When the assembly is deployed to our clients, I only want them to be able to use the Workflow activity. The code activity is of little use by itself and would no doubt confuse them.
I thought the logical way to do this would be to set the code activity class to internal: the XAML is in the same assembly and should be able to access it. However, when I do that I get an error in the XAML saying that the type can't be found in the assembly.
Is there a way to make activities internal/hidden?
This is a common problem with XAML in all its forms. It's caused by the fact (mentioned in one of the comments) that the parser isn't in the same assembly, so has no access to internals of your assembly.
The work-around that I've seen most frequently is just to separate out what you'd like to have as internal into its own namespace. At least then your consumers aren't typically bothered by confusing types that they don't need to use. In WPF this namespace is usually the main namespace with ".Primitives" appended to it. e.g. System.Windows.Controls.Primitives.
Another tack that you could investigate is using a custom NativeActivity rather than a XAML one. Presumably this could use internal classes, since the XAML parser isn't involved. I've not tested this out though.
I needed a way to trim strings within my persistent class because my legacy database is using char fields. I downloaded the nHhaddIns dll to use its TrimString class which is derived from IUserType.
Using their example I created a property in my mapping class as shown at the bottom.
uNHAddIns is added as a project within my solution. However, I received this error:"Could not determine type for: uNhAddIns.UserTypes.TrimString, uNhAddIns, for columns: NHibernate.Mapping.Column(HSTAT)"
I tried running the example that is in the uNhAddIns project and receive the same error. Any ideas?
<property name="HSTAT" column="HSTAT" type="uNhAddIns.UserTypes.TrimString, uNhAddIns" />
Don't know if you've managed to fix this already, but does your own uNhAddIns.UserTypes.TrimString inherit from IUserType? My own pattern for user types in NHibernate involves the type implementation living in the DataModel, and the required IUserType interface living separately in my DataAccess layer. The IUserType implementation does the necessary marshalling between the database and my DataModel type implementation.
I just came across this same error when trying to use the DataModel class in my mapping file rather than the IUserType implementation.