I have been really struggling with this. There is a lot of info, but can't seem to figure out the basics to get started.
In ASP.Net, I would have done all this with different web.config files.
This is what the end result of what I want is.
I have a single server with IIS on it. (say www.mysite.com)
I have 3 versions of the ASP.net core web site
www.mysite.com/PROD
www.mysite.com/DEMO
www.mysite.com/TEST
I am using Web Deploy from VS to Publish these to the server. I would like to have 3 different Publish profiles. Each will use a different configuration and publish to the appropriate web site.
The end result should have these differences
PROD:
ASPNETCORE_ENVIRONMENT : Production
Connection string : ... myDB_Prod
SiteName : "The Real Site"
DEMO:
ASPNETCORE_ENVIRONMENT : Production
Connection string : ... myDB_Demo
SiteName : "The Demo Site"
TEST
ASPNETCORE_ENVIRONMENT : Development
Connection string : ... myDB_Test
SiteName : "The Test Site"
LOCAL DEV
Use ISSExpress
ASPNETCORE_ENVIRONMENT : Development
Connection string : ... myLocalDB
SiteName : "Local Dev"
Note. This is made up, but would answer my questions. It is not what I am really doing, so please don't comment on that. I would actually really like to be able to turn on Development by changing something in a config file on the server without deploying (say in the web.confg!)
In my research, I am getting really confused with all the various places to set config. There also is changes in 2.2 and that is throwing me off.
I have been reading the MS Docs, but I must be missing something. Not sure where to start. appsettings.json, web.config, other config files, etc.
Related
i am new to Web-Development and so it is the first time, that I try to work with different environments.
So in my WebApp which is deployed on Azure I want to use a connectionString for my local database, when I am working locally in development environment, and when I deploy it, it should use a different database with another connectionString.
I have seen that there are two files in my Asp.Net Core project. "appsettings.json" and "appsettings.Development.json". If I understand correctly, app.dev.json should override the settings in app.json if I work in Development Environment. But it doesn`t. When I am debugging the app, to realy make sure that environment is set to development, it still uses appsettings.json.
You might be correct in term of Multiple Configuration Files. appsettings.json is a default configuration file that you can declare anything which includes both Development and Production. The merging pattern will be appsettings.{Environment}.json, then all matching keys will replace all keys in appsettings.json. Remembered the name Environment should be matched with ASPNETCORE_ENVIRONMENT to be used. In you case, app.dev.json so your environment should be dev (case-sensitive) instead of Development.
For example: We have a default `appsettings.json
{
"ConfigurationString": "mongodb://localhost:27017",
"MongoOptions": {
"AllowWireUp": true,
"AutoConnect": true
}
}
Then you want to work in Development, you create appsettings.Development.json with content
{
"ConfigurationString": "mongodb://192.168.1.1:27017",
"MongoOptions": {
"AllowWireUp": false
}
}
Later when you run with Development, you will get combined file
{
"ConfigurationString": "mongodb://192.168.1.1:27017",
"MongoOptions": {
"AllowWireUp": false
}
}
Important: You will see MongoOptions.AutoConnect is false in Development because .NET Core merges two files based on first level key instead of merging nested. That means MongoOptions in appsettings.Development.json will replace entire your appsettings.json
There is a way to do that. I guess you are using Azure app service?. if so follow thease steps
Create multiple app-settings files inside your project. (dev/ staging / uat / prod)
These file names shoud be appsettings.Development.json appsettings.uat.json and appsettings.Production.json
Each file should contain its own configurations.
Then Go to your App service in azure > configuration > Application settings , add required prifix of your appsettings json file in Value filed in ASPNETCORE_ENVIRONMENT
Restart app service. it should work now
I have a Core WebJob deployed into an Azure Web App. I'm using WebJobs version 3.0.6.
I've noticed that changes to Connection Strings and App Settings (added via the Azure web UI) are not being picked up immediately by the WebJob code.
This seems to correlate with the same Connection Strings and App Settings not being displayed on the app's KUDU env page straight away (although I acknowledge this may be a red herring and could be some KUDU caching thing which I'm unaware of).
I've deployed a few non-Core WebJobs in the past and have not come across this issue so wonder if it's Core related? Although I can't see how that might affect configs showing up KUDU though.
I was having this issue the other day (where the configs were not getting picked up by the WebJob or shown in KUDU) and was getting nowhere, so left it. When I checked back the following day, the configs were now correctly showing in KUDU and being picked up by the WebJob. So I'd like to know what has happened in the meantime which means the configs are now being picked up as expected.
I've tried re-starting the WebJob and re-starting the app after making config changes but neither seem to have an effect.
It's worth also noting that I'm not loading appSettings.json during the program setup. That being said, the connection string being loaded was consistenly the connection string from that file i.e. my local machine SQL Server/DB. My understanding was always that the anything in the Azure web UI would override any equivalent settings from config files. This post from David Ebbo indicates that by calling AddEnvironmentVariables() during the setup will cause the Azure configs to be observed, but that doesn't seem to be the case here. Has this changed or is it loading the configs from this file by convention because it can't see the stuff from Azure?
Here's my WebJob Program code:
public static void Main(string[] args)
{
var host = new HostBuilder()
.ConfigureHostConfiguration(config =>
{
config.AddEnvironmentVariables();
})
.ConfigureWebJobs(webJobConfiguration =>
{
webJobConfiguration.AddTimers();
webJobConfiguration.AddAzureStorageCoreServices();
}
)
.ConfigureServices((context, services) =>
{
var connectionString = context.Configuration.GetConnectionString("MyConnectionStringKey");
services.AddDbContext<DatabaseContext>(options =>
options
.UseLazyLoadingProxies()
.UseSqlServer(connectionString)
);
// Add other services
})
.Build();
using(host)
{
host.Run();
}
}
So my questions are:
How quickly should configs added/updated via the Azure web UI be displayed in KUDU?
Is the fact they're not showing in KUDU related to my Core WebJob also not seeing the updated configs?
Is appSettings.json getting loaded even though I'm not calling .AddJsonFile("appSettings.json")?
What can I do to force the new configs added via Azure to be available to my WebJob immediately?
The order in which configuration sources are specified is important, as this establishes the precedence with which settings will be applied if they exist in multiple locations. In the example below, if the same setting exists in both appsettings.json and in an environment variable, the setting from the environment variable will be the one that is used. The last configuration source specified “wins” if a setting exists in more than one location. The ASP.NET team recommends specifying environment variables last, so that the environment where your app is running can override anything set in deployed configuration files.
You can refer here for more details on Azure App Services Application Settings and Connection Strings in ASP.NET Core
I'm trying to publish my ASP.NET Core application on Azure service. This works, but when I try to use the application functionality, I get the message
Your App Service app is up and running.
Moreover, in my wwwroot folder I don't have any .html files. I only have an Index.cshtml file, which is located in the Views/Home-folder in my application, all another files are .css, .js, etc.
When I run the application in Visual Studio in Debug mode, immediately opens the page in browser that was generated from Index.cshtml. But after the application is published in Azure, this does not happen.
What can I do to make Azure see Index.cshtml?
AFAIK, a default route would be added to Configure method of your Startup.cs file as follows:
app.UseMvc(routes =>
{
routes.MapRoute(
name: "default",
template: "{controller=Home}/{action=Index}/{id?}");
});
I also created my .Net Core 2.0 MVC application to check this issue, it could work as expected on local side and my azure web app.
Moreover, in my wwwroot folder I don't have any .html files.
Views under Web Application and Web Apllication MVC would be compiled into {your-webapplication-assemblyname}.PrecompiledViews.dll, you could leverage ILSpy to check your DLLs.
For your issue, I would recommend you clear the web content in your web app via KUDU, or modify the publish settings and choose Remove additional files at destination under File Publish Options, then redeploy your application to Azure Web App to narrow this issue.
Are you finding index.cshtml in your web package? In case if you get index.cshtml in your final web package, you may need to add index.cshtml file type to the following in..
..YourAzureWebApp --> Application Settings --> Default Documents
I found out what the problem was. There are two types of applications, as presented below in the picture: Web Application and Web Apllication MVC. I worked with the second type of application. When I selected the first type and published the application, Azure immediately found the required index.html. I just had to choose Web Application.
But why does not it work with the second type of application (Web Apllication MVC)? I still do not know the answer to this question.
2 cents from my side as I just stuck for a while with this.
The problem was that yesterday I'd been playing around with deploying to Ubunut / Ngnix and today I decided to try Azure.
BUT I forgot to comment (disable) the following lines in my Startup:
//for nginx server
app.UseForwardedHeaders(new ForwardedHeadersOptions
{
ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto
});
and that costed me almost half of the day to find the issue.
I also put the routing in the following way
app.UseStatusCodePages();
app.UseAuthentication();
app.UseMvc(routes => {
routes.MapRoute(
name: "default",
template: "{controller=Pages}/{action=Index}");
});
Now looks like it works on Azure :)
As described in this article: https://azure.microsoft.com/en-us/blog/windows-azure-web-sites-how-application-strings-and-connection-strings-work/, Azure Web Apps/Web Sites/Web Jobs can take their configuration settings (appSettings, connectionString) from environment variables instead of app.config/web.config.
For example, if an environment variable named "APPSETTING_appSettingKey" exists, it will override the following setting from app.config/web.config:
<appSettings>
<add key="appSettingKey" value="defaultValue" />
</appSettings>
This works fine once the application is deployed in Azure, but I would like to use the same method when testing locally.
I tried to emulate this in a local command line:
> set APPSETTING_appSettingKey=overridedValue
> MyWebJob.exe
The web job accesses this setting using:
ConfigurationManager.AppSettings["appSettingKey"]
When running in Azure, it reads the value "overridedValue" as expected, but locally it reads the value "defaultValue" from the app.config file.
Should I expect this to work, or is this implemented only under an Azure environment?
I could obviously create an abstraction over ConfigurationManager that emulates this, but this wouldn't work when calling code that needs a connection string name instead of a connection string value. Also, I want to use the same method regardless of the environment to simplify management of settings.
There are 3 reasons why I need this:
1) I don't like the idea of deploying to production a web.config file that references connection strings, etc for a developement environment, because there's a risk of an error that would cause the development settings (in web.config) to be used in production (production web app connecting to development database, etc), for example if an environment variable is named incorrectly (after renaming the setting in web.config but forgetting to rename it in environment variables)
2) I'm trying to setup development environments where each developer has his own isolated cloud resources (storage account, databases,...). Currently, everyone has to manually edit his .config files to reference the correct resources, and be careful when checking-in or merging changes to these files.
3) A solution can have multiple projects that need to duplicate the same settings (main web app, web jobs, integration test projects,...). This causes a lot of work to ensure updated settings are replicated across all files.
This would be simplified if there was an environment-independent .config file without any actual configuration, each developer would configure a set of environment variables once and be able to use them for all parts of a solution.
Yes, this special transformation of environment variables into config values is done via a component that is specific to Azure WebApps and won't be in play locally.
Generally people are fine with the local behavior this produces - locally you are reading from config settings as usual, but in Azure you're reading from secure settings that were configured via the App Settings portal blade (so these settings aren't in your source code).
You could write an abstraction over this if you wish, E.g. the WebJobs SDK actually does this internally (code here).
When I am developing locally and want to consistantly use Environment.GetEnvironmentVariable. In my static class Main I have the following code:
if (config.IsDevelopment)
{
config.UseDevelopmentSettings();
Environment.SetEnvironmentVariable("UseDevelopmentSettings", "true");
}
Then in my static class Functions I add a static constructor and in there I call the static method below:
static void AddAppSettingsToEnvironmentVariables()
{
String useDevelopmentSettings = Environment.GetEnvironmentVariable("UseDevelopmentSettings"); ;
if (!(String.IsNullOrEmpty(useDevelopmentSettings)))
{
foreach (String key in ConfigurationManager.AppSettings.AllKeys)
{
Environment.SetEnvironmentVariable(key, ConfigurationManager.AppSettings[key]);
}
}
}
The code is small enough that I can simply comment it out before I test in Azure.
If you want to test the application with the value that will be used in Azure portal AppSettings/Connection String. I would recommend use HostingEnvironment.IsDevelopmentEnvironment. To ensure it will work, please change the <compilation debug="true" targetFramework="4.5.2" /> to <compilation debug="false" targetFramework="4.5.2" />. set the value with the same value in Azure portal if (HostingEnvironment.IsDevelopmentEnvironment == false). I have try with a simple project, hope it helps:
public ActionResult Index()
{
if (HostingEnvironment.IsDevelopmentEnvironment == true)
{
ViewBag.Message = "Is development.";
}
else
{
ViewBag.Message = "Azure environment.";
}
return View();
}
Here is the result:
Just starting off with Breeze and Azure. I downloaded the sample app and added my own controllers. On my local machine it works just fine. When I deploy to my Azure site, I keep getting the following error in the logging section of the page: Query failed: Metadata query failed for: api/CoreData/Metadata; An error has occurred.
I have a controller named Products that simply returns a view. The view contains the js calls to my CoreData ApiController. Follows the sample.
The only thing logged on the server is the following:
At first I was using EF to access data, but have changed to just creating an in-memory object and returning it so as to eliminate db issues.
The URL is http://acapella.azurewebsites.net/products. I've spent quite a bit of time trying to diagnose and research, but feel that I'm overlooking something simple.
Any help or suggestions would be appreciated.
An Azure web site is a free, relatively easy way to deploy a Breeze application where you can test it on a variety of mobile devices and experience your app's responsiveness (or lack thereof).
I have had good success pushing a Breeze app to an Azure web site but there were many stumbles including some that looked like yours.
Two thoughts. First, you'll want to turn "Custom errors off" in your Web.config.
<configuration>
<system.web>
<customErrors mode="Off"/>
</system.web>
</configuration>
My second recommendation: take a look at John Papa's post on deploying an MVC Web API app to an Azure web site. It is excellent. And I know it works.
I hope to have a video on the process very soon.
The first thing you can do is return the exception. In your Breeze controller do this:
[HttpGet]
public string Metadata()
{
try
{
return _contextProvider.Metadata();
}
catch (Exception e)
{
return e.Message + Environment.NewLine + Environment.NewLine + e.StackTrace;
}
}
That made it clear to me something was wrong with my connection string. The exception I got was:
Format of the initialization string does not conform to specification starting at index 0.
My connection string locally seemed ok, but the problem was on Azure. My web.release.config had a correct transform, but when publishing, Visual Studio would add another connection string. You can check this by connecting with FTP to your Azure site and looking at your web.config. I fixed it by selecting the correct connection string when publishing:
After that, there still seem to be two connection strings in my uploaded web.config, but at least it works.