2
votes

I have a C# ASP.Net MVC4 Web Role deployed on Windows Azure Cloud Services using Package and Publish. First time it uploaded entire package and site has been running fine. When I wanted to publish the next set of changes, the Publish option is trying to upload the entire package again.

I have already configured Remote Desktop and Web Deploy and also enabled incremental updates as per guidelines stated in the article Publishing a Cloud Service using the Windows Azure Tools.

But this seems to be not working and Publish is trying to upload entire package again and again. Has anybody faced this issue and come up with any fix?

3

3 Answers

5
votes

Nope.

currently there is no out-of-the-box solution to support incremental changes deploy.

When working with Cloud Services I highly suggest that you do not use Web Deploy for anything else than development/testing. The reason is that all changes made via web-deploy and any other non-full-package-upload process will be wiped out as soon as an instance in being recycled/healed.

I've been working on a project to allow rolling out partial changes. Unfortunately it only supports update to the "bin" folder currently. You can take a look at this project here. It is a good starting point at least.

2
votes

For quick publish incremental changes to development environment (Not recommended for Production), check - Speed Up Azure Deployments with the New Web Deployment Feature.

0
votes

In VS2013, choose 'Deploy' from the context menu of the Web App project which is referenced by the role (and not the 'Cloud Service' project referencing the role(s) ... doing that will publish the whole service and all of its roles non-incrementally).

There should be a 'publish profile' which refers to the website on the *.cloudapp.net platform. If there is, it was put there by Visual Studio ... probably when you first ticked the 'Enable Web Deploy for all web roles' check-box when first deploying the service.

However, it might not be there, or be wrong. Because, for example, Visual Studio is dumb, and noticing that you had already published the Web App as a 'Web Site' (before you decided to incorporate it as a 'Web Role' in a service), it decided to leave the existing entry for *.azurewebsites.net alone. Or is it because that project was only included in the role as an <VirtualApplication /> element in the service definition's XML, and Visual Studio just neglected to create it?

So you'll have to find some way to force Visual Studio to re-create the right profile for you, or you'll have to manually copy and edit the publishing profile XML files from a known good source (Properties/PublishProfiles directory under the project root), or just guess the settings from absent documentation.

Those settings will be something like:

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="12.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <WebPublishMethod>MSDeploy</WebPublishMethod>
    <MSDeployServiceURL>https://MYAPP.cloudapp.net:8172/MsDeploy.axd</MSDeployServiceURL>
    <DeployIisAppPath>INSTANCE</DeployIisAppPath>
    <RemoteSitePhysicalPath />
    <AllowUntrustedCertificate>True</AllowUntrustedCertificate>
    <SkipExtraFilesOnServer>True</SkipExtraFilesOnServer>
    <DeployAsIisApp>False</DeployAsIisApp>
    <MSDeployPublishMethod>WMSVC</MSDeployPublishMethod>
    <UserName>MYUSER</UserName>
  </PropertyGroup>
</Project>

Where: MYAPP - is the domain name of the deployed Azure service INSTANCE - is the name of the instance you want to update (get it from Server Explorer ... it's the 'Name' property of the 'Instance' under your service ... or get it from the list of instances comprising your service from the Windows Azure management dashboard). MYUSER - is the name of the user you set up when publishing initially, for the Remote Desktop Services