Investigating Issues with InfoPath 2010 SharePoint Applications

  • Article

Summary:  Learn how to use debugging techniques and diagnostic tools to quickly investigate issues with SharePoint applications that use Microsoft InfoPath 2010. Specifically, this guide examines best practices for finding problems with InfoPath 2010 form solutions.

Applies to: InfoPath 2010 | InfoPath Forms Services | Office 2010 | SharePoint Server 2010

In this article
Overview of Investigating Issues with InfoPath 2010 SharePoint Solutions
Debugging a Form Template
Diagnostic Tools
Conclusion
Additional Resources
About the Author

Published:  October 2010

Provided by:  David Gerhardt, 3Sharp | About the Author

Contents

Overview of Investigating Issues with InfoPath 2010 SharePoint Solutions

Microsoft InfoPath 2010 enables organizations to build robust end-to-end SharePoint applications. When combined with InfoPath Forms Services in Microsoft SharePoint Server 2010, InfoPath 2010 enables users to automate business processes that collect, manage, and share information. IT professionals and developers can create powerful business applications with declarative logic (no code) or custom code on the SharePoint platform that uses InfoPath forms to interact with external data and drive workflows.

As with any SharePoint application, you should investigate issues carefully. InfoPath 2010 is equipped with debugging capabilities that let you quickly analyze problems, both at design time and run time. In addition, you can use a suite of diagnostic tools to review issues reported on the SharePoint Server. This article examines the most common diagnostic methods for SharePoint applications that use InfoPath 2010.

Debugging a Form Template

When you mention the term debugging, an IT professional or developer is likely to have visions of examining lines of custom code. It is true that when you create an InfoPath form solutions, you must consider custom code. However, not all form templates contain custom code: many use declarative logic only. Like code, declarative logic can also have unexpected results. As such, you will have to diagnose these problems as you would for custom code. Therefore, debugging has broader implications for InfoPath forms. In this section, you will examine different ways to discover issues in a form template, whether it contains custom code or not.

Viewing Hidden Nodes with a Custom Debug Form View

InfoPath 2010 uses an XML data model, both for the main data source and any external data sources used by the form template. Typically, the views in your form will not display every node from all data sources. Even the main data source may contain a hidden node that drives functionality such as conditional formatting or a calculated field. One common source of unexpected behavior is a hidden main data source or external data node that contains incorrect information.

You can debug these types of errors by creating a single debug form view that displays the values of all nodes across all data sources. When you preview form functionality in the InfoPath designer, you can switch to this debug view to determine whether your application is setting the data source nodes correctly. When you create the view, you should configure the view properties so that the view does not appear on the Current View list. This will hide the view from end-users. You should also use labels in the form view to differentiate between different data sources.

To create a debug form view

  1. On the ribbon, click the Page Design tab.

  2. In the Views group, click New View.

  3. In the Add View dialog box, in the New view name box, type Debug and then click OK.

  4. At the top of the form view, type Main Data Source, the label for the main data source nodes.

  5. In the Fields task pane, drag the root node of your main data source into the form view, under the label that you previously added.

    Note

    If you are designing a SharePoint list template, click Show advanced view in the Fields task pane before dragging nodes into the form view.

  6. In the form view, underneath the nodes that you previously added, type the label for a secondary data source.

  7. In the Fields task pane, click the Fields list and then click that secondary data source.

  8. Drag the root node of the secondary data source into the form view, under the label that you previously added.

  9. Repeat Steps 6-8 for all other secondary data sources.

  10. In the Page Design tab of the ribbon, in the Views group, click Properties.

  11. In the View Properties dialog box, clear the Show on the View menu when filling out this form check box, as shown in Figure 1.

    Figure 1. Preventing the debug view from appearing on the View menu

    View Properties dialog box

  12. Click OK.

To access your debug view at run time, you could add a button control to your form view(s) that switches to the debug view. To prevent end-users from seeing the button, you could add conditional formatting that hides the view if the current user is not the form designer or some other person responsible for debugging. The built-in get-UserName function works well for this behavior.

