I have a database context that I am trying to update using DB scaffolding.
The command I am using in package manager console is:
Scaffold-DbContext Name="pwa_db" Microsoft.EntityFrameworkCore.SqlServer -OutputDir Data -Force
My appsettings.json looks like this:
"ConnectionStrings": {
"pwa_db": "Server=[My Server];Database=[My DB];Trusted_Connection=True;MultipleActiveResultSets=true"
}
yet when I run the command I get this error:
"A named connection string was used, but the name 'pwa_db' was not found in the application's configuration. Note that named connection strings are only supported when using 'IConfiguration' and a service provider, such as in a typical ASP.NET Core application. See https://go.microsoft.com/fwlink/?linkid=850912 for more information."
The strange thing is that this context was generated using this command so I'm not sure why it would stop working now.
I could easily get around this by just using the full connection string in the command instead of a named connection but then the DB context is generated with the connection string inside which I would prefer to avoid because you always get a warning like this:
#warning To protect potentially sensitive information in your connection string, you should move it out of source code. You can avoid scaffolding the connection string by using the Name= syntax to read it from configuration - see https://go.microsoft.com/fwlink/?linkid=2131148. For more guidance on storing connection strings, see http://go.microsoft.com/fwlink/?LinkId=723263.
The warning itself I'm not so concerned about because I'm using a trusted connection, so no credentials are being stored and I'm not expecting the source to ever leave our office.
Can anyone tell me what other configuration bits I might need to look at or what other issues may be at play? Because I can't see what is going wrong from the docs linked in any of the messages.
Have you tried adding the connection string to the appsettings.development.json file too?
I know this is old but maybe this can help someone else.
It works for me and I followed what you did in the scaffolding command and the json "ConnectionStrings". The error mentions IConfiguration. You are probably missing the connection set up in the Startup class.
public class Startup
{
public Startup(IConfiguration configuration)
{
Configuration = configuration;
}
public IConfiguration Configuration { get; }
// This method gets called by the runtime. Use this method to add services to the container.
public void ConfigureServices(IServiceCollection services)
{
...
services.AddDbContext<DTCCDbContext>(options =>
options.UseSqlServer(Configuration.GetConnectionString("pwa_db")));
...
}...
Related
I have hosted Azure Function V3 on Azure Linux environment. I am trying to read the connection string from the configuration section. But I am not getting it. I tried to put the connection string on both, Application Settings as well as Connection Strings sections as shown below.
I am using dependency injection and my Startup class looks like below.
using BHD.Data.Data;
using Microsoft.Azure.Functions.Extensions.DependencyInjection;
using Microsoft.EntityFrameworkCore;
using Microsoft.Extensions.DependencyInjection;
using System;
[assembly: FunctionsStartup(typeof(BHD.AzureFunctions.Startup))]
namespace BHD.AzureFunctions
{
class Startup : FunctionsStartup
{
public override void Configure(IFunctionsHostBuilder builder)
{
var sqlConnection = ConfigurationManager.ConnectionStrings["DefaultConnection"].ConnectionString;
builder.Services.AddDbContext<ApplicationDbContext>(
options => options.UseSqlServer(sqlConnection));
}
}
}
I get NullPointerException on ConfigurationManager.ConnectionStrings["DefaultConnection"].ConnectionString even though the connection string exists in local.settings.json file as shown below.
{
"IsEncrypted": false,
"Values": {
"AzureWebJobsStorage": "UseDevelopmentStorage=true",
"AzureWebJobsDashboard": "UseDevelopmentStorage=true"
},
"ConnectionStrings": {
"DefaultConnection": "<My connection string>"
}
}
The way to get configuration in Azure Functions 2+ is IConfiguration, not ConfigurationManager.
You can inject IConfiguration into most places where you might inject anything else, but in Startup() you need to use something like this trick instead.
IConfiguration will automatically read from your function app settings when hosting in Azure, and your local.settings.json when run locally.
Edit (references):
The documentation for this is IMHO neither clear nor easy to find. There is also a lot of related discussion and confusion on GitHub.
The main source is DI in Azure Functions 2. Within it, most of what you need to know is almost easily missed:
The function host registers many services. The following services are safe to take as a dependency in your application:
[...] Microsoft.Extensions.Configuration.IConfiguration [...]
It also, in Working with options and settings says:
Values defined in app settings are available in an IConfiguration instance
The host does this for you; you do not need to do anything, and as above, it automatically gets settings from the correct source depending on your hosting context.
I would like to ask if there is a way to tell ASP.NET Core 2 to choose different connection strings.
It is quite annoying to keep changing the connection string in the appsettings.json file every time I publish my website to the hosting server..
I am using this code to get connection string.
services.AddDbContext<AppIdentityDbContext>(options =>
options.UseSqlServer(Configuration["Data:WebDataBase:ConnectionString"]));
Maybe there is an easy way but I am thinking of using an if statement in my Startup.cs:
if (local) {
services.AddDbContext<AppIdentityDbContext>(options =>
options.UseSqlServer(Configuration["Data:WebDataBase1:ConnectionString"]));
}
else {
services.AddDbContext<AppIdentityDbContext>(options =>
options.UseSqlServer(Configuration["Data:WebDataBase2:ConnectionString"]));
}
But how can I set this local variable whether the server is my local computer or a live hosting server?
"Data": {
"WebDataBase1": {
"ConnectionString": "Data Source=DatasoruceName;Initial Catalog=DBname;Trusted_Connection=True;Integrated Security=True;"
},
"WebDataBase2": {
"ConnectionString": "Data Source=DatasoruceName;Initial Catalog=DatabaseName;Trusted_Connection=True;Integrated Security=True;"
}
}
Environment specific configuration is not supposed to be specified within code. ASP.NET Core has a mechanism for that which allows you to swap out the configuration dependending on what environment you run on.
While developing your application, you usually run in the Development environment. When you are deploying your application for production, the Production environment is used by default. But if you have other environments, you can totally make up new names for those too and have specific configurations for them. That all is explained in the Environments chapter of the documentation
What environments allow you to do is create multiple appsettings.json files. The ASP.NET Core by default comes with two files: appsettings.json and appsettings.Development.json.
The former is supposed to contain environment unspecific configuration; things that apply to all environments. The latter file contains development-specific configuration and for example adjusts the logging level so that you get more information during development. You can also use these files to specify a default connection string within appsettings.json and overwrite that for development within appsettings.Development.json.
Furthermore, the configuration file follows a very simple pattern: appsettings.<Environment>.json. So if you run in the Production environment, a file named appsettings.Production.json will be loaded if it exists. This mechanism allows you to configure all your environments differently without having to resort to detections within your code.
In addition, there is also the concept of user secrets during development. These are for development-specific configurations that do only apply to yourself but not for example to other members of your team. This is basically a per-machine configuration that allows you to overwrite both the appsettings.json and the appsettings.Development.json. This is described in the user secrets chapter.
Best practice is to avoid connection strings altogether within configuration files though, since you want to avoid that people that happen to have access to your configuration files (for example through your source code) can know the passwords to your database. In that case you can use other mechanisms, for example environment variables that are local to the process.
In your case, where you are just using integrated security, and as such rely on the credentials of the current user, this is not that much of a problem. The only thing you are leaking is the database name. – So you can definitely start out with putting the connection strings into the appsettings files.
So for example, this is how you would configure your database context within your Startup’s ConfigureServices:
services.AddDbContext<AppIdentityDbContext>(options =>
options.UseSqlServer(Configuration.GetConnectionString("WebDataBase"));
Your appsettings.Development.json would look like this:
{
"ConnectionStrings": {
"WebDataBase": "Data Source=DatasourceName;Initial Catalog=DBname;Trusted_Connection=True;Integrated Security=True;"
}
}
And your appsettings.Production.json would look like this:
{
"ConnectionStrings": {
"WebDataBase": "Data Source=DatasourceName;Initial Catalog=DatabaseName;Trusted_Connection=True;Integrated Security=True;"
}
}
I have a .net core solution that contains a database project (class library) and a console application. The database project contains EF Migrations and to do Add-Migration, most methods use a hard-coded connection string in one place or the other.
To avoid hard-coding (and/or duplication) I have created a shared appsettings.json file in the solution root and I use it in my Main method and the class library
In the console application
static void Main(string[] args)
{
var settingPath = Path.GetFullPath(Path.Combine(#"../appsettings.json"));
var builder = new ConfigurationBuilder()
.AddJsonFile(settingPath, false);
var configuration = builder.Build();
var services = new ServiceCollection()
.AddDbContext<MyContext>(options => options.UseSqlServer(configuration["ConnectionStrings:MyDatabase"]))
.BuildServiceProvider();
}
And in the class library to use migrations
public class DesignTimeDbContextFactory : IDesignTimeDbContextFactory<MyContext>
{
public MyContext CreateDbContext(string[] args)
{
var settingPath = Path.GetFullPath(Path.Combine(#"../appsettings.json"));
var builder = new ConfigurationBuilder()
.AddJsonFile(settingPath, false);
var configuration = builder.Build();
var optionsBuilder = new DbContextOptionsBuilder<MyContext>()
.UseSqlServer(configuration["ConnectionStrings:MyDatabase"]);
return new MyContext(optionsBuilder.Options);
}
}
This is working well for development purposes when I use dotnet run but when I publish the console application, it doesn't include the appsettings file. Other than running a powershell script as part of dotnet publish, is there any other cleaner way of including this file when the project is published?
IDesignTimeDbContextFactory is exactly for the purpose its name describes. You shouldn't be running migrations against your production database in the first place, and if you do, you should be generating specific migrations for production into your app (instead of the class library) and using your app for the migrations. See the docs on using a separate project for migrations. That, then, negates the need to share your appsettings.json. Just leave the connection string hard-coded in your factory, since it's only for development anyways.
Now, you might have an issue I suppose in a team environment. However, even if you're using something like SQLite, you can use project-relative paths that won't be developer-specific, and with LocalDB, you can use a normal SQL Server connection string to the MSSQLLocalDB instance, which will be same for every developer using Visual Studio. Regardless, even if you do need to specify the connection specifically by developer, at that point it would make more sense to use user secrets, anyways, since you wouldn't want that info be committed to source control. Otherwise, each developer would end up clobbering the other's copy of appsettings.json, and you'd have a mess on your hands.
Long and short, just hard-code the connection string in your factory, or if you can't or won't, use user secrets for the connection string. In either case, you do not need to share appsettings.json.
The way I've done this before is to specify the startup project when you run dotnet ef (with the -s switch - the options are at https://learn.microsoft.com/en-us/ef/core/miscellaneous/cli/dotnet#common-options)
It gets messy quickly, and it's probably easiest to write some wrapper scripts for the project that deal with this kind of thing.
I am going to try and explain this issue as clear as I can.
I start with two projects:
Project One: Data model
A repository class that wraps a DbContext that has a single DbSet: RentalListings
This DbContext uses the default settings, so that when I save changes it saves to local DB.
Project Two: Console App
Contains a console application that when runs, instantiates an instance of the repository class.
Then it creates multiple "RentalListings" and saves them to the repository.
So far so good. After running the console app I check the local DB SQL object explorer, and my repository class has successfuly saved to this db.
Now, I want a way to access this inserted data via a Web API. So I add:
Project Three: Web API
I create a new controller class and add a single GET action method to fetch all listings.
When I run the API project, I can hit the action method, which looks like:
[HttpGet]
public IEnumerable<RentalListing> GetAllListings() {
StatsRepository repository = new StatsRepository(new StatsContext());
return repository.GetRentalListings();
}
via the correct URL. However I am getting the following error returned:
Unable to complete operation. The supplied SqlConnection does not specify an initial catalog or AttachDBFileName.
Now, from searching the web I think the issue is that it doesn't know how to access the database??? And that I should specify a connection string in the Web.config file in my Web API project.
Questions:
1) How did my console app, that doesn't specify a connection string, create a mdf database using my repository class?
2) Why doesn't the same work for my web api project? can't it just use the repository to fetch the database, just like the console app did?
Look forward to hearing the replies, thanks in advance!
Q :1. How did my console app, that doesn't specify a connection string, create a mdf database using my repository class ?
A :1. It is by default.If you didn't specify the connection string on console app then it uses your context class namespace plus name of the context class to create a db.
e.g.
Context class namespace = MyDbContextNameSpace
Name of the context class = MyContext
Then your DB name will be like this : MyDbContextNameSpace.MyContext.
Note : If SQL Express is installed then the database is created on your local SQL Express instance (.\SQLEXPRESS). If SQL Express is not installed then Code First will try and use LocalDb ((localdb)\v11.0).
You can read more about it here : Building an Initial Model & Database
Q :2. Why doesn't the same work for my web api project? can't it just use the repository to fetch the database, just like the console app did?
A :2. When you talk to EF through Http/s,you have to provide the connection string on web.config file. Otherwise EF doesn't know how to do that.That is by design.
e.g.
MyContext.cs
public class MyContext : DbContext
{
public MyContext() : base(“name=MyContextConn”)
{
}
public DbSet<Blog> Blogs { get; set; }
}
web.config
<connectionStrings>
<add name=“MyContextConn“ connectionString=“conndetails”
providerName=“System.Data.SqlClient“ />
</connectionStrings>
The DbContext class can definitely be responsible for 'specifying a connection string', as you put it, but the reason it is most commonly found in a config file is so that different connection strings can be specified for different configurations. For example, your Web.Debug.config connection string might point to an instance of SqlExpress that you have installed on your development box and the Web.Release.config connection string might point to a Sql instance contained in Azure.
Specifying a connection string in your config file isn't necessarily going to fix the issue. The connection string can specify a username and a password. If you put those in to the connection string then it will most likely work. For example <add name="DefaultConnection" connectionString="Server=myServerAddress;Database=myDataBase;User Id=myUsername;Password=myPassword;" providerName="System.Data.SqlClient" />
The issue you are experiencing is most likely due to the fact that the console application is running under the context of the Windows user launching the application. It is using those credentials to connect to the database. I'm assuming that your console, webapi app and sql are all installed/running on the same machine and that your user is the only one that you use to log in to sql(again assuming you are using SSMS). The web application though is most likely being run through IIS or IISExpress which is run under a different context by default(I believe IUSR for IIS). If you would like to have your connection string use integrated security(to keep your username and password out of your configs -- which is generally considered a good practice) like this: <add name="DefaultConnection" connectionString="Data Source=myServerAddress;Initial Catalog=myDataBase;Integrated Security=True" providerName="System.Data.SqlClient" /> then you would want to setup the context that the application is being run under by updating the user the apppool is running under. You would do this by updating the app pool identity and then making sure that the web application is using that app pool.
Hope this helps.
I have a database and a C# class library which acts as a repository for accessing objects from the database using Entity Framework. When trying to use this repository assembly in other projects I am running into difficulty; My working assumption is that this it due to the Connection String as I am getting the following error:
The specified named connection is either not found in the configuration, not intended to be used with the EntityClient provider, or not valid.
I have added an App1.config file to the project and added the same connection string I had successfully used when creating the database:
<add name="EDSEntities" connectionString="metadata=res://*/Model1.csdl|res://*/Model1.ssdl|res://*/Model1.msl;provider=System.Data.SQLite;provider connection string='data source="C:\Documents and Settings\hmay\My Documents\My Projects\Timetabler\DataSets\EDS.db";foreign keys=true'" providerName="System.Data.EntityClient" />
.... but it doesn't work. I don't understand the connection string very well and wondered if there is something else here I might need to tweak?
Regards
Adding app1.config would not do anything. App.config and web.config are specially named files and they need to be named exactly that. However if you use your library in multiple apps i would refactor it.
Change the DbContext class to have a single constructor that takes a connection string and push the responsibility for creating the connection string into the app rather than the library. It is not good to have a class library that expects your app to have a particular named entry in the connection strings section of its config.
try trimming metadata references to metadata=res://*