Troubleshooting Application Diagrams
When working in Application Designer, certain actions affect the application diagram as well as other distributed system diagrams. This topic describes conditions that result from performing these actions, their impact on associated items, and steps you can take to resolve these conditions.
The following list describes alert states that can arise from these actions as well as other areas in which you might need to troubleshoot issues:
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 Deleting Applications from Application Diagrams
Alert States on Application Diagrams
The following table describes alert states that can appear on the application diagram.
Alert state |
Possible cause |
|---|---|
Red dashed outline |
Application or endpoint definition shapes appear with red dashed outlines when their links to the following items are broken:
Application or endpoint definitions with these broken links are also called "orphaned". |
Red error (X) |
A validation error exists on an application definition. This icon appears below the application type name on the application definition shape. |
Yellow warning (!) |
One of the following:
|
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 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.
An application or endpoint definition appears orphaned when its SDM metadata is missing. This occurs if the SDM metadata is missing from the application definition (.sdm) file or if the application definition's .sdm file no longer exists in the solution. For more information about SDM, see Overview of the System Definition Model (SDM).
For example, if you delete an application definition's .sdm file while the application diagram remains closed, the application definition and any of its uses as members on system diagrams will appear orphaned. When you reopen the application diagram, Visual Studio regenerates the .sdm file with any SDM information that it can recreate from another source. Visual Studio will also recreate a new application definition on the application diagram based on the regenerated .sdm file.
Note
The regenerated .sdm file will not contain any information that is stored only in the previously deleted .sdm file. Certain information, such as certain settings and constraints and changes to the application definition's identity (its name, SDM document name, culture, or version) will be lost. For example, SDM information for Web content endpoints on an ASP.NET application is stored only in the .sdm file. If you delete the .sdm file, Visual Studio regenerates it when you reopen the application diagram. However, Visual Studio will not reverse-engineer the Web content endpoints. These endpoints will remain orphaned.
To resolve an orphaned definition, restore the .sdm file. If you cannot restore the .sdm file, add any new endpoints that you need to the new definition and reconnect application definitions from the orphaned definition to the new definition. If your system diagrams contain orphaned members resulting from the orphaned definition, repair those members by associating them with new definition. Finally, delete the orphaned definition from the application diagram. For more information, see How to: Repair Orphaned Members in Application Systems.
The project for an implemented application definition is missing or unloaded from the solution.
The implemented application definition and its connections appear orphaned when its project is missing or unloaded from the solution.
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.
The project for an implemented application definition is no longer available.
The implemented application definition and its connections appear orphaned, and its project appears unloaded in your solution.
To resolve this issue, remove the unloaded project from your solution and delete the application definition from the application diagram.
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.
Warning States on Applications or Endpoints
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 .NET Web Service provider endpoint.
A warning icon appears on a .NET Web Service provider endpoint when an .asmx file containing the Web service class definition inline was used to create the endpoint.
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.
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.
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 .NET Web Service provider endpoint 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
To perform this task, right-click the .asmx file in Solution Explorer and choose View in Browser. After fixing the errors, right-click the consumer endpoint and refresh the Web reference.
-OR-
If you do not want the Web service to be compliant with WS-I Basic Profile, remove the ConformsTo and EmitConformanceClaims attributes from the Web service class file.
Cannot access the WSDL file because IIS or ASP.NET Development Server might not be running.
Make sure IIS or ASP.NET Development Server is running. For more information, review the product documentation for your version of IIS and see Web Servers in Visual Web Developer.
ASP.NET is not enabled for Microsoft Internet Information Services (IIS).
Enable ASP.NET on IIS. For more information, review the product documentation for your version of IIS.
Web references to Unicode URLs are not supported on IIS versions prior to 6.0.
Upgrade to IIS 6.0. For more information, review the product documentation for Microsoft Internet Information Services at https://go.microsoft.com/fwlink/?LinkID=42196 and Microsoft Windows Server 2003 Deployment Kit at https://go.microsoft.com/fwlink/?LinkID=34154.
1WS-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.
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.
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.
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.
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.
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.
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.
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.
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 .NET 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 .NET 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.
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 .NET 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.
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.
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.
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.
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.
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.
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.
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 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.
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 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.
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.
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 Members and Endpoints from Application Systems