The config value is stored in the Web.config. When I build the web project, the Web.config gets copied to the build folder as {ProjectName}.dll.config. Running the web app locally works fine, the config value gets read without problem using ConfigurationManager.AppSettings["{key}"];.
When I build the cloud service however, the {ProjectName}.dll.config does not get copied to the cspkg file that I upload and run on Azure. I would expect it to be in approot/bin. However there is a Web.config in approot.
Running on Azure the app fails when trying to read from the app settings using ConfigurationManager.AppSettings["{key}"];.
I am aware of CloudConfigurationManager but I would like to avoid having to maintain the configuration in both, Web.config and the cloud cscfg.
The service configuration file specifies the number of role instances to deploy for each role in the service, the values of any configuration settings, and the thumbprints for any certificates associated with a role.
In Solution Explorer, select Properties>Development>Service Configuration and set the value as Cloud.
Then, set the web role's Service Configuration as Cloud.
In setting tab, Add Setting about connection string and what you want to store.
The following code illustrates an example of how to access a connection string. Replace the placeholder with the appropriate value.
// Setup the connection to Azure Storage
var storageAccount = CloudStorageAccount.Parse(RoleEnvironment.GetConfigurationSettingValue("<ConnectionStringName>"));
For more details about how to configure Azure Cloud service roles with Visual Studio, you could refer to this article.
Related
Can I host a web application created on .net core 2.1 with sql server as database to azure web app service using CI tools / MS WebDeploy?
The following points I want to take care:
The application is using file system for temp storage and file storage
Deployment should be managed by some CI tools such as jenkins
After deployment, the app settings file should be modified with some keys/server details
Log files(stored on app root) should be accessible by application administrator
Is there a way to create a virtual directory same as in IIS and upload the files using FTP or similar protocols..?
All your doubts about deploying .net core 2.1 web app are achievable.
Suppose our projects are all completed and uploaded to github.
Questions and explanations about your concerns：
About the connection configuration using the database, you can directly configure it in web.config. If you are using azure sql server, find the connection string, set up the firewall, and pass the SSMS test, you can test the connection in the code. It can also be added in the Configuration -> Application settings -> Connection strings in the portal. After the addition, the priority is higher than the configuration in web.config, which will override the configuration and not modify the web.config file.
Regarding the use of file storage, you can use azure storage services or not. Looking specifically at the business, for example, very small pictures, documents and other files can be stored in the current program running directory, which is consistent with the original development at the code level. When publishing, you need to include the MyFiles file in the publishing process, or wait for the publishing to be completed and add folders manually in kudu, or the program can judge. It is recommended to use the program to judge that the subsequent program upgrade will not lose data.
The confidential information in the app settings file can actually be configured in web.config or appsetting.json. Make sure that the offline project is running properly when you are debugging locally, and then you can publish it. The rest is configured in the portal as in the first explanation.
The Log Files file storage can fully achieve the effect you want. It should be enough to set the owner permissions of this app services. For details, please refer to the official documentation.
Virtual directories and virtual applications, I have a better answer in another post here, you can refer to it.
Steps：
First of all, we can create a web app in portal and select .net core 2.1. Create appservices, and click Deployment Center when finished.
Follow the prompts step by step, and wait until the Action in github is completed, and the release is successful.
I was able to deploy Azure Functions to run SignalR Messaging to the Azure portal, but the local.settings.json file which contained the SignalRConnectionString required to run SignalR Messaging was not uploaded. How can I add this string on the Azure portal?
Error message on Azure portal :
Microsoft.Azure.WebJobs.Extensions.SignalRService: The SignalR Service connection string must be set either via an 'AzureSignalRConnectionString' app setting, via an 'AzureSignalRConnectionString' environment variable, or directly in code via SignalROptions.ConnectionString or SignalRAttribute.ConnectionStringSetting.
the local.settings.json file which contained the SignalRConnectionString required to run SignalR Messaging was not uploaded. How can I add this string on the Azure portal?
Please check whether you add all Function app settings that you defined in the local.settings.json to function app in Azure when you publish the project.
If you did not add AzureSignalRConnectionString for the Remote field, you can select and navigate to your function app on Azure portal, then you can update value of AzureSignalRConnectionString or add new application setting for your function app in Configuration under Platform features blade, like below.
Application settings
Test Result
I have a webapp deployed to an Azure Web App. In the webapp I am using MembershipReboot, with Entity Framework. The Sql Server database is also in Azure.
It is deployed via BitBucket integration and continuous deployment, in a staging slot.
As part of the build process, a web.config transfrom, changes the connection string value to "dummy".
I set this the connection string, named MembershipReboot, in the Azure portal.
When I browse to the application, I get this error:
Format of the initialization string does not conform to specification starting at index 0.
If I change the connection string in the web.config, to be the Sql Azure connection string the app loads fine. If I set it back to "dummy" then I get the above error.
This indicates to me that the connection string set in the Azure portal isn't being picked up by the application.
I created this Azure enviromnent using the ARM template deploy, mixed with some Azure powershell commands. I've tried creating the environment by hand too, with the same issue.
Any ideas on what to look at next?
edit: Just to say, the correct connection string is viewable within Kudu.
Managed to fix this.
It was due to StructureMap being invoked, and creating a database context (via global.asax), before the environment was providing the correct connection string.
In our case, the app was mixing Owin startup and global.asax Application_Start, we had to move the global.asax startup into the Owin startup, and not allow the database context to be created during that startup. I suspect we could have just done the latter.
Recently I had a problem with a service in Windows Azure, I've deploy the app to staging with a connection string to test DB, before I swap to production, i've change the connection string to production DB, that was on saturday, but today at my production environment the connections strings were to test DB.
Is there an schedule to recycle the instances in windows Azure?
If there is, Where did azure took the package to create the new instance?
Thanks in advance.
Azure can recycle your cloud service (Web and Worker) roles at any time and you don't have any control on that. When you deploy your service, it is stored in Azure storage and instances are created from that. Once deployed, you can't change the Web.config file because if redeployed, the new instance will use the original settings stored in your deployment package. It is best practice to store connection strings in the service configuration file instead of the Web.config file since you can change it at runtime.
Check this SO Q/A for the how to: Set the application ConnectionString in the Service Configuration instead of web.config in Azure
I have an single Azure Web Role CSPKG with multiple CSCFG files for different customers.
When I deploy a new version I need to specify both which package and configuration file to use.
But sometimes there are changes made in the Azure portal that not have been changed in source cscfg files. (Ex: custom logging levels, etc).
Is there any way I can upgrade an existing instance without overwriting existing settings in Azure. (Of course the scheme needs to be the same).
That's pretty easy to do:
Create a console application which gets the current properties from the Service Management API (Get Hosted Service Properties with embed-detail=true, look for the ExtendedProperties element).
Have it update your local CSCFG file
Deploy the CSPKG and the updated CSCFG file