Should a Lightswitch 2011 project still publish to Azure RRS feed

  • Question

  • I created a Lightswitch project in Visual Studio 2010 quite some time ago and it successfully published and republished to Azure. It has been running for more than 18 months. Recently the Azure account was changed to a new owner resulting briefly in there being no credit; as a result the application was removed. I have tried to re-publish but keep getting the following errors:

    Error 1 An unknown error occurred while attempting to deploy the published package to Windows Azure. 

    Error 2 The remote server returned an unexpected response: (400) Bad Request. 

    Nothing has changed other than new certificates were required as the old ones had expired.

    Should a Lighswitch 2011 project (created on Vista) still re-publish to Azure ?

    It would be re-assuring to know that others can still accomplish this.

    Friday, October 2, 2015 7:59 PM


All replies

  • I guess you're deploying directly to azure, but you can publish it to local file system and copy the package to azure instance. It requires "web deploy" tool installed there. That tool can be installed through web platform installer. 

    Join apps request, talk about startup ideas.

    Sunday, October 4, 2015 8:58 AM
  • Forrest

    Thank you for the reply and apologies for the delay in responding.

    I presume that you mean a 'pull' from the Azure end rather than a push from my PC ? This is new to me.

    So I should create a packaged application as opposed to a published application (as described in the Deploying Lighswitch Applications (2010 version)) and I can then install that from an Azure account ?

    The 'web deploy' tool that you refer to is also new to me. ..... but I will have a look around.



    Thursday, October 8, 2015 10:15 AM
  • I finally found the answer to this problem.

    Apparently when a Lightswitch Application is deployed to an Azure Service, a virtual environment is created and the Operating System (OS) to be used in this service must be specified. This can be specified in the configuration (.cscfg) file uploaded to Azure from Visual Studio.

    Two attributes – osFamily and osVersion can be specified. Different values (1, 2, 3 or 4) can be used for osFamily. Each indicates a particular ‘Azure Guest OS Family’ (see

     VS2010 Lightswitch does not by default include these attributes in the .cscfg file. If, when deploying an application to Azure from Visual Studio, these attributes are not explicitly provided in the .cscfg file then Azure defaults to using Guest OS Family 1.  That these attributes were not explicitly provided by VS2010 was not a problem ... until Azure Guest OS Family 1 was retired. After that, if an application was deployed from VS2010 to Azure it failed with the (not very helpful) messages noted above.

    This is what had happened to me. The project had been deployed and re-deployed successfully some time ago when Guest OS Family 1 was still valid. When I tried to redeploy it in August 2015 Guest OS Family 1 had been retired.

    How did it become clear that this was the problem ?

    As indicated in the reply from Forrest above, it is possible to deploy a Lightswitch project to Azure by ‘pulling’ from Azure as opposed to ‘pushing ‘ from Visual Studio. I originally knew nothing about this route but it turns out to be fairly straightforward.  Access and sign in to the target Azure Account from the PC/Device where the built VS Project is located.  Assuming a Cloud Service/SQL Database have been created on Azure, select the Cloud Services tab, double-click the Cloud Services Name. Select Deployment Settings/Create Production Deployment. Specify a Deployment Label and paths to the Package and Configuration files for the VS Lightswitch Project. These are in the ...bin\release folder for the built Project; the Package has an extension of .cspkg and the Configuration an extension of .cscfg. Click the ‘tick’ (OK) icon in the lower right of the screen to initiate the upload.

    When I followed this route using the Project which had failed to deploy from VS2010 it, of course, also failed to deploy from Azure. The difference was that, this time, the error message was precise and meaningful with a suggested route to correct it.

    The .cscfg file can be displayed by clicking ‘file view’ in Solution Explorer. Manually add the osFamily and osVersion attributes to the ServiceConfiguration element.

    <ServiceConfiguration serviceName="xxxxxxxx" xmlns="" osFamily="2" osVersion ="*">

    Make sure that the project is rebuilt after the attributes are included.

    When this had been done the VS2010 Project successfully deployed from VS2010 to Azure.

    So the answer to the original question above is yes, a VS2010 project can still be deployed to Azure... but the osFamily and osVersion attributes must be added manually to the .cscfg file.

    Mike H

    Friday, January 15, 2016 12:50 PM
  • Nice to know you get it fixed!

    Join apps request, talk about startup ideas.

    Saturday, January 16, 2016 1:44 AM