Dela via


Considerations for Implementing Applications

When you implement applications in Application Designer, be aware of the following considerations:

  • Installation Requirements

  • Security Considerations

  • Considerations Before Implementation

  • Troubleshooting Implementation

  • Considerations After Implementation

Installation Requirements

Before you implement certain applications, make sure you install the following items:

  • The programming languages that you selected for implementing applications.

  • The .NET Framework version (2.0, 3.0, or 3.5) that you selected for implementing applications.

  • Microsoft Visual Studio Tools for Office, if you want to implement Office applications. You will also need Microsoft Office 2003 or Microsoft Office 2007. For more information, see Installing Visual Studio Tools for Office.

  • To implement remote ASP.NET applications, install the .NET Framework version (2.0, 3.0, or 3.5) that you selected for those applications on the remote server.

Security Considerations

Certain security considerations apply when you configure specific settings for an application definition. For more information, see Applying Settings.

Unencrypted Settings in Application Configuration Files

When you implement an application or edit an implemented application, Visual Studio displays a security warning when it writes settings with sensitive data to the application's configuration file as clear text (unencrypted). These settings might also appear unencrypted when you edit them in the Properties window, Settings and Constraints Editor, or in the ComplexSetting Collection Editor, which you can open from the Settings and Constraints Editor.

The following table lists these settings and their location in the Settings and Constraints Editor as well as in the application's configuration file. The table also notes how Visual Studio displays these settings.

Note

You might need to add the appropriate resource before you can edit the corresponding setting. For more information, see Adding Resources. You can encrypt settings in configuration files. For more information, see Encrypting Configuration Information Using Protected Configuration and Troubleshooting Application Diagrams.

Setting name

Settings and Constraints Editor location

Application configuration file section

Settings

AppSettingsSection resource under Application Settings, Directory, and then Configuration.

appSettings

ConnectionStrings

ConnectionStringsSection resource under Application Settings, Directory, and then Configuration.

You can add this setting when you configure the database connection string for a database consumer endpoint. You can perform this task by using the Connection Properties dialog box, the Properties window, or the ComplexSetting Collection Editor.

Warning

The connection string appears as clear text in the Connection Properties dialog box and in the Properties window. The password appears as a masked string in the Connection Properties dialog box. It does not appear in the Properties window. The connection string appears as a masked string in the Settings and Constraints Editor. The entire string, including the password, appears as clear text in the ComplexSetting Collection Editor.

When you copy or include a database consumer endpoint in a custom prototype, Visual Studio copies the connection string, but not the password, as clear text to the new location. 

Warning

When you implement the database consumer application, Visual Studio writes the string as clear text to the application's configuration file. For more information, see How to: Configure Connections to External Databases.

connectionStrings

Password

IdentitySection resource under Application Settings, Directory, Configuration, and then SystemWebSectionGroup.

Visual Studio displays a masked string when you view this setting in the Settings and Constraints Editor.

identity

SqlConnectionString

SessionStateSection resource under Application Settings, Directory, Configuration, and then SystemWebSectionGroup.

sessionState

StateConnectionString

SessionStateSection resource under Application Settings, Directory, Configuration, and then SystemWebSectionGroup.

sessionState

Users

FormsAuthenticationCredentials resource under Application Settings, Directory, Configuration, SystemWebSectionGroup, AuthenticationSection, FormsAuthenticationConfiguration, and then FormsAuthenticationCredentials.

Visual Studio displays a masked string when you view this setting in the Settings and Constraints Editor.

Warning

The setting's value appears as clear text when you view or edit it in the ComplexSetting Collection Editor.

credentials under forms under authentication

Network

SmtpSection resource under Application Settings, Directory, Configuration, NetSectionGroup, and then MailSettingsSectionGroup.

Visual Studio displays a masked string when you view this setting in the Settings and Constraints Editor.

smtp under mailSettings

Security Handling for Application Configuration File Settings

Regardless of whether you encrypt settings that contain sensitive data, Visual Studio treats them in the following manner:

  • Visual Studio includes these settings when you copy the application definition or endpoint on the application diagram. When you implement the application, the setting will appear in the application's configuration file as clear text (unencrypted). Visual Studio displays a security warning when it writes these settings to the application's configuration file.

  • Visual Studio includes these settings when you include the application definition or endpoint in a custom prototype. When you implement the application, these settings will appear in the application's configuration file as clear text (unencrypted). Visual Studio displays a security warning when it writes these settings to the application's configuration file. Therefore, be aware of this consideration before distributing these files, avoid storing sensitive, confidential, or proprietary data in settings, or consider using encryption. For more information, see How to: Create Custom Prototypes from Configured Applications and Endpoints.

  • Visual Studio does not save these settings in the application definition (.sdm) or application diagram (.ad) file. For more information, see Overview of the System Definition Model (SDM).

  • Visual Studio does not make these settings available when you author user-defined constraints. For more information, see Constraining Application and Application Hosting Relationships.

