For my current work on Azure integration for NPanday I’m investigating what the Azure Tools do with the Service Configuration (*.cscfg) on publish, since the file in Visual Studio it isn’t the same as one which is deployed along with the Cloud Service Package (*.cspkg).
The build & package part for Azure Cloud Services can be found in %Program Files (x86)%\MSBuild\Microsoft\VisualStudio\v10.0\Windows Azure Tools\1.6\Microsoft.WindowsAzure.targets
Find and copy
First, the build tries to figure out which configuration to build use as input by checking for ServiceConfiguration.$(TargetProfile).ccfg and ServiceConfiguration.ccfg, while $(TargetProfile) is “Cloud” by default.
As a part of the build, after being copied, the configuration file is augmented with more settings.
Add “file generated” comment
That was why I noticed, that the files are different. The comment in the target file makes it look like the file is generated from scratch, but instead it is just a copy which changed here and there. By default, the comment is the only change 🙂
<AddGeneratedXmlComment GeneratedFile="@(TargetServiceConfiguration)" SourceFile="@(SourceServiceConfiguration)" />
Cloud Tools version
If IntelliTrace or profiling is enabled, this change lets Azure know which versions of the tools are in use.
<AddSettingToServiceConfiguration ServiceConfigurationFile="@(TargetServiceConfiguration)" Setting ="$(CloudToolsVersionSettingName)" Value="$(CloudToolsVersion)" Roles="@(DiagnosticAgentRoles)" Condition="'$(EnableProfiling)'=='true' or '$(EnableIntelliTrace)'=='true'" />
Intelli Trace
If IntelliTrace is enabled, it will add a connection string to the configuration:
<AddIntelliTraceToServiceConfiguration ServiceConfigurationFile="@(TargetServiceConfiguration)" IntelliTraceConnectionString="$(IntelliTraceConnectionString)" Roles="@(DiagnosticAgentRoles)"/>
Profiling
If profiling is enabled, it will add an connection string, where to store profiling data.
<AddSettingToServiceConfiguration ServiceConfigurationFile="@(TargetServiceConfiguration)" Setting ="Profiling.ProfilingConnectionString" Value="$(ProfilingConnectionString)" Roles="@(DiagnosticAgentRoles)" />
Remote Desktop
If remote desktop is set to be enabled, the build configures this switch in the cloud service configuration, too:
<ConfigureRemoteDesktop
ServiceConfigurationFile="@(TargetServiceConfiguration)"
ServiceDefinitionFile="@(TargetServiceDefinition)"
Roles="@(RoleReferences)"
RemoteDesktopIsEnabled="$(EnableRemoteDesktop)"
/>
Web Deploy
If WebDeploy is enabled for any of your web roles, it will add an endpoint to the definition and set the instance count to zero for all web roles in the service configuration.
<EnableWebDeploy ServiceConfigurationFile="@(TargetServiceConfiguration)" ServiceDefinitionFile="@(TargetServiceDefinition)" RolesAndPorts="$(WebDeployPorts)" />
Connection String Override
If ‘ShouldUpdateDiagnosticsConnectionStringOnPublish’ is set to true, the diagnostics connection string is overridden for all roles in order to prevent the default setting “UseDevelopmentStorage=true” to be published to the cloud.
This is one of the typical “Microsoft demo-ready” features. Most certainly you’ll have multiple role-spanning connection strings or settings that you’d like to change on publish, but this is the only one needed to get demos to run, right?
<SetServiceConfigurationSetting Roles="$(DiagnosticsConnectionStringRoles)" ServiceConfigurationFile="@(TargetServiceConfiguration)" Setting="$(DiagnosticsConnectionStringName)" Value="$(DiagnosticsConnectionStringValue)" />
Corresponding parameters in NPanday
The most complex part in the build is the setup for profiling and IntelliTrace; currently we have no plans on supporting these in NPanday. We will rather just deploy from Visual Studio, in case we need profiling or IntelliTrace.
I still have to look at how RDP and MSDeploy can be added to the configured service configuration; for a first release of NPanday that may have to be done manually.
Lars Corneliussen 