I'm building a custom ASP.NET Membership provider since I'd like to use my own 'User' table for creating members and that kind of stuff. Here's the situation:
I've got a MVC 4 project that refers to a 'Services' project containing the service layer.
I built a wrapper around the custom MembershipProvider which helps unit testing. This wrapper references the custom MembershipProvider.
I reference the wrapper from my service layer.
I placed the custom MembershipProvider inside the MVC4 project (in the App_Data folder) because that's required as far as I know... At least: Visual Studio whines that it can't find the membership provider if I put it elsewhere.
So now I've got a circular dependency: MVC4 -> Service Layer -> Wrapper -> MVC4. My question: how do I get rid of that? Ideally I'd like to place the membership provider in a separate project, but I just don't get that to work. Any suggestions about that? Google isn't really helpful I'm afraid.
Bonus question 1: Should I extend SqlMembershipProvider instead of MembershipProvider?
Bonus question 2: Is there no better option? This whole ASP.NET membership feels really outdated and has many downsides imho (for instance: it isn't built to be testable).
You can absolutely put your custom membership provider in another project. I have two that I built as separate DLLs, and then added a reference in the web project.
You don't mention why you added a reference in your service layer, but if this is necessary you should really treat them as two different scopes, and therefore requiring two separate solutions. I have one membership provider that required calling a WCF service to authenticate membership, but those are two seperate pieces and you should not be sharing code between the two.
You do not need to place your code in the App_Data folder, just add a reference to your Membership Provider project or DLL in the web site project. Right
Bonus Question 1: No.
Bonus Question 2: The membership providers pre-date the whole TDD movement (as far as Microsoft is concerned), so yes, they are not real conducive to testing. But, if you inherit from the base classes, you are hooking into a well tested and time-worn framework, so you really only need to test your custom bits.
Related
I wanted to build a VB.net web application using MS Visual Studio 2015. Someone suggested me to create a Web API instead of MVC project if i'm also planning to create a mobile app later on. I may use angularjs in my project so controllers will surely be used, so what should i choose when creating the project in the first place?
Because when i created a web project: File=>New Project=>ASP.net Web Application=>Empty..there are no folders for Controllers, Model, etc. Do i have to create a Controller folder on my own?
Or should i do this: File=>New Project=>ASP.net Web Application=>Web API..? sorry if its a silly question. its just that i'm afraid that if i chose the wrong project now, it'll affect the development later on.
Answer to your question mainly depends on your choice and needs,
for example
In Case of an empty project as name defines you will have nothing else web.config.
Benefits of it:
here you can define, design your own structure. you can either make
it simple 3 tier or you can make it WEBAPI application. it's all up
to you.
however in the case of choosing Webapi template you will have a prebuilt structure which can help you out for initial understanding
https://docs.asp.net/en/latest/tutorials/first-web-api.html
benefits of it
You will get predefine template and structure.
you can utilize of webapi's which further isolate you backend logic from the frontend.
as you are also planning to create the mobile app. and using front end as angular, so in that case, webapi may come handy.
as the whole world is moving towards webapi, so i will recommend you to use it. please refer https://blogs.msdn.microsoft.com/martinkearn/2015/01/05/introduction-to-rest-and-net-web-api/
so down the line it all depend on you if you want to build you application for the stretch and take full control of it regarding structuring backend etc.. then go with empty else go with Microsoft pre-define template
Thanks,
Ajay Kotnala
Does SimpleMembershipProvider use ApplicationName in anyway? I don't see any tables that will help it link in the documentation. I don't see any tables generated or linked in the actual source code itself,
GitHub - ASP-NET-MVC/aspnetwebstack
But isn't membership inherently bound to an ApplicationName? Or is there any workaround I can use to get this associated with. Basically I have an application and an admin portal, I want to use the same tables, but use different applications to identify different users and roles.
Thanks,
Fahad
You can use custom UserProfile table for storing such information. There is a very good information on asp.net blog: Customize the SimpleMembership in ASP.NET MVC 4.0
You may also consider migrate your project to MVC 5 and use OWIN authentication
No they moved away from the idea of partitioning users by ApplicationName (it seems a strange use case).
The preferred way would now be to just specify different connection strings and use separate databases (this assumes you have multiple apps).
If you want to partition users within a single application, you would ideally have 2 providers and direct calls accordingly, but SimpleMembershipProvider doesn't support non-default providers so you can only use one. You can overcome this, take a look at BetterMembership.Net, this supports multiple instances of SimpleMembershipProvider from a single application.
I understand the whole membership approach is supposed to be easier in MVC 4.
However, this is proving to be very time consuming in getting this to work.
Case in point: The example at http://blog.longle.net/2012/09/25/seeding-users-and-roles-with-mvc4-simplemembershipprovider-simpleroleprovider-ef5-codefirst-and-custom-user-properties/ shows a modification to the System.Web section of the web.config, namely that one adds the WebMatrix type to the roleManager section. However, I have no role manager section in my web.config. This is a fresh project.
What did I miss along the way?
Second, what I ultimately want to do is hook up SimpleMembership to my MVC 4 project, and have custom profile fields. And I need to do this against MySQL. I've read that the universal data providers allow for this, but does anyone have one simple, single tutorial on how to do this?
I really do hope that things really are more "simple" in MVC 4 than they were in MCV 3.
SimpleMembership provider won't work with MySql - have to extend the ExtendedMembershipProvider and implement the methods, etc... to work with mysql/EF.
I use ASP.NET MVC 3 for an application which makes heavy use or Users and Roles.
To create a user and assign role(s) I use the standard process via ASP.NET Membership.
Throughout the entire app I use NHibernate for the underlying data access except the places were the default MembershipProvider and RoleProvider implementations are used (inside the AccountController which delegates calls to those implementations).
I would like to use NHibernate in order to be able to read/edit/modify the values on that tables which are managed by ASP.NET Membership.
I found two solutions:
Write a custom NHibernate implementation for MembershipProvider and RoleProvider (or even use this one). That's the hardest path.
Map only the tables (as described here) and then use NHibernate directly (although any default actions from AccountController will still handled by the default providers).
Any suggestions/recommendations?
I've used the custom provider you link with pretty good success. I did make a few changes to it, so that it would use a single session for its lifetime.
If you want to use ASP.net membership I think that approach is your best bet, mainly for portability (it doesn't rely on any SP's being present in your database). I'm currently using the modified provider from that link against MSSQL and Postgres with no problems, and I've used it against MySQL as well.
I have been building web sites with ASP.NET for a while now. At first I avoided learning the intricacies of the ASP.NET Provider Model. Instead I used the canned providers where necessary, and leaned heavily on Dependency Injection frameworks for all my other needs.
Recently however, I have been writing pluggable components for ASP.NET and of course writing lots of custom provider based solutions in order to make that happen. It has become quickly apparent to me however, that a lot of initialization code is being duplicated, which is a bad thing.
So...
Are there any best practices that have emerged on how to avoid the configuration spaghetti code?
Have you built, or have any examples (base/helper classes, custom attributes, reflection) to share of abstracting the basic initialization code out so building custom providers is easier?
NOTE:
Please do not try and send me to the Provider Toolkit site. I have already exhausted that resource, which is why I am turning to the SO Community :)
I just did a rough implementation of rather basic implementation of the membership and role providers, and I don't have any code duplication at all!
I have divided everything into three projects (plus tests):
Application - asp.net mvc app. models, controllers etc.
Infrastructure - IoC and Interfaces
Infrastructure.Web - Providers
The model for User and Role implement interfaces from Infrastructure and those classes get registered to the IoC on application startup. The providers then asks the IoC to resolve the classes and does it's thing. This way I can add things to the model and user interface yet using the same providers. The one problem I've noticed, is that the web being launched by the "ASP.NET Configuration"-button can't use the providers, as the setup is being done in Application_Start and the "ASP.NET Configuration" is another web. I don't see this as a problem though.