My title is a bit complex, but I will break down really simply what I am doing here.
I have an existing database with about 20 tables. I have a project that my partner has decided that we should use the old Simple Membership over Identity. This is no longer an option on the table, we have finalized that decision. WE will be creating the project in Web Forms using Visual Studio 2012 because that is what we have licenses for.
Step 1) I started a new project in VS 2012 using Web Forms and I pointed the Default Connection String at my current database and registered a few users. This created the tables I needed for membership in my SQL Server 2012 database.
Step 2) I did some relational mapping in my database connecting existing tables to the new membership UserID's where needed so that my existing tables are now related to the membership stuff.
Step 3) Here is where I am a bit lost because normally I have used SqlDataSources with Web Forms in the past. I have some experience with MVC so I would like to do things differently in this web forms project and start from Database First and import my database tables into a Data Access Layer, I'm thinking of using a Class Library for this.
MY QUESTION: When importing my EDMX for database first. Should I
A) Bring in all of the tables (Existing Tables + New Membership Tables)
B) Just bring in the Tables that are NOT part of Membership?
C) Bring in my Existing Tables and only the User and Membership table? or
D) Do you have any other idea?
My reasoning for this question is that I know that I can access the Membership stuff in the Web Forms Project but will it possibly be needed in the Class Library since my application will eventually be very User centric. Lots of tracking of user time and logins, assigning tasks and projects, permissions to that user etc.. I was leaning toward (A)
I know this is a very complex question or maybe I should say it may have many answers all due to things that I may not know yet or I have not explained fully. But I'm looking for some direction as I have never used a Class Library or Database first in this way or in a Web Forms Application.
Snapshot of Database:
You really don't need to include the Membership tables in the EF model. As you pointed out, the Membership class will handle it as long as you have it properly configured in the Web.Config file.
You should import only those tables that are related to your application.
You would only import the membership tables only if you are building a custom membership provider, which is old news by now.
At least, I personally don't do it. This also helps to keep the EF model with just what I need.
Hope it helps.
Related
I am trying to update an older website. It already has an existing database with a user and a role table, with existing data in it.
I need to create a new web-api and a new web project and integrate ASP.NET Identity into the already existing database.
I have currently setup my solution to breakup the projects as follows:
Domain
Services
WEB_API
WEB_UI
My aim is to implement the Identity in the services layer so that both my WebAPI and MVC site can utilize the same identity mechanism.
I am fairly overwhelmed at the moment, I have read many tutorials and articles over the last day or two and have ended up with the options of either re-implementing the IUserStore and IRoleStore. And also with mapping the different entities in the OnModelCreatingMethod.
I cant seem to find a tutorial which is aimed at what I want to do. My database is to different to simply remap the names of columns, And I dont want to re-implement the entire Identity Stores as there are only a few conflicting fields. Most tuts I have found are related to using mysql instead of EF. I still want to make use Entity Framework.
Issues I have:
The current Users Table in the database used Int pk , not GUID
The Password Field uses a different Hashing algorithm. So i would need to override how Identity checks and store the password.
I do not have all the required Identity User fields in my database, however I am able to add new fields, I just cant change already existing fields.
I am making use of Database First as the DB already exists.
So basically my question is, In what direction do I need to go in order to overcome the above mentioned issues. Can I get away with changing the Database mapping? Or do I need to go as far as re implementing the User and Role Stores?
What I had initially planned was to re-implement the User and Role Stores using entity framework, And i could then make use if the DB first model classes and map the actual DB structure and fields to my ApplicationUser Fields. But this is where I thought I might be diving into cold waters, and i'm generally not a fan of reinventing the wheel if not necessary.
-The first thing you should do if you haven't already is to BACK-UP your current database!
You could use code first to update an existing database.
I found this walkthrough and it seemed close to the route you're on, and I'm hoping it will help solve your problem, begin at "Migrating to Visual Studio 2013".
http://www.asp.net/identity/overview/migrations/migrating-an-existing-website-from-sql-membership-to-aspnet-identity
This would create a few new tables, but not necessarily a new database.
Download Nuget packages:
Microsoft.AspNet.Identity.EntityFramework,
Microsoft.AspNet.Identity.Owin,
Microsoft.Owin.Host.SystemWeb
Enable-migrations and run a script such as this: https://aspnet.codeplex.com/SourceControl/latest#Samples/Identity/SQLMembership-Identity-OWIN/Migrations.sql
Or you could try using a reverse POCO generator found in visual studio extensions.
(My 1st attempt at writing an answer here. Tried to clarify.)
I have a Forms project that uses ASP.NET membership authentication to manage the users. I also have created model classes that use entity frameworks to populate a database. Currently, I have been planning on keeping the asp tables (membership and other records) in the same database as the tables containing the other application data.
When I run my program after changing some of the data model classes, entity frameworks recreates the entire database, and I've lost all my ASP.net tables.
What am I doing wrong here?
Without seeing, your code it is hard to say. Here is my wild guess.
You might have DropCreateDatabaseIfModelChanges. Basically, it drops the entire database when Code First classes change.
If so, you might want to replace it with NullDatabaseInitializer which prevents the schema from being altered.
I have an existing ASP.Net Web Forms application which is using EF Code First with Existing Database i.e. I am using EF classes and DbContext to point to an existing database.
I want to give the project the functionality to create/edit tables/fields and just wondering if people can recommend the best way to do this. I can't use migrations because the project is used on several different servers/databases.
I thought about putting something in the Global.asax file in Application_Start using SqlCommand. Is this a good idea or can you suggest a better way to do this, preferably with EF?
I'm not sure what if any code would be helpful so please let me know if there is anything you would like me to add to the question.
EDIT:
Based on answers so far felt I should also note that I cannot directly access the servers the application is installed on because they belong to clients. Project is deployed locally, zipped and uploaded onto a site for their download.
When using EF Code First, you should use EF Code First Migrations, although you say it's impossible.
Your only reason not to use this is the multiple database servers. Do you use Distributed Transactions?
Otherwise, the only variable is the ConnectionString to the database server, and EF Migrations will do all the work for you to update your SQL schema.
It's probably a bad idea to do this as part of application startup - it'll require that the user that your application connects to the database with has escalated privileges in order to create/edit tables.
You can use migrations to initialise a database as part of a deployment process using the migrate.exe which is part of the EF NuGet package.
It's probably also useful to read a bit more around migrations - there is support for multiple contexts that can each be migrated separately...
Alternatively you could use a SQL script as part of your deployment process but then you'd need to manage the SQL by hand...
I created a login system for one MVC App based on the new Identity framework, and since I already went through all the hard work of modifying my database to match the Identity 2.0 requirements, I was wondering if it would be possible to use it outside of MVC, so I could reuse what I already created, like a login system for a desktop project that I'm working on for example. If so, can I implement the login system on a .dll that can be reused on other projects?
Yes, you could use your existing database for another application. Add the ADO.NET Entity Data Model, and point it to your database. Then, if you need to, select "Update Model from Database" and you should be all set.
Although, it may be just as easy to create your own user/roles tables. It's frustrating (to me) that Identity creates the Primary keys as strings, even though they are essentially Guids.
We are developing an ASP.NET MVC Application that currently uses it's own database ApplicationData for the domain models and another one Membership for the user management / membership provider.
We do access restrictions using data-annotations in our controllers.
[Authorize(Roles = "administrators, managers")]
This worked great for simple use cases.
As we are scaling our application our customer wants to restrict specific users to access specific areas of our ApplicationData database.
Each of our products contains a foreign key referring to the region the product was assembled in.
A user story would be:
Users in the role NewYorkManagers should only be able to edit / see products that are assembled in New York.
We created a placeholder table UserRightsRegions that contains the UserId and the RegionId.
How can I link both the ApplicationData and the Membership databases in order to work properly / having cross-database-key-references? (Is something like this even possible?)
All help is more than appreciated!
In my opinion, you should be able to integrate your database with the standard aspnet_db reliably, but I would advise against duplicating or replacing the aspnet_users table.
That is the focal point of all the providers that use the aspnet_db schema, including custom providers that may augment but do not implement custom replacement.
To maximize reuse of strong tested infrastructure code in the provider stack/API it is best to go with that flow.
You will want to be very attentive to any modified membership core functions and ensure that the way your new constraints behave in an expected fashion in each case.
The facet of the membership story that I have found needs the most attention is deleting a user, and a simple modification/addition to the delete user sproc can manage this capably.
It sounds like you might need to create your own customized Membership Provider. You can probably (not positive here) extend the existing one so you don't have to completely reinvent it. Here is a video from ASP.net that describes how to do that. Google "asp.net membership provider" for tons more.
You can try rolling your own membership or just extend is like Dave suggests.
Create your own [Users] Table which can be populated based off the aspnet_Membership table. So therefore you could have more control over it.
You could also just implement a more involved Profiles system. The .NET team has improved the way profiles are stored now, so instead of "blobicizing" them, you can set them up to be stored in an actual table now [thank god].
Table Profile Provider
If you find the right articles, it's really easy to extend the membership provider to allow for extra functionality. I've moved my users table to my main SQL server table and have written my own role manager that gets values from a separate table. What it sounds like you need to do is to set up a table in your users DB with the location of each user, then create a method on the user object something like "GetLocation()" that returns the user's location from the DB, you could then user that to filter your data from your main DB. Here's a few articles I had kicking aroundin my bookmarks, see if they help, if you have a look on the main ASP.NET site or google for membership provider extending articles, there are plenty around.
http://msdn.microsoft.com/en-us/library/ms998347.aspx
https://web.archive.org/web/20211020202857/http://www.4guysfromrolla.com/articles/120705-1.aspx
http://msdn.microsoft.com/en-us/library/aa479048.aspx
As the others have pointed out there are many good resources available that can help you with creating your custom provider using the existing database.
It looks like you are headed in the right direction with mapping tables. I think the one piece you are missing is Distributed Queries. This link is specific to Sql Server 2008. There is a link there to the documentation for Sql Server 2005 if that is what you are using.