Learn about the new tools for remotely debugging workflows in Visual Studio 2012
In Office Developer Tools for Visual Studio 2012, we enabled remote event debugging using Windows Azure Service Bus.
Now, in Visual Studio 2013, we have implemented a similar approach for remotely debugging workflows in apps for SharePoint.
The new and re-worded debugging options are available on the SharePoint tab under the Properties page of your app for SharePoint project, as shown in Figure 1.
To debug workflows on Office 365, select the “Enable Workflow debugging” and “Enable debugging via Windows Azure Service Bus” check boxes and enter the Service Bus endpoint connection string. If you try to debug without providing a connection string, you will be prompted to supply one.
As mentioned in the previous blog post, you’ll need to follow these steps to use the Windows Azure Service Bus for debugging remote events:
- Register for a Windows Azure account and then create a Service Bus namespace.
- See Managing Service Bus Service Namespaces for more information about managing namespaces.
- To get the Service Bus connection string, select your service namespace, choose Access Key, and then copy the Connection String.
After you have enabled remote event debugging and configured the Service Bus connection string, you can debug remote events.
- How can I turn on/off the notification from Visual Studio that tells me to provide a Service Bus connection string? If you are debugging an Office 365 workflow in your project and have not configured Service Bus debugging, Visual Studio will prompt you to configure it (see Figure 2). You can change this behavior by clearing the Notify me if Windows Azure Service Bus debugging is not configured check box on the SharePoint project property page.
- When do I need to enable the Service Bus debugging for workflows? You must enable Service Bus debugging if you want to debug workflows on Office 365. If your project targets SharePoint installed on your local network, you do not need to enable Service Bus debugging. Instead, you need to open incoming connections to TCP port 12292. If you use Windows Firewall with Advanced Security, you can simply enable the rule “Workflow Manager Tools 1.0 for Visual Studio 2012 – Test Service Host”. If you try to debug against a SharePoint host on the local network without opening the port, Visual Studio will prompt you to enable the rule.
- Do I have to enable Service Bus debugging for every project? Even though you configure the settings in project properties, Service Bus debugging settings are saved for the current user of the workstation so that you can reuse the settings across different projects. However, this setting is not saved into source control (TFS), so if they are needed by a different user or on a different machine, they need to be entered again.
- Will I be charged for Service Bus usage? Yes. Remote event debugging uses the Relay Service component of the Service Bus. Refer to the Service Bus Pricing FAQ for more information. If you are currently a Visual Studio Professional, Premium, or Ultimate with MSDN subscriber, you can check out the special offer on Windows Azure, which provides Service Bus Relay Hours of up to 1,500, 3,000, and 3,000 respectively.
- Do I have to change debugging settings before I publish my app to the marketplace or to the Corporate Gallery? No. The package created by the Publish command in Visual Studio has the .app extension and does not contain any debugging information. A separate package, having the .debugapp extension is the only one used during debugging.
- Can I use Service Bus to debug workflows in SharePoint sandbox or farm solutions? No. SharePoint solutions can only be debugged against SharePoint installed on the developer’s workstation.
- Can I use Service Bus to debug SharePoint 2010 workflows? No. You can only use it for debugging apps for SharePoint, and apps cannot contain SharePoint 2010 workflows.