To add a button control that switches to the debug view for certain users

  1. In the Page Design tab of the ribbon, in the Views group, select a view other than the debug view from the View list, and then place the pointer at the bottom of the view.

  2. On the Home tab, in the Controls group, click the icon to show more controls (at the lower right of the gallery), and then click Button.

  3. Right-click the button, and then click Button Properties.

  4. In the Button Properties dialog box, change the Label value to Debug, and then click OK.

  5. On the Home tab, in the Rules group, click Manage Rules.

  6. In the Rules task pane, click New, click Formatting, and then click the None link located under the Condition header.

  7. In the Condition dialog box, click the first list, and then click The expression.

  8. Change the expression in the text box to xdUser:get-UserName() != "UserName". Figure 2 shows how the Condition dialog box will appear.

    Figure 2. Setting conditional logic for the debug button

    Condition dialog box

  9. Click OK.

  10. In the Rules task pane, select the Hide this control check box.

  11. Click New again, click Action, click Add, and then click Switch views.

  12. In the Rule Details dialog box, click the View list, and then click Debug, as shown in Figure 3.

    Figure 3. Switching to the debug view

    Rule Details dialog box

  13. Click OK.

Debugging Code at Design Time

InfoPath 2010 includes Microsoft Visual Studio Tools for Applications, a version of Visual Studio that offers a development experience similar to Microsoft Visual Basic for Applications. Visual Studio Tools for Applications provides a streamlined Visual Studio IDE, and lets you use most of the .NET Framework objects compatible through the .NET Framework 3.5. You can add event handler stubs for an existing form template, access the InfoPath object model and System.xml in a form code file, and then program to the event framework accordingly, either with Visual Basic or C#.

Note

The Visual Studio Tools for Applications UI is slightly different for Visual Basic and C# custom code solutions. The following section points out these UI differences, when they affect the process.

At design time, Visual Studio Tools for Applications provides debugging capabilities that a developer would expect. You can add breakpoints, step through lines of code, and build solutions, such as you can with the Visual Studio IDE. However, Visual Studio Tools for Applications does not let you debug forms that are running in SharePoint Server. To debug InfoPath form code at run time in SharePoint Server, you would need Visual Studio, which is discussed in the next section.

To debug form code at design time with Visual Studio Tools for Applications

  1. In the ribbon, click the Developer tab.

  2. In the Code group, click Code Editor.

  3. In Visual Studio Tools for Applications, add a breakpoint somewhere, as shown in Figure 4.

    Figure 4. Adding a breakpoint to the form code file

    breakpoint in Code Editor

  4. Click the Debug menu and then click Start Debugging (or press F5), which starts the InfoPath preview.

  5. Edit the form in the InfoPath preview until the breakpoint is started.

  6. In Visual Studio Tools for Applications, click the Debug menu and then click Step Over (or press SHIFT+F8) to step through a line of code.

  7. To stop debugging and close the InfoPath preview, click the Debug menu and then click Stop Debugging (or press CTRL+ALT+BREAK).

Debugging Code in Server Forms at Run Time

The run-time code debugging experience for server forms is slightly different from the steps that were described in the previous section. Because the form template has already been deployed to the SharePoint Server, you will have to attach the SharePoint process in Visual Studio, not Visual Studio Tools for Applications. By using the process attached, you can open the form code file in Visual Studio and insert breakpoints accordingly. Then, you can open the form in a browser and debug the code file.

Your form solution must also have program database (PDB) files, which hold debugging and project status information. If the form template that contains custom code is administrator-deployed, (that is, it was uploaded to InfoPath Forms Services by a server administrator and then activated to a site collection) SharePoint Server will dynamically load those PDB files. However, you may need to publish the form template directly to the SharePoint Server (either as a site content type or directly to a form library), as a sandboxed solution. In this scenario, you must configure Visual Studio Tools for Applications to build PDB files for your form solution by outputting full debug information. This will embed those files in the form template, such as the project assembly.

To configure Visual Studio Tools for Applications to build PDB files for sandboxed solutions

  1. In Visual Studio Tools for Applications, click the Project menu and then click the properties option (for example, Hardware Request Properties).

  2. For a C# code solution, click the Build tab and then, at the bottom, click Advanced. In the Advanced Build Settings dialog box, click the Debug Info list and then click full, as shown in Figure 5.

    Figure 5. Outputting full debug information for C# code solutions

    Advanced Build Settings dialog box

  3. For a Visual Basic code solution, click the Compile tab and then click Advanced Compile Options. In the Advanced Compiler Settings dialog box, click the Generate debug information list and then click Full, as shown in Figure 6.

    Figure 6. Outputting full debug information for Visual Basic code solutions

    Advanced Compiler Settings dialog box

  4. Click OK.

  5. Click the Tools menu and then click Options.

  6. In the Options dialog box, in the area to the left, expand Debugging and then click General.

  7. Clear the Enable Just My Code (Managed only) check box.

  8. Select the Suppress JIT optimization on module load (Managed only) check box. Figure 7 shows how the Options dialog box may appear.

    Figure 7. Setting general options in Visual Studio Tools for Applications

    Options dialog box

  9. Click OK.

  10. Click the Build menu and then click the build option (for example, Build Hardware Request).

