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.
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.
I have multiple service configurations defined : local, testing, and production.
under properties of the web role, configurations tab, I set the service configuration to one of the options.
However, this does not affect the values that I get using CloudConfigurationManager.GetSetting(key)
Even when set to local, I get the value for the production configuration.
I assume that setting the active conflagration is done elsewhere, or that it does not apply when running local?
I could not find the answer in the pages below:
http://msdn.microsoft.com/en-us/library/windowsazure/ee405486.aspx
Azure role configuration management
we want to deploy a webrole on the Azure cloud service (PaaS)
we have multiple Virtual Applications that have exactly the same codebase (dlls) but different web.configs
this leads to multiple time the same dll's in the package to upload; resulting in a very large package file
is there any way to share the bin folder for these 'same' Virtual Applications to minimize the size of the package?
greetings,
Tim
Create a cloud application with one web role containing the codebase and additional web roles containing only the Web.config for the multiple virtual applications.
On ServiceDefinition.csdef, define the virtual applications for the roles as required.
Set a startup task to copy the contents from the complete web role to each of the additional virtual applications. This will be executed at role initialization time, with administrator privileges.
This way your deployment package won't need to include multiple copies of the same artifacts, and the virtual applications will be set up when the role instance is initialized.
Is it possible for you to load your configuration settings based on the host header or incoming request?
In the past we had configuration settings stored in Azure Blob Storage that were loaded (and then cached) based upon the host header. This allows you to load what is identically the same site except for the specific settings for that client.
In essence this is a multi-tenant application.
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).
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