January, 2009

  • Cloudy in Seattle

    Adding Files to your Windows Azure Service Package


    When using the Windows Azure Tools for Visual Studio, there are two times that you end up creating a Windows Azure Service Package:

    1. When you build and run on the Development Fabric -- this is a folder based package, extension is csx.  This is used by the Development Fabric.
    2. When you use the "Publish" feature -- this creates a .cspkg file which is a zipped and encrypted version of the csx built in (1).  This is what you upload to the Cloud.

    This post explains how this process works so that you can have better control over what files end up in the package. 

    The first thing to know is that in both cases above, the way the contents of the package is created are the same.  The difference is that in case 2, the package is zipped and encrypted.

    Web Role

    The way the Web Role copies files to the Service Package is by using the internal ASP.Net _CopyWebApplication build target.  This build target copies the build outputs and content files.

    In other words, it doesn't copy all of the files in your project to the Service Package.  It has to either be a build output or a content file. 

    If you want an your file to be copied, you can add it to the project:


    and set the Build Action from "None":


    To "Content". 


    This marks the file as "Content" and will copy the file to your Service package (both when debugging in the DevFabric and "Publish" to the cspkg).

    The other option you have is to keep the Build Action as "None" but set "Copy to Output Directory" to "Copy if Newer" (or "Copy Always").  The difference is that when you set the Build Action to "Content", the file will show up in the root of the Web Role folder, whereas when you set the file to Copy to the Output Directory, it will show up in the bin directory along side your build output.


    One of the side effects of using the Web Application build action is that linked files are not supported.  We're working with the ASP.Net team to get this fixed in the future.

    Worker Role

    A Worker Role does not use the Web Application target that I referred to above and the only option to have extra files copied to the Service Package is to keep the Build Action set to None and set Copy to Output Directory to "Copy if newer".


    For assemblies that you need to have copied to the output directory, you can always add a reference to that assembly, even if you don't need it directly from your Web or Worker roles.  The reference has a property "Copy Local" which defaults to true.

    One exception is if the referenced file is in the GAC and you'll have to set "Copy Local" to true manually.

  • Cloudy in Seattle

    Debugging Silverlight in a Web Role on the Development Fabric


    As part of the announcement of the January 2009 CTP of the Windows Azure Tools was "Added support to debug Silverlight in a Web Role".  I'll go into more detail about that in this post in 2 ways:

    1. Adding Silverlight to a Web Role
    2. Configuring the Silverlight debugger

    Note: Developing Silverlight applications in Visual Studio requires Silverlight Tools.

    We've also found that folks have run into IIS mime type mapping issues with Silverlight, please follow the following instructions if you run into a "Cannot download Silverlight: issue.

    Registering MIME type in development fabric

    To ensure solutions containing Silverlight clients work correctly in the development fabric, please ensure that the MIME type for the Silverlight .xap extension is configured correctly in IIS.

    1.     Open Internet Information Services (IIS) Configuration Manager and select the server to manage (usually the top-level item on the left side)

    2.     Double-click MIME Types on the right side

    3.     Add an entry to map the .xap extension to the application/x-silverlight-app MIME type

    Adding Silverlight to a Web Role

    In order to add Silverlight to a Web, you first need to create a Cloud Service that contains a Web Role.  In Visual Studio, click on File -> New Project and select a "Web Cloud Service".


    This will create the Cloud Service project along with an ASP.Net Web Application project which is associated to the Cloud Service as the Web Role.

    Next we'll add Silverlight, click on the solution in the solution explorer and select Add -> New Project...


    This will bring up the Add New Project dialog again, and this time you'll select Silverlight -> Silverlight Application.


    After selecting that, you will get the following Silverlight project creation dialog:


    Link the Silverlight control on to the Cloud Service Web Role by ensuring that "Link this Silverlight control into an existing Web site" is selected and the "Choose existing Web site:" ComboBox has selected the Web Role that was created when you created the Cloud Service.  (there should only be one Web Application in your solution so this should be the only option)

    Notice how there is a CheckBox to "Enable Silverlight debugging" -- this directly corresponds to the debugger project setting that I talk about later.

    Set the SilverlightApplication1TestPage.aspx as the startup page so that it will be loaded in the web browser when you hit F5.


    Next, to the Page.xaml, between Grid tag, add a button with a Click event handler by the Button tag as shown in the following xaml snippet:

        <Grid x:Name="LayoutRoot" Background="White">
            <Button Click="Button_Click" Margin="100" Content="Click"/>

    Then right click on "Button_Click" and select "Navigate to Event Handler".  This will create the event handler in code behind (if it doesn't exist already) and take you to that location in the source.


    Add a simple message box to the event handler.

    private void Button_Click(object sender, RoutedEventArgs e)
        MessageBox.Show("Hello from Silverlight in a Web Role");

    When you run the app, and click the button, you will now get the message box.


    To show off the Silverlight debugging, you can now add a breakpoint to the code behind:


    When you click the button, you'll hit the breakpoint!  (This didn't work in earlier versions of the tools)

    Configuring the Silverlight debugger

    The reason the breakpoint above was hit was because as part of the Silverlight project creation, the Silverlight debugger was enabled. (remember the CheckBox I pointed out above?)

    If for some reason (say if you were doing Javascript debugging "you cannot debug Silverlight code and JavaScript code at the same time." or you didn't select "Enable Silverlight debugging when you created the Silverlight project) you disabled the Silverlight debugger, you can re-enable it on the Web tab of the Web Application project settings (lower right corner):


  • Cloudy in Seattle

    January 2009 CTP of the Windows Azure Tools and SDK released


    We're excited to announce that we've released an update to the Windows Azure Tools and SDK.

    What's new in the Tools?

    • Addressed top customer bugs.
      • Resolved hang and performance issues on run and debug.
      • Fixed issue with "Publish" of large projects.
      • Fixed issue with "Create Test Tables" when both the web and worker role reference the same assembly
    • Added support to debug Silverlight in a Web Role.
    • Better storage services integration
    • Error messages when there are Service Configuration or Service Definition errors

    What's new in the SDK?

    • Addressed top customer issues
      • Space in user name
      • Development storage may fail with a fatal error if the user name includes a space character.
      • Concurrent GetMessages requests to the Queue service may return the same message.
      • The DevTableGen utility may fail when passed the same assembly name on the command line more than once.
      • Development storage may fail to update or delete entities that contain special characters like these: '- $ & + , : ; = @'.
    • The Windows Azure SDK offers improved support for the integration of development storage with Visual Studio, including enhanced performance.
    • The StorageClient sample includes the following improvements. For more information, see the StorageClient Sample topic in the Windows Azure SDK help file.
      • The StorageClient sample now offers an optional exponential backoff retry policy.
      • The StorageClient sample now supports production endpoints that include the account name.
    • The ASP.Net Providers sample now supports a search syntax similar to the ASP.Net SQL-based providers. For more information, see the ASPProviders Sample topic in the Windows Azure SDK help file.

    I'll be drilling in to some of the details of how we've made things better in this release in future blog posts -- stay tuned!

Page 1 of 1 (3 items)