Partager via

Debugging SharePoint 2013 workflows using Visual Studio 2013

  • Article

Learn about the new tools for remotely debugging workflows in Visual Studio 2013.

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.

Figure 1. Configure remote event and workflow debuggingFigure 1. Configure remote event and workflow debugging

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.

Figure 2. Prompt for a connection stringFigure 2. Prompt for a connection string

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:

  1. Register for a Windows Azure account and then create a Service Bus namespace.
  2. See Managing Service Bus Service Namespaces for more information about managing namespaces.
  3. 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.

FAQ

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.

Comments

  • Anonymous
    February 04, 2014
    Very useful info! We just did a review on the new features SharePoint 2013's workflows have to offer. Check it out! www.theunbounded.com/sharepoint-2013-whats-new-in-workflows

  • Anonymous
    October 25, 2014
    VS 2013 Update 3 SharePoint-hosted App (O365) Azure Service Bus Unfortunately the debugging does not work. As soon as I enable workflow debugging and start building the project the TestServiceHostProxy.exe stops working. Furthermore the App Installation fails because of the following Exceptions: Microsoft.VisualStudio.SharePoint.TestServiceHostProxy: Unhandled Exception: System.ArgumentNullException: Value cannot be null. Microsoft.VisualStudio.SharePoint.TestServiceHostProxy: Parameter name: s Microsoft.VisualStudio.SharePoint.TestServiceHostProxy: at System.Convert.FromBase64String(String s) Microsoft.VisualStudio.SharePoint.TestServiceHostProxy:     at Microsoft.ServiceBus.SharedSecretTokenProvider.DecodeSecret(String issuerSecret) Microsoft.VisualStudio.SharePoint.TestServiceHostProxy:     atMicrosoft.VisualStudio.SharePoint.Remote.Diagnostics.ServiceHostFactory.CreateTransportClientEndpointBehavior(ServiceBusConnectionString connectionString) Microsoft.VisualStudio.SharePoint.TestServiceHostProxy:     at Microsoft.VisualStudio.SharePoint.TestServiceHostProxy.Program.CreateWebServiceHost(Uri tshUrl, String sbPath, Uri baseAddress) Microsoft.VisualStudio.SharePoint.TestServiceHostProxy:     at Microsoft.VisualStudio.SharePoint.TestServiceHostProxy.Program.Main(String[] args) Any thoughts? Thanks in advance!

  • Anonymous
    November 23, 2014
    Hi Igor, Microsoft Azure Service Bus now supports two types of connection strings: SAS and ACS. Based on the error you're getting the connection string you're using is an SAS connection string. For workflow debugging via Azure Service Bus, only ACS connection strings are currently supported. Follow the instructions on the Service Bus Authentication and Authorization page (msdn.microsoft.com/.../dn170478.aspx) to get an ACS connection string for any new Service Bus namespace created after August 2014. Thanks, John

  • Anonymous
    December 22, 2014
    The comment has been removed