I've started an ASP.NET Web App project using the template for an Azure Mobile Service and tried to create my model the Model-First approach.
After generating my database from my finished model I proceeded to add a TableController class for one of my entities to test my project.
But when I tried to make a POST request I got this message:
Model compatibility cannot be checked because the DbContext instance
was not created using Code First patterns. DbContext instances created
from an ObjectContext or using an EDMX file cannot be checked for
compatibility.","exceptionType":"System.NotSupportedException
Is it not possible to create an Azure Mobile Service with Model-First at all? What are my options if I want to use the Model-First approach?
If it's not an existing model, I would switch to Code First. It is possible to use Model First, but it requires more manual configuration.
If you have an existing model, see this tutorial on how to add the right system properties and map to data transfer objects: http://azure.microsoft.com/en-us/documentation/articles/mobile-services-dotnet-backend-use-existing-sql-database/
Related
I have generated a dotnet core project with the command “dotnet new angular …”. With individual account authentication option.
The dotnet core has generated a project with application data context like the following.
public class ApplicationDbContext : ApiAuthorizationDbContext<ApplicationUser>
{
public ApplicationDbContext(
DbContextOptions<ApplicationDbContext> options,
IOptions<OperationalStoreOptions> operationalStoreOptions) : base(options, operationalStoreOptions)
{
}
}
I would like to integrated the identity server 4 into the same project and be served on the same instance of the api controllers. I have followed a guide linked below to store the configuration and operational store in the ef database.
http://docs.identityserver.io/en/latest/reference/ef.html
I have found out, that the DeviceCodes and Persisted Grant table are already in place in the database. while I tried to migrate the database to meet the requirements of the Operational Store.
I have looked into the ef source code, that the ApiAuthorizationDbContext class has already included the these tables to support Identity Server.
Now I am not quite sure which is the best solution
(1) Should I switch the ApplicationDbContext to extend the IdentityDbContext instead of ApiAuthorizationDbContext and use completely the way described in the guide above?
(2) Or should I skip the steps related to the OperationalStore DbContext and let the identity server 4 use the existing tables provisioned by the ApiAuthorizationDbContext? And how can I put them together?
What is the best practice? Thank you very much in advance.
In my application I took the source-code for the IdentitServer4 entitframework core NuGet packages and added them to my IdentityServer project (in a separate class library).
By doing this I get in control of how it is implemented and also how/when apply the migrations. This makes it it easier to customize it as you like.
Then having separate contexts for IdentityServer and your application needs also gives you good separation of concerns.
I have a Visual Studio Solution containing three projects. One is DAL (Data Access Layer) witch is using Entity Framework Core with one ApplicationDbContext.
I have referenced it in another (the second project) witch is a backend panel that users will be authenticated with active directory and users and roles will be managed with help of ASP.NET Identity.
I have created another ASP.NET Core project (the website - third project) which is for separation of the panel and the website. Here is also referenced DAL project.
I want to store users of the website in the same database as the project of the backend panel, but I want separate tables for backend users and website users.
In website project I have created another ApplicationDbContext and in OnModelCreating I have override the default name of Identity tables with different prefix than AspNet.
The database connection string is the same for both ApplicationDbContext. I have done Add-Migration Inital and then updated the database Update-Database. I get the new tables with the new prefix in the same database with those with AspNet prefix.
So far so good.
The problem that I face is that it is not straightforward to query the database with two different contexts.
So my question is: Is it possible to user ASP.NET Identity twice in the same database with the same context?
I am open to accept other solution to achieve what I need.
No. It is not possible to have two separate instances of Identity tables and classes in the same context. The way you're doing it with separate contexts is the best method. If you want to simplify access, I'd recommend creating one or more service-style classes that are injected with both contexts. Then, you can simply inject your service class into your application, instead, and work with just one thing via that. You'll of course need to write methods that interact with your two contexts as necessary, but that's work you'll just need to do once and then you can reap the benefits from there.
Bit of a noob question I'm afraid. I have an ASP.NET Core Web Application, which uses Individual User Account for authentication so it's brought in the Identity bits and created me migrations and an "ApplicationDbContext" for all of the user/roles stuff. I moved the Data related classes, migrations etc into a separate class project to separate it from the MVC project, but other than that it's out-of-the-box. All good. My DB has been created by migrations and I can register and login.
Now, I'm coming to build my app, and I'm not sure where is best to add my entities. The question is should I
1) Add my entities to the "ApplicationDbContext" which was created for me by Visual Studio?
2) Create a second DbContext instance in my Data project?
3) Something else?
I understand that if my app was to use separate databases for authentication and domain data then it would be a no brainer and option 2 would be the answer. But this app is very simple with one database, so I'm wondering if I may be able to get away with option 1.
The ApplicationDbContext that was created for me inherits from IdentityDbContext. I don't know if that has other implications if I were to go with option 1 and add my entities to ApplicationDbContext.
I did start down the road of option 2, but quickly found that things like Add-Migration wouldn't work when the project had 2 contexts. I found that the Add-Migration command now has a -context switch which can be used to tell the command which context to use, but I'm a bit concerned that I will run into other issues. Particularly I am going to be using VS Team Services to build and deploy the app to Azure using continuous deployment, and I don't know if those build and release features will cope with the multiple DB contexts.
Any advice from somebody in the know? This has got to be a pretty standard requirement, right?
Hence your app is very simple one,you can use ApplicationDbContext for your domain models as well.That means, I would like to recommend you to use single context class for your app.If you do so,you can easily manage your business requirements (i.e. any relations between your classes) with the users and Roles on the IdentityDbContext context.
I would like to ask you how can I implement DB First model in ASP.NET Identity Scheme. When I create a WebAPI project with individual user authentication I can see code-first model with some implementation in it. I am trying to solve this and I was searching for some solution but i didnt found it. Do you know about any good tutorials or just the solution? Thanks
Models need not be present always inside Model folder of web-api project.
They can be from other dlls as well.
I would suggest you to create a new project for your Data Access Layer, and add the EF databasefirst dbml to that project. Later refer it in your web-api project to use it.
For a business application, I am providing a base entity model. Thereafter the end user should be able to extend the model for his specific needs.
For the base model I want to use database-first approach. But I don't know how to accommodate for allowing user to extend it.
One part is to provide a UI for entity model editing and the other is to reflect the changes in the model and database thereafter. Please offer suggestions.
EDIT:
- Once the entity model is edited and saved, all EF facilities should work like before.
- Model update is conducted at the time of maintenance, i.e., it is not in use by business users.
- The affected project can be compiled and a new assembly can be produced and put to use.
It is not possible. When you modify entity model you must modify related entity classes (or create new ones) => you must recompile application or use some dynamic assemblies. Moreover there is no API to modify entity mapping at runtime so you are going to build new Entity designer.
It is generally same requirement as installing C# 2010 Express on client desktops and allowing them to modify, rebuild and redeploy your application.
Edit:
What you want requires:
Modifing EDMX - very complex XML file. Writing custom tool for that will be complex task. Moreover you will have to add logic wich will don't allow user to break the application.
Running T4 templates to generate new or modified entities.
Compiling application - what if user makes changes which break the build???
Redeploying DB - this itself is pretty bad taks because whole DB generation logic is Workflow running in Visual studio. Moreover you need another workflow which will be able to upgrade database - default one can only deploy new blank DB. Such workflow exists but it requires VS 2010 Premium or Ultimate.