When using the Windows Azure Tools for Visual Studio, there are two times that you end up creating a Windows Azure Service Package:
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.
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":
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.
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.
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:
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?)
We're excited to announce that we've released an update to the Windows Azure Tools and SDK.
What's new in the Tools?
What's new in the SDK?
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!