In Using StructureMap 2.5 to scan all assemblies in a folder, we can see that StructureMap uses AssembliesFromPath() to explicitly look for types to resolve. What is the equivalent of this in Microsoft Unity? Because Unity is such a generic term, searching for documents about this online is not that easy.
Update: Unity has something called an Assembly Matching Rule but its description does not communicate to me that it scans folders.
The Assembly Matching Rule is used for applying interception to classes constructed by Unity and not for container registration. Unity itself does not have any convention-based scanning functionality like StructureMap. There is a CodePlex project that adds similar functionality to Unity though. http://autoregistration.codeplex.com/
Registration by Convention was added in Unity 3.0. Nice examples of this feature are provided in "Developer's Guide to Dependency Injection Using Unity" in solution in samples named OtherUnitySamples. You can find the book here:
http://msdn.microsoft.com/en-us/library/dn178463(v=pandp.30).aspx
and code samples here:
unity.codeplex.com/downloads/get/683531
Related
I'm a little confused as to what integrated options I have for DI. I see it's pretty straightforward for .net core (for my particular projects), but I don't need to build a cross platform app and don't see the advantage to using core. However, it doesn't look like .net framework applications are still setup with Global.asax and without Startup.cs so does that mean there is no integrated DI option for .net framework 4.7? Do I still need to get a 3rd party solution or is there a way to use the same DI workflow in a .net framework project as is used in a core project?
Dependency Injection is not integrated by default in classic asp.net, you need to add a nuget package to handle DI (only integrated by default in asp.net core).
EDIT: Even though I found out how to do it as explained below, I still ended up going with Autofac because I didn't realize the Microsoft's solution only supports constructor injection, but not property injection.
I found instructions on how to do it here. I know link answers are bad, but I don't have time to do any more than this. If someone else wants to make an answer with full instructions I will mark it.
https://scottdorman.blog/2016/03/17/integrating-asp-net-core-dependency-injection-in-mvc-4/
Also note that if you are not using Owin already, it is not required. You can set it up just the same in Application_Start method of Global.asax. Only change you would need to make is when it references the Startup class in a statement that reflectively gets all the Controller classes, you will need to change that to be the class the code is in (or any other class in your assembly).
Heading for alternative using for prism and di/ioc. mef is skilful framework for prism but not so fast. trying to use autofac for prism because our application infrastructure have to many presentation layer like a web, mobile, tablet(silverlight) and desktop(wpf). mef is not good idea for web(if there is no pluggin operation etc. requirements)
tried mef and autofac together. used aggregate catalog and exposed parts to autofac but it's a not complatetly solution. there is to many problems to be solved. using are together.(prism, prism.mefextensions, prism.autofacextensions and autofac's mefintegration)
using prism.autofacextensions for alternating mef but autofac is not ready to prism i think. tried some alternative projects but not ready. also autofac is not inject import attributed object automatically and not have a scanning tool for directory(export attribute scanner. it's must be coded.) and all prism extensibility must be declared. i think its not ready to use for prism.
is there a any alternative ready to use for prism framework? we must use ioc container for all presentation layers. whats best solution?
Based on my understanding, Unity container supports all the layers you mentioned of ASP.NET Web API, Windows Phone 8, Silverlight and WPF.
In addition, Bootstrapper implementation and any other feature related to PRISM becomes relatively simple to achieve as PRISM already includes the UnityBootstrapper class which implement most of the required functionality.
You can find helpful information for Unity container in the following CodePlex Unity site:
Microsoft Unity Container 3
I hope this helps.
I am working in Visual Studio 2013 RC and am testing Forms Authentication using new Microsoft.AspNet.Identity.* packages.
I would to integrate these concepts (Users, Roles, etc, etc) but want to use my own domain models (POCOs) which are in different assembly. I also don't want to create a dependency on Microsoft.AspNet.Identity.* dlls.
Is that even possible?
I found this article which says it is not, but the article is written based on Preview not RC versions of identity packages.
I have updated my sample project which you can find here: Identity RC1 sample
It now implements an entity framework model, it still require a reference to the Microsoft.AspNet.Identity.EntityFramework as I didn't want to reimplement all the Store classes also. But the sample shows how you can use your own POCO classes for the model.
If you want to completely remove the dependency on Microsoft.AspNet.Identity.EntityFramework from your model assembly you need to implement an class implementing the IIdentityStore interface which has properties of the following interfaces:
IUserLoginStore
IRoleStore
IUserSecretStore
ITokenStore
IUserClaimStore
IUserManagementStore
IUserStore
The IIdentityStore class should be in an assembly separate from your model assembly, with a reference to your model assembly. The IIdentityStore assembly would be dependent on ASP.Net Identity core.
Your custom implementation of IIdentityStore would need to somwhow be able to convert to and from your POCO classes to ASP.Net Identity interfaces such as IUser, IUserSecret etc.
Seems to me to be a lot of work for little gain, if you are using EF for your stores anyway.
Taking a dependency on the AspNet.Identity.Core assembly and have some of your POCO classes implementing one tiny interface each, seems a lot simpler to me.
Yes this is a fully supported scenario, basically you will want to use exclude using the Microsoft.AspNet.Identity.EntityFramework dll which has the default EF implementation, but you should be able to reuse the Manager classes and just implement your own custom Stores using your own POCOs which the manager will use just fine via the interface. For RTM its been streamlined and simplified a bit more, I believe the RC version was not quite as streamlined yet.
Updated You can get early access to the RTM bits here: MyGet
Just in case. Maybe I can help someone.
exorcising entity framework from asp.net.Identity
I'd created separate project(class library), then add ref to asp.identity.core,
then I'd implemented my UserStore class there, and feed it my Identity config in Web project.
It works fine in project with complex n-tier architecture.
I am converting a .NET 2.0 Winforms applications to ASP.NET MVC3. The Winforms solution uses several projects for business logic, and the MVC application includes these projects. The projects are also used by a variety of Windows console applications.
The problem is that these projects use System.Windows.Forms.Application.StartupPath to find files they use, whereas for web development System.Web.HttpRunTime.AppDomainAppPath is used.
I would prefer that both solutions use the same projects and that these projects are modified as little as possible as they are large, old, and relatively undocumented. What is the correct way to address this issue?
Right now I am thinking that I would create a new configuration with each project that would define WEB, and then use #if/#else statements to include the correct depedency and to define the return of the getPath() method.
Before you start plaguing your code with preprocessors, you should consider creating an interface IApplicationConfigurator or IApplicationStarter
public interface IApplicationStarter
{
string GetPath();
}
And inject it with a MvcApplicationStarter or a WinformsApplicationStarter depending on your application. You can then have your project libraries have a dependency on the IApplicationStarter interface. It should require minimal implementation on the projects, and you can reuse the pattern for other common dependencies. Look into dependency injection frameworks as it takes this approach into the next level.
This is what class libraries are for. Create a class library project, move all the common bits there, and then have a separate WinForms and MVC project that both reference your class library.
I'll try to explain in the simple way.
I have a solution (c# 4.0) that contain 4 projects
Framework
DAL
Domain
WebApplication
So my question is:
Framework is the right place to configure my Unity IoC? I want to configure via code and not with xml, so Framework need to know reference of DAL but DAL already knows Framework.
All my projects will know Framework, so where i configure my IoC?
Applications should be configured in the Composition Root, which is as close to the entry point as possible. In your case, that would be the WebApplication. That's the only project which should have a reference to Unity. None of the other projects should have any reference to Unity at all.
In the composition root, you should follow the Register Resolve Release pattern.
See also this answer - it talks about Ninject instead of Unity, but the concept (and hence the answer) is the same.