Once you have created the PDB files and deployed the form template to the SharePoint site, you can then attach the SharePoint process in Visual Studio. For form templates that have been administrator-deployed, you must attach to the w3wp process that is tied to the application pool hosting the form template. You can get the PID of the correct w3wp from the Worker Processes management feature in Internet Information Services (IIS) Manager. For templates that have been published directly to the SharePoint site as sandboxed solutions, you must attach to the SPUCWorkerProcess process.

To debug a sandboxed solution with Visual Studio 2010

  1. Start Visual Studio 2010.

  2. Click the Tools menu and then click Attach to Process.

  3. In the Attach to Process dialog box, click the SPUCWorkerProcess.exe process and then click Attach. Figure 8 shows this process listed in the Attach to Process dialog box.

    Note

    If you do not see this process listed in the Attach to Process dialog box, select the Show processes from all users and Show processes in all sessions check boxes.

    Figure 8. Attaching to the SPUCWorkerProcess process for sandboxed solutions

    Attach to Process dialog box

  4. Click the File menu, click Open, and then click File.

  5. In the Open File dialog box, locate your form code file (for example, FormCode.cs) and double-click it. By default, the form code file is located in %USERPROFILE%\Documents\InfoPath Projects\FormName.

  6. Within the form code file, add a breakpoint somewhere.

  7. In a browser session, navigate to the form library where the sandboxed solution is hosted and start the form in the browser.

  8. Edit the InfoPath form until the breakpoint is started and then step through lines of code as needed in Visual Studio 2010.

  9. To stop debugging, in Visual Studio 2010, click the Debug menu and then click Stop Debugging (or press SHIFT+F5).

Diagnostic Tools

There are several tools that let you investigate issues with your form solution, either with the template itself or the run-time experience on the SharePoint Server. This section reviews the most common tools you can use for diagnosing such issues.

Design Checker

The easiest way to detect problems with your form template is to use the Design Checker, which is built into the InfoPath designer and reports errors and warnings. Errors block publication of the form template, whereas warnings identify potential loss of functionality and experience degradation. If the form template is compatible with InfoPath Forms Services, the Design Checker can also verify the template on the SharePoint Server and report browser optimizations. You can get more details about an error, warning, or browser optimization by clicking the item in the Design Checker task pane.

To run the Design Checker for a form template that is compatible with InfoPath Forms Services

  1. In the ribbon, click the File tab.

  2. In the Info area, click Design Checker.

  3. In the Design Checker task pane, if the Verify on server check box is cleared, select that check box and then click Refresh. Figure 9 shows an example of the Design Checker task pane for a web browser form.

    Figure 9. Using the Design Checker

    web browser form

Event Viewer

Event Viewer monitors application, security, and system events and records those events in event logs on the SharePoint Server. You can use Event Viewer to troubleshoot potential server configuration and service errors.

Before you use Event Viewer, you must enable error logging for different InfoPath Forms Services categories. The category that you select will appear in the Event Viewer log if an error or warning occurs when reproducing the issue in your application. For example, a form template that cannot connect to an external data source will produce an entry in Event Viewer with the Runtime - Data Connections category. For InfoPath Forms Services issues, only errors and warnings are relevant. Therefore, select Warning as the least important event to report.

To enable logging of InfoPath Forms Services errors

  1. Start SharePoint 2010 Central Administration.

  2. On the home page, click Monitoring.

  3. In the Reporting area, click Configure diagnostic logging.

  4. Expand the InfoPath Forms Services category and select the appropriate check box, as shown in Figure 10.

    Note

    If you do not know the category for your issue, enable logging for all categories.

    Figure 10. Enabling logging of InfoPath Forms Services issues

    InfoPath Forms Services category

  5. Click the Least important event to report to the event log list and then click Warning.

  6. Click OK.

