Troubleshooting Application Diagrams 

When you are working in Application Designer, certain actions affect the application diagram as well as other distributed system diagrams. This topic describes certain conditions that result from these actions, their impact on associated items, and steps you can take to resolve these conditions.

The following list describes alert states that can appear on the application diagram as well as other issues that you might need to troubleshoot:

• Alert States on Application Diagrams

• Locked Application Diagrams

• Synchronization Issues

• Closing and Removing Application Diagrams

• Reverse-Engineering Web References in Class Libraries

For other areas that might require troubleshooting, see the following topics:

• Considerations for Reverse-Engineering in Existing Solutions

• Considerations for Renaming Applications on Application Diagrams

• Considerations for Implementing Applications

• Considerations for Deleting Applications from Application Diagrams

The following table describes alert states that can appear on the application diagram.

The following sections contain more information about the alert states that might appear:

• Error Alert States on Applications or Endpoints

• Warning States on Applications or Endpoints

Error alert states might appear on applications or endpoints under the following conditions:

• The System Definition Model (SDM) definition of an application or endpoint is missing.

  A red dashed outline appears on application or endpoint when its associated SDM metadata is missing. For example, this might occur if the SDM definition for an application or endpoint is missing from the associated application definition (.sdm) file or if the .sdm file no longer exists in the solution. For more information, see Overview of the System Definition Model (SDM).

  For implemented or reverse-engineered applications, if the .sdm file is deleted while the application diagram is closed, the .sdm file is regenerated with any SDM information that can be recreated from another source when you reopen the diagram. However, this regenerated .sdm file does not contain any information that was stored solely in the previously deleted .sdm file. Certain settings and constraints will also be lost if the .sdm file is deleted.

  For example, SDM information for Web content endpoints on an ASP.NET application is stored only in the .sdm file. If this file is deleted and then regenerated, these Web content endpoints are not reverse-engineered and appear with a red dashed outline when you reopen the diagram.

  Tip

  To resolve this condition, delete the application or endpoint definition from the application diagram. You can also undo deletion of the .sdm file.

  If you change the identity of an application definition, such as renaming the definition or changing the SDM document name, this information is stored only in the .sdm file and will not be recreated in a regenerated .sdm file. The definition on the application diagram and any references to it on system diagrams appear with a red dashed outline and will not be resolvable. However, a new application definition based on the regenerated .sdm file will appear on the application diagram so that you can reconnect other applications that reference the broken one.

  Tip

  To resolve this condition, delete the broken application definition from the application diagram. You can also undo deletion of the .sdm file.

• The project associated with an implemented application definition is missing or unloaded from the solution.

  A dashed red line outline appears on an implemented application definition and any of its connections if its project is missing or unloaded from the solution.

  Tip

  To resolve this condition, add the project back to the solution or reload the project. For more information, see How to: Reverse-Engineer Projects in Existing Solutions and How to: Unload and Reload Projects.

• A validation error exists on an application.

  A red error icon appears on the application. Validation errors appear in the Error List window so you can review and resolve them. For more information, see Error List Window.

Yellow warning states might appear on applications or endpoints under the following conditions:

• An .asmx file containing the Web service class definition inline was used to create a Web service provider endpoint.

  A warning icon appears on a Web service provider endpoint when an .asmx file containing the Web service class definition inline was used to create the endpoint.

  Tip

  To resolve this condition, the Web service must be defined within a single class definition in a separate code file or "code-behind" file. For more information, see Overview of ASP.NET Applications on Application Diagrams.