Considerations Before Implementation

Before you implement applications, be aware of the following considerations:

  • Connect the applications that you want to implement. This enables Visual Studio to generate correctly any needed Web service client proxy classes.

  • Confirm that the Language, Project, Project Location Type, Template, and Target Framework properties contain the values that you need. You cannot modify these properties after implementation. For more information, see Considerations After Implementation.

    Note

    You might want to create or save a copy of the application diagram before implementation.

    For more information, see the following topics:

  • Visual Studio will update the Office Version setting on an Office application to the version specified in the Template property when you implement the application. 

  • Specify the project name you want before you implement an application. You can rename a Windows or Office project in Solution Explorer after implementation. However, renaming the project does not change its assembly name or its project folder name on disk. For example, if you rename a Windows project from "MyGeneratedName" to "MyRenamedProject", Visual Studio will compile that project as "MyGeneratedName.exe" instead of "MyRenamedProject.exe". Its project folder name will remain "MyGeneratedName" on disk.

  • Do not use the project name to set the project location for a Windows or Office application. After you implement the application, you can change the project location by using Windows Explorer.

  • Application definition names are case-sensitive while project names are not.

    Visual Studio will not implement a "duplicate" application when you implement applications of the same type and with names that differ only in case.

    To avoid this condition, change the name of the duplicate before implementation.

    For more information, see How to: Rename Applications on Application Diagrams.

  • If you want to implement ASP.NET applications that run using IIS on a local or remote server, you must have administrator permissions on that particular server. Otherwise, Visual Studio cannot implement the application.

    If you are running Visual Studio on Windows Vista, you can run Visual Studio as an administrator to implement these applications on a local server. 

    For more information, see Troubleshooting Implementation.

  • A conflict will occur when you implement a "duplicate" ASP.NET application that has the same name and location as a previously implemented and deleted application whose project still exists on disk.

    To avoid this conflict at implementation, rename the "duplicate" application before you implement it. Otherwise, see Troubleshooting Implementation.

  • Confirm that projects and their folders on disk have unique names, even if those projects have different names in Solution Explorer and their folders on disk have different parent folders.

    When you are ready to generate a deployment report, you can specify the location where Visual Studio will create a directory and copy the output files. However, Visual Studio will not include the projects' parent folders in that directory. Therefore, if a solution contains projects whose folders have the same name on disk, Visual Studio will create a single directory for projects that have the same name, even if they have different parent folders. This can cause output files to overwrite each other when Visual Studio copies them to that directory. For more information, see Location and Directory Structure of Deployment Output Files.

Troubleshooting Implementation

When you implement an application, you might encounter the following issues:

  • Visual Studio cannot implement ASP.NET applications that are set to run using IIS on a local or remote server.

    To implement ASP.NET applications that run using IIS on a local or remote server, you must have administrator permissions on that particular server.

    If you are running Visual Studio on Windows Vista, you can run Visual Studio as an administrator to implement these applications on a local server.

    For more information, choose How to: Choose Web Site Type for ASP.NET Applications.

  • Visual Studio cannot generate project files for an application.

    This issue might occur when applications are set to an incompatible custom project template. Application Designer supports only custom project templates created from Windows, Office, Web site, and ASP.NET Web application projects.

    To resolve this issue, select a standard project template or a different custom project template.

    This issue might also occur when applications are set to a .zip file that contains the custom project template.

    To resolve this issue, unzip the .zip file before you select the custom template.

    For more information, see Visual Studio Templates and Project Templates for Applications on Application Diagrams.

  • A conflict occurs when you implement an ASP.NET application that has the same name and location as another application that was implemented and deleted but whose project still exists on disk.

    To resolve this conflict, you can perform one of the following actions:

    • Create the project in another location.

    • Open the existing project and add it back to the solution.

    • Overwrite the existing project.

    To avoid this conflict, rename the application before implementation.

Considerations After Implementation

After you implement an application, be aware of the following considerations:

  • The root name of the associated project does not change when you change the application definition name. However, Visual Studio will synchronize project files, such as System Definition Model (SDM) documents and class files, with changes to the application definition. For more information, see Overview of Application Designer.

  • The Target Framework property of an ASP.NET, Windows, or Office application will appear empty and read-only in the Properties window after you implement the application. After implementation, you can view and change the application project's .NET Framework version in the project's properties.

    Note

    Be aware of certain considerations when you change the target framework version in the project's properties. For more information, see How to: Choose the .NET Framework Version for Applications.

  • The Office Version setting on an Office application will reflect the version that the application's Template property specified when you implemented the application. Though you can change this setting, application settings typically reflect the application's configuration. When you evaluate the application for deployment, Visual Studio will validate only the application's settings against the logical server's settings. No validation warning will appear if these settings do not match the version in the Template property. For more information, see Applying Settings.

See Also

Tasks

How to: Implement Applications on Application Diagrams

Other Resources

Implementing Applications on Application Diagrams