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.
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).
This is really a question about what would be a recommended pattern...
I use ASP.NET Core 2.0 and use dependency injection to allow my controllers and other classes to have access to a IMyDatabaseRepositor, via class constructors.
I also have several other projects in separate assemblies. I was thinking of allowing these other projects do some repository work as well. We're really talking about providing access to an existing DbContext.
Should I somehow pass the IMyDatabaseRepository instance to methods in the other project classes, or should those classes simply instantiate their own IMyDatabaseRepository (and do all their own "Startup" and connection string stuff for database and DI)?
I'm not sure if the other project classes can use the IServicesCollection somehow as well in order to get DI instances from my main ASP.NET Core web app.
Any thoughts?
Libraries should not compose object graphs, only the startup project should.
This means that in the library you simply use Constructor Injection, while in your Startup class you register all components from all libraries.
I haven't followed the ASP.NET MVC evolution since version 3 or so. Back then in MVC3 the simplest/preferred way to boost entity metadata info for the MVC DisplayNameFor etc magic was to use DataAnnotations. With the possible use of the [MetadataType] attribute if the classes were code generated.
I am wondering if this is still the preferred approach in MVC 5 (reading through what's news for V4 and V5 did not reveal any specific) or there are now some more customizable (built in) metadata engines around.
The genuine problem of mine is how to annotate entity classes in a different assembly. My project is built on a way where EDMX files and thus entity classes are living in a separate assembly (reused by the Web, PowerShell, etc modules of the project)
For the most, yes, data annotations are still the way to go, but since you're dealing with third-party classes, your best bet is looking into the nuget package, FluentValidation. It allows you to configure validation on your class properties via a code-based API, instead of having to directly add annotations.
I want to create a class library for an MVC 4 web application. Every search I've tried has returned plenty of references that merely mention creating one, or the importance of doing so, but not specifics of how.
My first assumption was a template would be under Web in the Visual Studio New Project dialog, but no. I was unsure if I was to use the Class Library template under Windows, but did.
I want to include things like some data access (e.g., DbContext), but while Intellisense sees the System.Data.Entity namespace, there are no classes available. I guess I need some additional references, but no idea which ones. Looking at the references in my main MVC project, at lot of them are pointing to the Packages folder. I'm unsure if I should be doing the same.
In short, I'm looking for instructions on how to create a class library for MVC in Visual Studio, including the necessary references for EF, Razor and whatever else.
you used the correct template - a simple class library is all you need.
then in the MVC web project just add a reference to the class library project
Use NuGet to add references to the pieces of functionality, like EF and System.Web.MVC, that you need in your class library or libraries.
A data access project to handle persistence and a class library to hold HTML Helpers that you might want to reuse both make some sense. Razor views if you're using the RazorEngine rendering stack can also be interesting to be able to test.
You are right to use the Class Library template in visual studio for your needs. You can add all of the references you need through NuGet (such as Razor, EF, and so on) and by Right clicking on references in the Solution Explorer and picking and choosing what you need.
Remember when using multiple projects that you add references between projects too! (for example your Web App project needs to know about your Data Repository Project)
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.