To deploy a service in the development fabric, you must first package the service in the appropriate format. To package a service for the development fabric, call the CSPack command-line tool with the /copyonly option. This option copies the service binaries to a directory layout from which they can be run in the development fabric.

By convention, the default name for the directory created by CSPack ends in the .csx extension, but you can choose a different name for this directory.

Note that when you package a service for deployment to the cloud, you create a file package rather than a directory structure. The directory structure is for deployment to the development fabric only.

For more information about the CSPack command-line tool, see CSPack Command-Line Tool.

After you have run CSPack to package the service for local deployment, ensure that you have taken the necessary steps to configure and run development storage, if your service uses the storage services. For information about configuring development storage, see About Development Storage.

After you have packaged your service and started development storage, call the CSRun command line tool to deploy the service to the development fabric. For more information about using CSRun, see CSRun Command-Line Tool.

Calling CSRun starts the development fabric if it is not yet running. When the fabric starts up, a system tray icon appears. You can right-click this icon to display the development fabric UI, to start or shut down the development fabric, and to exit the utility.

Note that calling CSRun requires administrative privileges. If you are not calling CSRun from an elevated command prompt, you'll be prompted with two User Access Control (UAC) prompts each time you start up the developer fabric.

To launch an additional service deployment to the development fabric, call CSRun again. Each deployment appears in the developer fabric UI. Note that the development fabric UI does not support launching additional service deployments.

To update the service configuration, call CSRun with the /update option. It's not possible to update the service configuration from the development fabric.

Within your service definition file, you must specify a port number for an HTTP or HTTP endpoint. An HTTP endpoint must request port 80; an HTTPS endpoint must request port 443. For a service running in the Windows Azure fabric, this port number is allocated with a unique IP address.

In the development fabric, it's not possible to allocate a unique IP address. The developer fabric will attempt to assign the requested port. If that port is not available, it will allocate the next best available port number. This means that in the development fabric, your service may be assigned a different port number from the one that you specified in the service definition file.

The development fabric UI shows your service deployments in an interactive format. You can examine the configuration of a service, its roles, and its role instances. From the UI, you can run, suspend, or restart a service. In this way, you can verify the basic functionality of your service.

Debugging with the Development Fabric

The development fabric UI enables you to debug your service locally. In this way, you can ensure that the service runs as expected in the development fabric and that the logging information that your code is writing will be adequate for diagnosing problems when the service is running in the cloud.

Note:
It's not possible to attach a debugger to a role running in the cloud. Any live debugging information must be written to the logs.

To attach a debugger to a role running in the development fabric, right-click the role beneath the desired deployment in the left-hand pane of the development fabric UI and then click Attach Debugger. To configure the default debugger that the development fabric will attach to, display the development fabric UI, and then click Options from the Tools menu. Configure debugger information on the Attach Debugger tab.

Important:
A role running in the development environment runs with administrative privileges, whereas the same role running in Windows Azure runs with the privileges conferred by a standard Windows user account. It's possible that a role that relies on administrative privileges present in the local environment may behave differently when deployed to Windows Azure.

Logging and Alerting

Opening the Local Store

Concepts