Event Viewer displays logged Items in chronological order, with the most recent event shown first. InfoPath Forms Services events are listed in the Applications and Services Logs area within the Microsoft view. You can sort the event list by clicking any of the columns. To view more details about the event, double-click the entry in the list to display the Event Properties dialog box.

To view issues with Event Viewer

  1. Start the Server Manager.

  2. In the area to the left, expand Diagnostics, Event Viewer, Applications and Services Logs, Microsoft, SharePoint Products, and Shared.

  3. Click the Operational view, as shown in Figure 11.

    Figure 11. Locating InfoPath Forms Services issues in Event Viewer

    Server Manager Operational view

SharePoint ULS Logs

A Unified Logging Service (ULS) trace log can provide more detail than an Event Viewer entry. A trace log contains the same information found in Event Viewer but also includes the stack trace. A new ULS log is created automatically on the SharePoint Server computer at set intervals (by default, every 30 minutes).

As with Event Viewer, you must enable issue logging for different InfoPath Forms Services categories. The category that you select will appear in the trace log when reproducing the issue. To obtain the most detailed information about an issue, you must enable verbose logging. The path of the trace logs is identified in the Trace Log area of the Diagnostic Logging page.

To enable logging of InfoPath Forms Services issues in ULS logs

  1. Start SharePoint 2010 Central Administration.

  2. On the home page, click Monitoring.

  3. In the Reporting area, click Configure diagnostic logging.

  4. Expand the InfoPath Forms Services category and select the appropriate check box.

    Note

    If you do not know the category for your issue, enable logging for all categories.

  5. Click the Least important event to report to the trace log list and then click Verbose, as shown in Figure 12.

    Figure 12. Enabling verbose logging for the ULS trace logs

    InfoPath Forms Services category

  6. Note the path of the trace logs in the Trace Log area. By default, trace logs are created in %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\14\LOGS.

  7. Click OK.

For easy viewing of SharePoint ULS logs, you can use the open source SharePoint ULS Log Viewer, which is available for download on CodePlex. The SharePoint ULS Log Viewer lets you filter issues by severity, category, and process.

IIS Logging

An Internet Information Services (IIS) log often contains more detail than an entry in Event Viewer, as well. An IIS log entry can determine who has visited a SharePoint site, what was viewed, and when the information was last viewed. You can also correlate an IIS log entry the information that is stored in the Event Viewer logs.

You can customize log settings for each web application on a SharePoint Server. Within Internet Information Services (IIS) Manager, you can configure the log file format (with the option to customize it as needed), set the directory where log files are stored, schedule the time period (for example, daily) for creating new log files, and even specify the maximum file size.

To configure log settings for a web application in Internet Information Services (IIS) Manager 7

  1. Start Internet Information Services (IIS) Manager.

  2. In the Connections area to the left, expand the server and then expand Sites.

  3. Click the appropriate web application.

  4. In the Features view, in the IIS area, double-click Logging. Figure 13 shows an example of the IIS log settings for a web application.

    Figure 13. Configuring IIS logging

    IIS Manager Features view

By default, log files are created in %SYSTEMDRIVE%\inetpub\logs\LogFiles. When you open a log file, the most recent activity will be located at the end of the file.

Conclusion

This article reviewed the best practices for investigating issues with SharePoint applications that use InfoPath 2010. Within the InfoPath designer, you can add a debug view that surfaces all nodes in both the main data source and any secondary data sources. This makes it easier to detect whether fields are being set correctly. For managed-code form solutions, you can use the debugging capabilities of Visual Studio Tools for Applications at design time or use Visual Studio for SharePoint Server forms at run time. There are also diagnostic tools that can discover issues with the form template or the run-time experience. They include the Design Checker, Event Viewer, SharePoint ULS logs, and IIS logs. The combination of debugging techniques and diagnostic tools gives developers an efficient means to quickly analyze problems with InfoPath form solutions.

Additional Resources

For more information, see the following resources:

About the Author

David Gerhardt manages a team at 3Sharp that develops solutions for clients using Microsoft SharePoint offerings and Office client applications. David has consulted with customers since the mid-‘90s and especially enjoys XML-related technologies. Since 2003, he has done lots of work with Microsoft InfoPath and authored the Developing InfoPath 2007 Managed-Code Solutions and Best Practices for Deploying InfoPath 2007 Form Templates to a Production Environment white papers. He also co-authored the book Building Content Type Solutions in SharePoint 2007 and has a blog site at http://blogs.3sharp.com/davidg.