• Implementation did not succeed for a Web service consumer endpoint.

  A warning icon appears on the consumer endpoint because the Web reference could not be created. After resolving the cause, the consumer endpoint can be implemented.

  Tip

  To implement the consumer endpoint, select the Web service consumer endpoint, point to Implementation on the Diagram menu, and choose Implement. You can also right-click the endpoint and choose Implement.

  The following table describes scenarios that might produce this condition.

  Expand table

  Condition	To resolve this condition
  Consumer endpoint is connected to a Web service provider endpoint that has an operation referencing an undefined type.	Define the type on the Web service provider endpoint and then implement the consumer endpoint. For more information, see How to: Define Operation and Parameter Types for ASP.NET Web Services.
  Consumer endpoint is connected to an unimplemented Web service provider endpoint.	Implement the ASP.NET application with the Web service provider endpoint. Any connected but unimplemented consumer endpoints will be implemented automatically. Note Make sure that a WSDL file is also available at the specified WSDL location.
  An error occurred while attempting to download the WSDL file.	If the Web service provider is implemented and corresponds to an .asmx file in the solution, this condition might be due to run-time errors. To view these errors, open the test page by right-clicking the .asmx file in Solution Explorer and choosing View in Browser. After fixing the errors, right-click the consumer endpoint and refresh the Web reference.
  Web service provider endpoint claims to conform to Web Services Interoperability (WS-I) Basic Profile1 version 1.1 when it does not.	Look in the Web service class file for the following attribute: <WebServiceBinding(Name:="WebServiceName", ConformsTo:= WsiProfiles.BasicProfile1_1, EmitConformanceClaims:=True)> _ Choose one of the following: If you want the Web service to be compliant with WS-I Basic Profile, review the list of errors or warnings you need to resolve by opening the test page for the Web service's .asmx file. > [!TIP] > <P>To perform this task, right-click the .asmx file in Solution Explorer and choose <STRONG>View in Browser</STRONG>. After fixing the errors, right-click the consumer endpoint and refresh the Web reference.</P> <p>-OR-</p></li> <li><p>If you do not want the Web service to be compliant with WS-I Basic Profile, remove the <code>ConformsTo</code> and <code>EmitConformanceClaims</code> attributes from the Web service class file.</p></li> </ul></td> </tr> <tr class="odd"> <td><p>Cannot access the WSDL file because IIS or ASP.NET Development Server might not be running.</p></td> <td><p>Make sure IIS or ASP.NET Development Server is running. For more information, review the product documentation for your version of IIS and see <a href="https://msdn.microsoft.com/en-us/library/58wxa9w5(v=vs.80)">Web Servers in Visual Web Developer</a>.</p></td> </tr> <tr class="even"> <td><p>ASP.NET is not enabled for Microsoft Internet Information Services (IIS).</p></td> <td><p>Enable ASP.NET on IIS. For more information, review the product documentation for your version of IIS.</p></td> </tr> <tr class="odd"> <td><p>Web references to Unicode URLs are not supported on IIS versions prior to 6.0.</p></td> <td><p>Upgrade to IIS 6.0. For more information, review the product documentation for Microsoft Internet Information Services at <a href="https://go.microsoft.com/fwlink/?linkid=42196">https://go.microsoft.com/fwlink/?LinkID=42196</a> and Microsoft Windows Server 2003 Deployment Kit at <a href="https://go.microsoft.com/fwlink/?linkid=34154">https://go.microsoft.com/fwlink/?LinkID=34154</a>.</p></td> </tr> </tbody> </table> <sup>1</sup>WS-I Basic Profile is a specification containing recommendations for ensuring that Web services are compatible with each other. For more information about WS-I, see Interoperability Resources on MSDN online at [https://go.microsoft.com/fwlink/?LinkId=49585](https://go.microsoft.com/fwlink/?linkid=49585). The WSDL binding name and binding namespace do not match between a Web service provider and consumer endpoint. A warning ToolTip appears when you attempt to connect Web service endpoints whose WSDL binding name and binding namespace do not match. However, you are not prevented from making the connection. A project file does not compile or parse. A warning appears on an application when a project file cannot be parsed. The Error List window displays the name of the application, project file, and location of the line that does not compile or parse. Tip To resolve this condition, fix the parse or compile error in the specified file or undo the change that cause the parse or compile error. The language of the Web service class associated with a Web service provider endpoint does not match the language of the project that contains it. A warning icon appears on a Web service provider endpoint when the language of its Web service class file does not match the language of the application project that contains it. A warning also appears on the Web service consumer endpoint because no proxy class exists. Tip To resolve this condition, the language of a Web service must match the language of the Web service provider application. Locked Application Diagrams Under certain conditions, the application diagram might become locked and appear in a read-only state. The diagram will appear shaded, application definitions on the diagram will display padlocks, and changes cannot be made to the diagram. The application diagram becomes locked under the following conditions: A code or class file in the application project does not compile or parse. The diagram becomes locked and the Error List window lists one or more files that do not compile or parse and the location of those errors in those files. Tip To resolve this condition, fix the compile or parse errors in the specified files or undo the changes that caused the compile or parse errors. Changes to encrypted sections in configuration files were attempted; however, decrypting these sections was unsuccessful. When configuration file sections are encrypted, these sections must be decrypted in order to edit them. Otherwise, the diagram becomes locked and the Error List window indicates that the diagram is locked. Tip To resolve this condition, install the required decryption provider and key or manually decrypt the file. You might also need to close and reopen the application diagram. You can also remove the encrypted section from the configuration file; however, removing encrypted data also deletes it. For more information, see Considerations for Implementing Applications. For more information, see Encrypting Configuration Information Using Protected Configuration and Encrypting and Decrypting Configuration Sections. Changes on the application diagram cannot synchronize with other project files that remain checked in under source code control. The diagram becomes locked and the Error List window indicates that a synchronization error occurred because checkout was cancelled. Tip To resolve this condition, check out the necessary files so that they can synchronize with your changes, then close and reopen the application diagram. For more information, see System Definition Model (SDM) Documents Under Source Control. For example, this can occur when the .asmx file for a Web service is deleted and the source code control option is set to always check out the working file. To resolve this condition, check out the application definition (.sdm) file from the corresponding project as well as the application diagram (.ad) file, if not checked out. After performing this task, close and reopen the application diagram. The application diagram cannot be checked out for synchronization. When the application diagram is checked into source code control, the diagram becomes locked when source code control cannot check out the diagram for synchronization. This occurs when source code control settings are set to check out the server version of files, which reloads those files. However, SDM documents do not support reloading during synchronization, therefore, the diagram cannot be checked out and will lock. Tip To resolve this condition, close and reopen the diagram, which attempts to synchronize the diagram. To avoid this condition, change your source code control options to always check out the working folder version or check out the file prior to any operation that requires reloading the file. For more information, see System Definition Model (SDM) Documents Under Source Control. Checkout was cancelled by the user for .sdm files in application projects added to the solution from source code control. If a solution contains an application diagram (.ad) file, and projects (that were previously generated for applications on the application diagram) are added to the solution from source code control, Visual Studio either checks out the .sdm files in those projects automatically or prompts you to check them out, depending on your source code control settings. If checkout is cancelled for these .sdm files, the diagram becomes locked if it is open or the next time it is opened. Tip To resolve this condition, close the diagram, check out the .sdm files manually, and then reopen the diagram. You can also check out the .sdm files when you reopen the diagram. To avoid this condition, do not cancel checkout if you are prompted to check out the .sdm files. For more information, see System Definition Model (SDM) Documents Under Source Control. Following checkout cancellation by the user for a Windows application project containing a Web reference to a renamed Web service provider endpoint on the application diagram, checkout was cancelled by the user for the App.config and Settings.settings files associated with that Windows project. When a Web service provider endpoint that is associated with a Web reference in a Windows application project is renamed, Visual Studio either checks out the Windows application project automatically or prompts you to check it out, depending on your source code control settings, so that the Web reference can be updated. For more information, see Overview of ASP.NET Applications on Application Diagrams. If checkout is cancelled for the project, the .asmx file and class file associated with the Web service provider endpoint revert to their previous names. Visual Studio then attempts to check out or prompts you to check out the App.config and Settings.settings files associated with the project. If checkout is cancelled by the user for these files, the application diagram becomes locked if it is open or the next time it is opened. Tip To resolve this condition, close the diagram and check out the required files manually before reopening the diagram or when you reopen the diagram. To avoid this condition, do not cancel checkout if you are prompted to check out the App.config and Settings.settings files. When you accept checkout, any uppercase characters in the name of the Web service provider endpoint are changed to lowercase. Getting the latest version of an SDM document from source code control while the application diagram (.ad) file is open. Performing this operation requires reloading the application diagram and might cause these files to become unsynchronized. If this operation is performed while the application diagram is open, the application diagram becomes locked. For more information, see System Definition Model (SDM) Documents Under Source Control. Tip To resolve this condition, close the diagram and then reopen it. An application on the application diagram was implemented using a custom template that generated an application definition (.sdm) file. Such templates are typically created from projects associated with applications on the application diagram. Using these templates creates a conflict between the application definition (.sdm) file generated by the template and the one that Application Designer attempts to create during the implementation process. Tip To resolve this condition, close the diagram, delete the .sdm file, and reopen the diagram. A Web service project with Web Services Enhancement (WSE) settings was reverse-engineered or opened in a solution containing an application diagram when WSE is not installed. The diagram becomes locked when a Web service project with WSE settings is opened or reverse-engineered in a distributed system solution on a computer that does not have WSE installed. Tip To resolve this condition, close the diagram, install WSE, and then reopen the diagram. For more information, see Application Types and Prototypes for Defining Applications and Considerations for Reverse-Engineering in Existing Solutions. The application diagram or a project was modified while code was running. The diagram becomes locked when you attempt to modify the application diagram or projects in the solution while code is running, for example, when the Visual Studio Debugger is running. Adding a new distributed system diagram, such as a system diagram, and performing actions on that diagram while code is running causes Visual Studio to stop responding. Tip To resolve this condition, stop code execution, for example, by closing the debugger. To avoid this condition, stop code execution before adding a new distributed system diagram or before performing actions on the diagram. The application diagram or any other System Definition Model (SDM) file was modified outside the designer. The application diagram becomes locked when changes are made to the application diagram or any other SDM file outside of the corresponding designer. Tip To resolve this condition, close and reopen the application diagram. An attempt to close the solution occurred during a designer operation. The application diagram becomes locked when an attempt to close the solution was made during a designer operation. For example, this can occur when changes to the solution are automatically retrieved from source code control upon checkout. Tip To resolve this condition, close the diagram, and then close and reopen the solution. Synchronize your solution and project files with the latest versions under source code control, and then reopen the diagram. You might be prompted to save your solution before closing; however, saving the solution might require you to manually merge items in your solution in order to synchronize your solution. Merging SDM documents is generally not recommended. For more information, see Concurrent Checkout and Changes to System Definition Model (SDM) Documents. Synchronization Issues Once an application that supports implementation has been implemented, its corresponding project is generated and appears in the solution. The System Definition Model (SDM) definition for the application is stored in an SDM document that has an .sdm extension and is included with the generated project. Whenever the application diagram is opened or closed, this .sdm file is synchronized with any relevant changes to project code. Therefore, if the application diagram or an .sdm file becomes unsynchronized with the code, you can resynchronize it by closing and reopening the application diagram. For more information, see Overview of the System Definition Model (SDM) and Synchronization Across System Definition Model (SDM) Documents. You can specify a separate configuration (.config) file for a particular element in the App.config or Web.config file for a Windows or ASP.NET application, respectively. After adding this configuration file, you can specify its location by adding the configSource attribute to the element in the App.config or Web.config file. This configSource attribute specifies a folder located in the directory where the App.config file is stored and the name of a valid configuration file. For example: <sessionState configSource="MyFolder\MyConfigFile.config" /> This additional configuration file must contain only the configuration information for that element and should not contain an <?xml…?> declaration tag. For example, MyConfigFile.config must contain only the following: <sessionState> <Add session state info here> </sessionState> Note If the added configuration file is moved to another location in the project, the configSource attribute is not automatically updated with that location. Therefore, you must manually update the configSource attribute with the new location. If the application diagram locks, make sure the added configuration file is properly formatted. Otherwise, try closing and reopening the application diagram. Renaming a WSDL file with an invalid extension does not immediately delete any connections to the Web service endpoint. To update the application diagram, close and reopen it. Closing and Removing Application Diagrams To remove the application diagram or a project from the solution, you must close the application diagram and all other open distributed system diagrams in the solution. Closing the application diagram requires saving and closing any open system or deployment diagrams. Tip To close the application diagram without saving it, first close any open system or deployment diagrams. Reverse-Engineering Web References in Class Libraries Web service references in class libraries might not reverse-engineer correctly in the following scenarios: Web service references in Visual Basic or Visual J# class libraries might not reverse-engineer correctly when the class library is built as the last step after copying the appropriate entries and adding the class library project reference to the consumer application. Tip To resolve this condition, right-click the Web reference in the class library, choose Update Web Reference, and then rebuild the class library. To avoid this condition, build the class library after adding new Web references but prior to copying the configuration file entries and adding the class library project reference. Web service references in Visual Basic or Visual J# class libraries might not reverse-engineer correctly when a consumer application references multiple class libraries and each of those libraries contains a Web reference to a different Web service. Tip To resolve this condition, you will need to update all the Web references in the affected class libraries. Right-click each Web reference in each class library affected, choose Update Web Reference, and then rebuild the entire solution. After adding new Web references and rebuilding the corresponding class libraries, rebuild the entire solution again to reverse-engineer these Web references. Web service references might not reverse-engineer correctly when a Windows and ASP.NET Web project both reference the same class library. Tip To resolve this condition, close the application diagram and remove the references to the shared class library from the Windows and ASP.NET Web projects. First add the class library reference to the ASP.NET Web project, open the application diagram, and then add the class library reference to the Windows project. For more information, see How to: Reference Class Libraries from Applications on Application Diagrams. See Also Tasks Troubleshooting System Diagrams Reference Considerations for Deleting Applications and Endpoints from System Diagrams Other Resources Designing Applications with Application Designer