I've got a web application written in .NET Core using Entity Framework to connect to a SQL Server database. Everything works fine locally. The staging/production environment for the app is AWS Elastic Beanstalk, and I seem to be stuck on how to get the app to connect to the database there.
I've created an RDS (SQL Server) database underneath the Elastic Beanstalk app.
Connection string:
user id=[USER];password=[PASSWORD];Data Source=[SERVER].rds.amazonaws.com:1433;Initial Catalog=Development
Creating the DbContext:
services.AddDbContext<MyDbContext>(o =>
o.UseSqlServer(Configuration["Db:ConnectionString"]));
App fails to start, based on the following line in Startup.cs:
dbContext.Database.EnsureCreated();
You have to troubleshoot step by step as below procedure:
Db Connection string is working or not? Better to use with other app and simple doing the Db Connection testing. It could be possible that firewall block your port 1433.
As per your codes, .NET Core Framework will crate a database by code first approach. So that, you have to make sure, your IIS Application Pool user account has write access to SQL Database. Most probability it could be your problem.
Related
I'm counting on being able to use PostgreSQL 10-13 with NPGSQL drivers and the NPGSQL EF Core 5.0 Provider for deployment to Azure Web Apps and AWS Linux.
However, the NPGSQL docs focus on developer issues and are limited regarding details like connection strings and other tricky basics.
ConnectionStrings.com provides only simple samples of PostgreSQL connection strings and no diagnostic info.
Can anyone clue me into basic stuff like, what values are appropriate for a 'host name' in a Postgresql NPGSQL connection string when I'm in a Microsoft environment vs a Linux environment?
I'm trying to stay away from ODBC and OLE DB or other ADO.NET era tech.
Big thanks for any other clues like where and by whom is this itchy information is available?
A host name is just a standard DNS hostname (e.g. server.domain.com), or an IP address.
This page in the Npgsql docs lists the various connection strings, with the basic ones at the top. The getting started page shows a typical basic example of a connection string too.
My integration tests for my asp.net core application require a connection to a PostgreSQL database. In my deployment pipeline I only want to deploy if my integration tests pass.
How do I supply a working connection string inside the Microsoft build agent?
I looked under service connections and couldn't see anything related to a database.
If you are using Microsoft hosted agent, then your database need to be accessible from internet.
Otherwise, you need to it on self-hosted agent that can access your database.
I assume the default connectionstring is in appsettings.json, you could store the actual database connectionstring to a secret variable, then update appsettings.json file with that variable value through some task (e.g. Set Json Property) or do it programming (e.g. powershell script) before running web app and starting test during build.
If you can use any PostgreSQL database, you can use service container with a docker image that has PostgreSQL database (e.g. postgres).
For classical pipeline, you could call docker command run the image.
I would recommend you to use runsettings which you can override in task. In that way you will keep your connection string away of source control. Please check this link. And in terms of service connection, you don't need any service connection, only what you need is proper connection string.
Since I don't know how you connect to your DB in details I can't give you more info. If you provide example how you already connect to database I can try to provide a better answer.
I'm stuck with a .Net Core 1.0 project I'm not allowed to update to the newest .Net Core version yet, and currently trying to deploy it to a development IIS (8.5, on Server 2012 R2).
Slowly working through the list of errors now… and I've come across a strange case with an sqlite database the service uses internally.
The project has a postpublish step that grants write permissions (to IIS AppPool\DefaultAppPool on the machine running the IIS) for a few files the service needs to be able to write.
All but the sqlite file are writeable from the service afterwards, and are correctly being updated.
For the sqlite database however it throws a SqliteException SQLite Error 14: 'unable to open database file', unless I give Full Access not only to the DefaultAppPool user mentioned above, but Everybody—so to me it looks like the EF code is executed in another user context than the rest of the service.
Does anyone know which user, or how I could best find out (or what else might be the problem)?
I've built a multi tenant MVC4 application that use a specific database depending on the hostname.
The site binds to all of our customers hostnames:
If a visitor surfs to 'domain1.com', the 'domain1.com' database is used.
If a visitor surfs to 'domain2.com, the 'domain2.com' database is used.
Automatic migrations are normally placed in Application_Start():
Database.SetInitializer(new MigrateDatabaseToLatestVersion<MyProject.Models.MyProjectContext, MyProject.Migrations.Configuration>());
This will run the migrations on application start. However, since my application responds to several hostnames, only one database will be migrated. When i switch to another hostname, that database IS NOT migrated since the application is already loaded into memory on the server.
I solved this by moving the above line of code to Session_Start().
Is this good practice? Is there a better solution?
Thanks in advance,
Andreas
It seems I am running into the Microsoft Distributed Transaction Coordinator (MSDTC) related issue.
SCENARIO
I am using TransactionScope and with in the single scope it hits two different databases on different servers (for instance, DB_A running Windows Server 2003 and DB_B running Windows Server 2008). One database is accessed using Entity Framework 4.0 and another using normal ADO.NET APIs.
When I run the application from my development machine (running WinXP) it commits and rollbacks both the connections accurately. But when I run the application, deployed on another server (for instance WAS_A running Windows Server 2003) it commits correctly but in case of exception is doesn't roll back the database activities on both the servers.
I thought it would be the MSDTC configuration issue on the WAS_A. So I went to the MSDTC -> Security Configuration and checked all the available options (as I did previously on other machines). But still I am facing the same issue.
Looking for your expert advices. :)
I believe that you need to look into Enabling Transaction Flow. Specifically, take a look at how one may error and the other complete as described in TransactionScope and WCF Services:
an error in a second WCF service call was NOT rolling back the changes made in a previous WCF service call...
In order to create an ambient transaction in your client and ensure that it is used by your WCF services...
The article then details the following steps:
Configure Your Binding with transactionFlow
Decorate Your Interface with [TransactionFlow(TransactionFlowOption)]
Decorate Your Method with [OperationBehavior(TransactionScopeRequired)]
Optionally update your Connection Strings with Transaction Binding*
*Note: This is optional in my opinion.