Showing posts with label Windows Azure. Show all posts
Showing posts with label Windows Azure. Show all posts

Monday, April 8, 2013

Windows Azure using git deployment with two different websites in the same repository

Excited about the Windows Azure git deployment feature I decided to give it a try with bitbucket. Wow, talk about dead simple invisible magic deployment, I was very surprised at how easy it was. The only hangup is that the process is only designed to handle a single site deployment, if you have more than one web project and/or solution it's time to roll up your sleeves and read some dudes blog.

The git deployment uses a project called kudu that executes when a deployment is triggered by the git repository service of your choice. The process runs a series of shell commands to script and execute the deployment. While looking for a solution I came across an article that explained how to deploy two sites one nodejs the other mvc4 using a conditional batch file. It is just as easy to use this same method for two or more sites deployments using app setting keys to negate any conditional logic, thus turning your deploy.cmd into one line of sweet deployment victory.

Try it your self using the following steps:

  1. In the windows azure portal select the website you want to include.
  2. Select the configuration tab
  3. Scroll Down to app settings
  4. Use the Key APPLICATION then enter the name of the application you will use this later
  5. Repeat steps 1-4 for the 2nd website you will be deploying
  6. On your local computer open a git prompt:
    npm install azure-cli -g
    You are running windows aren't you, that's ok the git prompt is a little bashful.
  7. This is going to install all kinds of azure magic, go get beverage and come back or stay and watch the console light show
  8. Now from your solution root:
    azure site deploymentscript --aspWAP {Relative Path To Your 1st Project}.csproj -s {Relative Path To Your Solution}.sln
    cp deploy.cmd {Application Name Used in 1st Azure App Settings}.cmd
    azure site deploymentscript --aspWAP {Relative Path To Your 2nd Project}.csproj -s {Relative Path To Your Solution}.sln
    cp deploy.cmd {Application Name Used in 2nd Azure App Settings}.cmd
    
  9. Now edit your deploy.cmd to look like this:
    @ECHO OFF
    %APPLICATION%.cmd
    
    Yes.. it's that easy!
  10. Commit your changes
  11. Check to see if they deployed in the azure portal deployments tab

Tuesday, September 20, 2011

Azure Security Certificate Names Are Case Sensitive

If you receive the following error and are not using a proxy, and do not have Fiddler open, you might have some mixed case somewhere in your certificate name configuration settings:

1:55:36 PM - Warning: There are package validation warnings.
1:55:36 PM - Preparing...
1:55:36 PM - Connecting...
1:55:38 PM - Uploading...
1:56:25 PM - Creating...
1:56:42 PM - HTTP Status Code: 500/nError Message: The server encountered an internal error. Please retry the request./nOperation Id: {GUID}
1:56:43 PM - Deleting Quality Assurance Debug Only - Website
1:56:44 PM - There was no endpoint listening at https://management.core.windows.net/{GUID}/services/hostedservices/website/deploymentslots/Staging that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details.
1:56:44 PM - Deployment failed

Friday, September 9, 2011

Windows Azure Multi-Site Single Role Using Host Headers With Config Transforms

I was excited to find out that Azure supported multiple sites with a single worker role with a few simple configuration changes thanks to Wade Wegner's Example. I was a little disappointed that the process of building the package did not include the XDT transforms on the config. Neither is the website packaged for deployment which strips out all non essential files references in the web application before deploying. After a number of google searches and some trial and error I came up with the following solution:


In my example I created a single website and associated it to my azure project as the only worker role.

In the worker role pre-build event I have placed the following for each website that needed to be packaged and transformed:

Cloud Project Pre Build Event

rmdir ..\Deploy.Cloud\Website.Mvc /S /Q
"%systemroot%\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe" "$(ProjectDir)..\Website.Mvc\Website.Mvc.csproj" "/p:Platform=AnyCPU;PackageAsSingleFile=False;Configuration=$(ConfigurationName);DesktopBuildPackageLocation=..\Package\Website.Mvc;PackageAsSingleFile=False;IntermediateOutputPath=..\Deploy.Cloud\Website.Mvc\\" /t:Package

*You must remove the intermediate location before it creates the package otherwise debug/release configurations will not differ

*Note the extra slash at the end yes that is intentional if you do not add it you will get some interesting error messages about properties with no value

ServiceDefinition.csdef

<Site name="Website.Mvc" physicalDirectory="Website.Mvc\Package\PackageTmp">


What's going on here
Every time the cloud project builds it will copy and package the website in the cloud project's project root folder as the website name. Next step is to update the ServiceDefinition.csdef use the intermediate path location for the physicalDirectory. Why? because the package directory contains all of the assets to be deployed as a web deployment project which is not needed when deploying using a web role.


References

Wednesday, August 17, 2011

Windows Azure Accelerator for Web Roles Missing Trace Logging By Default

After upgrading our applications to Windows Azure Accelerator for Web Roles I found that the trace messages disappeared. Windows Azure Accelerator for Web Roles default project does not enable trace logging by default. To fix this simply add the following lines to the WebRole.cs of the Windows Azure Accelerator for Web Role project.

private static void ConfigureDiagnosticsMonitor()
{
//... Omitted from example
// Trace Logs
diagnosticMonitorConfiguration.Logs.ScheduledTransferLogLevelFilter = LogLevel.Undefined;
diagnosticMonitorConfiguration.Logs.ScheduledTransferPeriod = TimeSpan.FromMinutes(1);
//... Omitted from example
}

Tuesday, February 8, 2011

Using XDT with Worker Role App.configs

Recently I wrote a worker role in windows azure and was hoping the app.config would transform much like the web.config in the web roles. Sadly this is not the case. The configuration transforms are very useful when making a distinction between production, staging and development environments. After a little research, I did discover how to roll my own hopefully Microsoft will extend this feature to the rest of the azure project types.

Like the web roles this transform is only executed when a deploy is executed, here is how it was done:

  1. Un-load the project containing your worker role and app.config
  2. Edit the project file at the bottom add the following lines:

    <usingtask taskname="TransformXml" assemblyfile="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.Tasks.dll">
    <target name="AfterCompile" condition="exists('app.$(Configuration).config')">
    <transformxml source="app.config" destination="$(IntermediateOutputPath)$(TargetFileName).config" transform="app.$(Configuration).config">
    </transformxml></target>
    </usingtask>


  3. Add the following Item Group:

    <ItemGroup>
    <Content Include="App.config" />
    <Content Include="App.Debug.Config">
    <DependentUpon>App.Config</DependentUpon>
    <SubType>Designer</SubType>
    </Content>
    <Content Include="App.Release.Config">
    <DependentUpon>App.Config</DependentUpon>
    </Content>
    </ItemGroup>
  4. Now add the new configuration files to the project App.Debug.config, App.Release.config
  5. Reload the worker role project project
  6. Unload the cloud service project that references the worker role
  7. Open the file for edit and add the following line:

    <Target Name="CopyWorkerRoleConfigurations" BeforeTargets="AfterPackageComputeService">
    <Copy SourceFiles="..\{PROJECT PATH}\obj\$(Configuration)\{ASSEMBLY NAME}.dll.config" DestinationFolder="$(IntermediateOutputPath)\{PROJECT NAME}" OverwriteReadOnlyFiles="true"/>
    </Target>

  8. Reload the project file

You will need to use the name of your project and the assembly name in the locations above. The paths are relative to the azure service project file. If you get lost you can add an element to the target and set the text to your path.