I have downloaded the samples from the IdentityServer3 github repo and ran the MembershipReboot project, I changed the connection string to point to a real server but I still don't see how to get it create the database, I thought this used EF code first to do this. I just feel lost right now trying to understand how to use IdMgr and IdSvr.
You were right, The IDS MembershipReboot project relies on MembershipReboot which in itself uses EF migration scripts to generate the database if it doesn't exist (or upgrade it if it's an old one).
But, note that you need the connection string to use a user with permissions to create the database and tables in it.
Also, as far as I can remember you need to actually hit the (IDS) server with a request to get things spin up and create the DB. Otherwise, IDS would not load anything from the IoC container and the DbContext would not get created. But this is something I cannot verify now.
The configuration database of IDS (scopes, clients, claims etc.) is stored in-memory in the MembershipReboot sample you are using. It could be stored in MSSQL using EF (or any other store if you care to implement it). You can see a working sample that uses EF and MSSQL in the EntityFramework sample project. I guess you can combine the two samples get what you are after.
Related
My company's main software application hasn't been updated in twenty years. I expect to soon be working on a complete rewrite of it. To that end, I am beginning to work my way through the book "Pro ASP.Net Core 3" by Adam Freeman (8th edition).
Our application was written to be independent of specific database types. Most of our customers use PostgreSQL, but a few use SQL Server. Therefore, we use ODBC because ODBC drivers exist for both of those databases, as well as several others. The application does not do anything fancy with the databases, and ODBC works well. We configure an ODBC DSN to talk to whichever database the customer has, and the application itself doesn't have to be changed.
A search on "Entity Framework Core ODBC" led me to the EF Core Github, where people have asked similar questions, and the answers were mostly along the lines of "why on earth would you want to do that?". Well, I need to do that.
Can I use EF Core with ODBC, or is there some other way that I can set up an Entity Framework Core application that does not have to be modified if the underlying database changes from PostgreSQL to SQL Server?
You could use your appsettings.json to store a value used to swap between the two. Those environment configs get reloaded on change (though you might have to restart your application to read them again, I'm not sure on that one).
Regardless something along the lines of this would suit your needs I think.
if (Configuration.GetSection("dbOptions")["postgres"]))
services.AddDbContext<ApplicationDbContext>(options => options.UseNpgsql(Configuration.GetConnectionString("PostgresConnectionString")));
else
services.AddDbContext<ApplicationDbContext>(options => options.UseSqlServer(Configuration.GetConnectionString("SqlServerConnectionString")));
EDIT: I placed this in Startup.cs where you would normally configure the DBContext. I use a similar solution reading off the Environment type to load either the Prod or QA connection strings based on deployment. In principle, this should accomplish the same task without the need for rebuilding and redeploying the code base.
Need help! I am new to Core 2.0 and VS 2017 and haven't had much experience with MVC. I have an existing database that I need to use with a core 2.0 project at work. I was able to use the Scaffold-DbContect to initially create the domain models from the existing database.
However, the database developers are making changes to the database and adding new tables. I need to keep my domain models in sync with the database changes that are being made.
The only thing I can find on the internet is how to make changes to the model and update the database schema. However, I need to update the model from changes made to the database.
EF Core works on Code First approach. And You guys are following DB First approach together. So you should make changes in your code and then generate migrations accordingly, Otherwise, it will lead you in trouble.
You can use EF Core Power tool for generating the db changes at code side. But in this case you have to take care while generating migrations from code side.
I have an application that uses Entity Framework code first migrations where the application is deployed on two servers both using the same database. Now I have a simple database update where a table and the EF model has a new column/property. I have created the migration and it works fine in a one server scenario.
But how do I deploy this to two servers without downtime? Without EF I would just start out and add the column to the table and then update the servers one by one. The old app would work just fine against the updated database as long as it is a simple change like this. What is the best way to do this in EF? Can I avoid problems in the second, not updated server, while I am updating the first one and the database?
This sounds like a perfect candidate for a Mirrored database, assuming you are using SQL Server.
You'd just apply your migrations to the Principal database and it will take care of the rest behind the scenes.
For my first app I created the db and the tables it used. I was not impressed that I had to use buddy classes for validation, but at least I know what I am doing now.
For my next app, is it worth learning instead how to create db scripts to populate an empty db, and do it that way round? I suspect it is, but let me know what you think.
I find it quicker to design using the EF Designer and then generate the database from that. It's less key strokes overall. Sometimes I'll then make changes in the database and bring them back into the model, but for that first pass, EF designer works great.
My small team used asp.mvc 2.0/entity framework 4.0(model first approach)/Windows Server 2008r2/Sql Server 2008 r2 stack in out web site project. We've already complete developing process, and come to the web deployment stage. In this stage we are faced with the problem - ok we'll use vs2010 features for initial server/db deploy, but what we'll do in the future? Obviously some of our models can be modified after publishing in order to satisfy new conditions, and of course our server db will contains users data sets, articles etc. Is there any approach to update servers db with new db modification, without dropping db, and converting data from old instance to the new one?
Now we have found only DAC/DACPAC approach to update server db, but we don't know how to bind auto EF model generation with DAC.
May be there is exists another solution? Is there any standard way to resolve this kind of situation? Any advice?
Thanks
I'd be interested to know if you have found a solution to this yet?
Have you tried simply generating a database based on your EF model, and using a schema comparison tool such as SQL Compare to deploy changes from the EF-generated database and your target production server?