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
Related
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.
Does anyone know what the difference is between these two? I've looked and can't seem to find a page that has a clear description of how they are different. The way Microsoft explains the two of them is very vague.
Definition documentation
The file contains the definitions for the roles that are available to
a cloud service, specifies the service endpoints, and establishes
configuration settings for the service.
Configuration documentation
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
The very first line in the link you included for service definition file (*.csdef) is very important - The service definition file defines the service model for an application.
As you know Cloud Services are Stateless PaaS Services, and simply put the service definition file tells Azure Fabric Controller how your VM should be created and configured for you. For instance, InputEndpoints defines the ports that must be opened in the firewall to allow incoming traffic. Another example is vmsize element which tells the Fabric controller to create a VM of particular size (Small, Medium etc.) for hosting your role.
Service Configuration file (*.cscfg) can be thought of as web.config or app.config equivalent for your roles (Web and Worker). This is where you define the application settings.
One key difference between the two files is that csdef file is included in the package that gets deployed so if you have to make any changes to csdef file (e.g. VM size) you would need to redeploy your code. cscfg file is deployed along the package and you can make changes to the settings on the fly without having to redeploy your code. So if you have a setting and you want to change the value of that setting, you can simply do so on the portal (or some other means) without having to redeploy your code. Please note that the configuration setting elements name is also stored in csdef file so you can't add or remove a setting from the cscfg file. You have to add/remove it from both cscfg and csdef file.
When I use Windows Azure configuration settings, each time I publish an update to my cloud service, the settings are overwritten with the default from my project. This seems rather pointless to me, since if I want to override the default settings in the cloud, it makes sense that I want to preserve those overrides even when publishing an update to the app's code. Is there a way to preserve the settings when publishing from Visual Studio?
NO - A redeploy of your service will override all the settings to whatever is set in the config file (.cscfg) that you provide. To preserve the settings you have to update both, the configuration file in the cloud and the configuration file on your local disk.
Yes - create a local ServiceConfiguration.cscfg (the default) and a cloud or prod configuration ServiceConfiguration.Cloud.cscfg. Right click The cloud project and then "Manage Configurations" to add a new cscfg file. In your publish settings, then specify "Cloud" as your service configuration.
But, if you are asking if you are asking if you can update the Azure Role without uploading settings, then NO - you have to upload a Service configuration file.
In the "on premise" world, when creating an application like a Windows Service I'd classically use an App.config file to store a variety of configuration information about the application, from database connection strings to WCF endpoint information.
In the Azure Worker Role world, I am now presented with .cscfg files which are said to contain information "for the role".
I don't understand whether these files are there to supplement the configuration of the application, or replace App.config files entirely. How do these two files work to configure Azure Worker roles?
Very Basic Explanation:
Conceptually they're the same. In a traditional application, you use app.config file to define various settings related to the application (in appSettings section). Similarly, you use cscfg file to define various settings related to your cloud application (in ConfigurationSettings section). Like app.config file, you get to define other things (e.g. number of instances of your cloud application) in the cscfg file.
If you want, you can still define some of the settings in app.config file but one thing to keep in mind is that app.config file gets "packaged" and deployed and in order to change the settings, you would have to repackage your application and deploy it. However you could change the settings in a cscfg file on the fly using either the portal or Service Management API without having to repackage and redeploy the application. For example consider the scenario where you're defining the database connection string in settings file. If you specify that in app.config, in order to change it you would need to make change in app.config file --> Build the application --> publish the application. Where as in case of a cscfg file, you would just change this value in the portal.
For Web/Worker Roles the traditional configuration files (app/web.config) will keep working like they do on an on-premises deployment. But it's important to know that this file is included in the Service Package, meaning it's part of the deployment.
This means you can't change the settings you have in your app/web.config without redeploying your application. The ServiceConfiguration.cscfg on the other hand is something which is defined at Cloud Service deployment slot level, next to the actual Service Package. This means you can change this configuration file without having to redeploy your application. These settings can also be accessed from your application by calling RoleEnvironment.GetConfigurationSettingValue (similar to ConfigurationManager.AppSettings).
If you consider building an application that works both on-premises and in Windows Azure, consider using the Microsoft.WindowsAzure.ConfigurationManager package. Which automatically chooses the cscfg or app/web.config based on where your application runs.
Tip: By subscribing to the RoleEnvironment.Changing/Changed event you can intercept changes to this configuration file. You can handle this to update the web.config in code for example (explained here).
When setting up an Azure Web / Worker Role for the first time I need to 'Package' the project and upload it via the Azure portal. After doing this I can 'Publish' the application from Visual Studio.
Under which circumstances do I need to 'Package' the project again and update it via the Azure portal?
In other words - which changes require the project to be re-packaged?
Note: I need to 'Package' the project in order to upload it via the Azure portal. When I create a Compute Role in Azure, I must upload a package in order to be make the Compute Role operational.
From Azure portal:
You have nothing deployed to the production environment.
UPLOAD A NEW PRODUCTION DEPLOYMENT.
The Cloud Service package contains the role definitions, configuration settings, runtime bits, and other static content bundled with your app. Visual Studio (or PowerShell) creates an encrypted package (actually a zip file that you can look into, when building for emulator) for upload to the named slot you created via the portal.
In the future, there are certain things you can do without rebuilding the package, such as changing instance count and other configuration settings. Also: If you move your static content (such as your CSS, images, etc.) to blob storage, you can then update those directly without ever needing to recreate / redeploy the package (you may need to send some type of signal to your running app, to reload some resources, but that's going to be app-specific). If you have specific exe's or MSI's that get installed as part of your startup scripts, you can move these to blob storage as well, since they can easily be downloaded as your role startup code executes (and this cuts down on package size).
If you change anything defined exclusively in the service definition file (e.g. if you add a role or change a role size), you will have to repackage/redeploy (but you can deploy as an update, which won't take your service down [assuming you have 2 or more instances] or replace your assigned IP address).
I don't think you must package your project at the first time. You can publish your azure project for the first time. I'm not sure what prevent from your publishing. Could you explain a bit more.
I fact, the publish is very similar as package. Visual studio just packaged the project and uploaded them to azure on behalf of you.