Merge master into live

dotnet-desktop-guide/framework/winforms/additional-security-considerations-in-windows-forms.md

@@ -9,11 +9,13 @@ helpviewer_keywords:
 ms.assetid: 15abda8b-0527-47c7-aedb-77ab595f2bf1
 ---
 # Additional Security Considerations in Windows Forms
+
 .NET Framework security settings might cause your application to run differently in a partial trust environment than on your local computer. The .NET Framework restricts access to such critical local resources as the file system, network, and unmanaged APIs, among other things. The security settings affect the ability to call the Microsoft Windows API or other APIs that cannot be verified by the security system. Security also affects other aspects of your application, including file and data access, and printing. For more information about file and data access in a partial trust environment, see [More Secure File and Data Access in Windows Forms](more-secure-file-and-data-access-in-windows-forms.md). For more information about printing in a partial trust environment, see [More Secure Printing in Windows Forms](more-secure-printing-in-windows-forms.md).  
 
  The following sections discuss how to work with the Clipboard, perform window manipulation, and call the Windows API from applications that are running in a partial trust environment.  
 
 ## Clipboard Access  
+
  The <xref:System.Security.Permissions.UIPermission> class controls access to the Clipboard, and the associated <xref:System.Security.Permissions.UIPermissionClipboard> enumeration value indicates the level of access. The following table shows the possible permission levels.  
 
 |UIPermissionClipboard value|Description|  
@@ -22,9 +24,10 @@ ms.assetid: 15abda8b-0527-47c7-aedb-77ab595f2bf1
 |<xref:System.Security.Permissions.UIPermissionClipboard.OwnClipboard>|The Clipboard can be used with some restrictions. The ability to put data on the Clipboard (Copy or Cut command operations) is unrestricted. Intrinsic controls that accept paste, such as a text box, can accept Clipboard data, but user controls cannot programmatically read from the Clipboard.|  
 |<xref:System.Security.Permissions.UIPermissionClipboard.NoClipboard>|The Clipboard cannot be used.|  
 
- By default, the Local Intranet zone receives <xref:System.Security.Permissions.UIPermissionClipboard.AllClipboard> access and the Internet zone receives <xref:System.Security.Permissions.UIPermissionClipboard.OwnClipboard> access. This means that the application can copy data to the Clipboard, but the application cannot programmatically paste to or read from the Clipboard. These restrictions prevent programs without full trust from reading content copied to the Clipboard by another application. If your application requires full Clipboard access but you do not have the permissions, you will have to elevate the permissions for your application. For more information about elevating permissions, see [General Security Policy Administration](https://docs.microsoft.com/previous-versions/dotnet/netframework-4.0/ed5htz45(v=vs.100)).  
+ By default, the Local Intranet zone receives <xref:System.Security.Permissions.UIPermissionClipboard.AllClipboard> access and the Internet zone receives <xref:System.Security.Permissions.UIPermissionClipboard.OwnClipboard> access. This means that the application can copy data to the Clipboard, but the application cannot programmatically paste to or read from the Clipboard. These restrictions prevent programs without full trust from reading content copied to the Clipboard by another application. If your application requires full Clipboard access but you do not have the permissions, you will have to elevate the permissions for your application. For more information about elevating permissions, see [General Security Policy Administration](/previous-versions/dotnet/netframework-4.0/ed5htz45(v=vs.100)).  
 
 ## Window Manipulation  
+
  The <xref:System.Security.Permissions.UIPermission> class also controls permission to perform window manipulation and other UI-related actions, and the associated <xref:System.Security.Permissions.UIPermissionWindow> enumeration value indicates the level of access. The following table shows the possible permission levels.  
 
  By default, the Local Intranet zone receives <xref:System.Security.Permissions.UIPermissionWindow.AllWindows> access and the Internet zone receives <xref:System.Security.Permissions.UIPermissionWindow.SafeTopLevelWindows> access. This means that in the Internet zone, the application can perform most windowing and UI actions, but the window's appearance will be modified. The modified window displays a balloon notification when first run, contains modified title bar text, and requires a close button on the title bar. The balloon notification and the title bar identify to the user of the application that the application is running under partial trust.  
@@ -59,11 +62,13 @@ ms.assetid: 15abda8b-0527-47c7-aedb-77ab595f2bf1
 |<xref:System.Windows.Forms.MessageBox>|-   Calling the <xref:System.Windows.Forms.Form.Show%2A> method.|  
 
 ### Hosting Third-Party Controls  
+
  Another kind of window manipulation can occur if your forms host third-party controls. A third-party control is any custom <xref:System.Windows.Forms.UserControl> that you have not developed and compiled yourself. Although the hosting scenario is hard to exploit, it is theoretically possible for a third-party control to expand its rendering surface to cover the entire area of your form. This control could then mimic a critical dialog box, and request information such as username/password combinations or bank account numbers from your users.  
 
  To limit this potential risk, use third-party controls only from vendors you can trust. If you use third-party controls you have downloaded from an unverifiable source, we recommend that you review the source code for potential exploits. After you've verified that the source is non-malicious, you should compile the assembly yourself to ensure that the source matches the assembly.  
 
 ## Windows API Calls  
+
  If your application design requires calling a function from the Windows API, you are accessing unmanaged code. In this case the code's actions to the window or operating system cannot be determined when you are working with Windows API calls or values. The <xref:System.Security.Permissions.SecurityPermission> class and the <xref:System.Security.Permissions.SecurityPermissionFlag.UnmanagedCode> value of the <xref:System.Security.Permissions.SecurityPermissionFlag> enumeration control access to unmanaged code. An application can access unmanaged code only when it is granted the <xref:System.Security.Permissions.SecurityPermissionFlag.UnmanagedCode> permission. By default, only applications that are running locally can call unmanaged code.  
 
  Some Windows Forms members provide unmanaged access that requires the <xref:System.Security.Permissions.SecurityPermissionFlag.UnmanagedCode> permission. The following table lists the members in the <xref:System.Windows.Forms> namespace that require the permission. For more information about the permissions that are required for a member, see the .NET Framework class library documentation.  
@@ -80,7 +85,7 @@ ms.assetid: 15abda8b-0527-47c7-aedb-77ab595f2bf1
 
  If your application does not have permission to call unmanaged code, your application must request <xref:System.Security.Permissions.SecurityPermissionFlag.UnmanagedCode> permission, or you must consider alternative ways of implementing features; in many cases, Windows Forms provides a managed alternative to Windows API functions. If no alternative means exist and the application must access unmanaged code, you will have to elevate the permissions for the application.  
 
- Permission to call unmanaged code allows an application to perform most anything. Therefore, permission to call unmanaged code should only be granted for applications that come from a trusted source. Alternatively, depending on the application, the piece of application functionality that makes the call to unmanaged code could be optional, or enabled in the full trust environment only. For more information about dangerous permissions, see [Dangerous Permissions and Policy Administration](https://docs.microsoft.com/dotnet/framework/misc/dangerous-permissions-and-policy-administration). For more information about elevating permissions, see [General Security Policy Administration](https://docs.microsoft.com/previous-versions/dotnet/netframework-4.0/ed5htz45(v=vs.100)).  
+ Permission to call unmanaged code allows an application to perform most anything. Therefore, permission to call unmanaged code should only be granted for applications that come from a trusted source. Alternatively, depending on the application, the piece of application functionality that makes the call to unmanaged code could be optional, or enabled in the full trust environment only. For more information about dangerous permissions, see [Dangerous Permissions and Policy Administration](/dotnet/framework/misc/dangerous-permissions-and-policy-administration). For more information about elevating permissions, see [General Security Policy Administration](/previous-versions/dotnet/netframework-4.0/ed5htz45(v=vs.100)).  
 
 ## See also
 

dotnet-desktop-guide/framework/winforms/advanced/application-settings-architecture.md

@@ -9,13 +9,15 @@ helpviewer_keywords:
 ms.assetid: c8eb2ad0-fac6-4ea2-9140-675a4a44d562
 ---
 # Application Settings Architecture
+
 This topic describes how the Application Settings architecture works, and explores advanced features of the architecture, such as grouped settings and settings keys.
 
  The application settings architecture supports defining strongly typed settings with either application or user scope, and persisting the settings between application sessions. The architecture provides a default persistence engine for saving settings to and loading them from the local file system. The architecture also defines interfaces for supplying a custom persistence engine.
 
  Interfaces are provided that enable custom components to persist their own settings when they are hosted in an application. By using settings keys, components can keep settings for multiple instances of the component separate.
 
 ## Defining Settings
+
  The application settings architecture is used within both ASP.NET and Windows Forms, and it contains a number of base classes that are shared across both environments. The most important is <xref:System.Configuration.SettingsBase>, which provides access to settings through a collection, and provides low-level methods for loading and saving settings. Each environment implements its own class derived from <xref:System.Configuration.SettingsBase> to provide additional settings functionality for that environment. In a Windows Forms-based application, all application settings must be defined on a class derived from the <xref:System.Configuration.ApplicationSettingsBase> class, which adds the following functionality to the base class:
 
 - Higher-level loading and saving operations
@@ -36,6 +38,7 @@ This topic describes how the Application Settings architecture works, and explor
  [!code-vb[ApplicationSettings.Create#1](~/samples/snippets/visualbasic/VS_Snippets_Winforms/ApplicationSettings.Create/VB/MyAppSettings.vb#1)]
 
 ## Settings Persistence
+
  The <xref:System.Configuration.ApplicationSettingsBase> class does not itself persist or load settings; this job falls to the settings provider, a class that derives from <xref:System.Configuration.SettingsProvider>. If a derived class of <xref:System.Configuration.ApplicationSettingsBase> does not specify a settings provider through the <xref:System.Configuration.SettingsProviderAttribute>, then the default provider, <xref:System.Configuration.LocalFileSettingsProvider>, is used.
 
  The configuration system that was originally released with the .NET Framework supports providing static application configuration data through either the local computer's machine.config file or within an `app.`exe.config file that you deploy with your application. The <xref:System.Configuration.LocalFileSettingsProvider> class expands this native support in the following ways:
@@ -82,16 +85,18 @@ This topic describes how the Application Settings architecture works, and explor
 </configuration>
 ```
 
- For a definition of the elements within the application settings section of a configuration file, see [Application Settings Schema](https://docs.microsoft.com/dotnet/framework/configure-apps/file-schema/application-settings-schema).
+ For a definition of the elements within the application settings section of a configuration file, see [Application Settings Schema](/dotnet/framework/configure-apps/file-schema/application-settings-schema).
 
 ### Settings Bindings
+
  Application settings uses the Windows Forms data binding architecture to provide two-way communication of settings updates between the settings object and components. If you use Visual Studio to create application settings and assign them to component properties, these bindings are generated automatically.
 
  You can only bind an application setting to a component that supports the <xref:System.Windows.Forms.IBindableComponent> interface. Also, the component must implement a change event for a specific bound property, or notify application settings that the property has changed through the <xref:System.ComponentModel.INotifyPropertyChanged> interface. If the component does not implement <xref:System.Windows.Forms.IBindableComponent> and you are binding through Visual Studio, the bound properties will be set the first time, but will not update. If the component implements <xref:System.Windows.Forms.IBindableComponent> but does not support property change notifications, the binding will not update in the settings file when the property is changed.
 
  Some Windows Forms components, such as <xref:System.Windows.Forms.ToolStripItem>, do not support settings bindings.
 
 ### Settings Serialization
+
  When <xref:System.Configuration.LocalFileSettingsProvider> must save settings to disk, it performs the following actions:
 
 1. Uses reflection to examine all of the properties defined on your <xref:System.Configuration.ApplicationSettingsBase> derived class, finding those that are applied with either <xref:System.Configuration.ApplicationScopedSettingAttribute> or <xref:System.Configuration.UserScopedSettingAttribute>.
@@ -103,18 +108,21 @@ This topic describes how the Application Settings architecture works, and explor
  If you implement your own settings class, you can use the <xref:System.Configuration.SettingsSerializeAsAttribute> to mark a setting for either binary or custom serialization using the <xref:System.Configuration.SettingsSerializeAs> enumeration. For more information on creating your own settings class in code, see [How to: Create Application Settings](how-to-create-application-settings.md).
 
 ### Settings File Locations
+
  The location of the `app`.exe.config and *user*.config files will differ based on how the application is installed. For a Windows Forms-based application copied onto the local computer, `app`.exe.config will reside in the same directory as the base directory of the application's main executable file, and *user*.config will reside in the location specified by the <xref:System.Windows.Forms.Application.LocalUserAppDataPath%2A?displayProperty=nameWithType> property. For an application installed by means of ClickOnce, both of these files will reside in the ClickOnce Data Directory underneath %InstallRoot%\Documents and Settings\\*username*\Local Settings.
 
  The storage location of these files is slightly different if a user has enabled roaming profiles, which enables a user to define different Windows and application settings when they are using other computers within a domain. In that case, both ClickOnce applications and non-ClickOnce applications will have their `app`.exe.config and *user*.config files stored under %InstallRoot%\Documents and Settings\\*username*\Application Data.
 
  For more information about how the Application Settings feature works with the new deployment technology, see [ClickOnce and Application Settings](/visualstudio/deployment/clickonce-and-application-settings). For more information about the ClickOnce Data Directory, see [Accessing Local and Remote Data in ClickOnce Applications](/visualstudio/deployment/accessing-local-and-remote-data-in-clickonce-applications).
 
 ## Application Settings and Security
+
  Application settings are designed to work in partial trust, a restricted environment that is the default for Windows Forms applications hosted over the Internet or an intranet. No special permissions beyond partial trust are needed to use application settings with the default settings provider.
 
  When application settings are used in a ClickOnce application, the `user`.config file is stored in the ClickOnce data directory. The size of the application's `user`.config file cannot exceed the data directory quota set by ClickOnce. For more information, see [ClickOnce and Application Settings](/visualstudio/deployment/clickonce-and-application-settings).
 
 ## Custom Settings Providers
+
  In the Application Settings architecture, there is a loose coupling between the applications settings wrapper class, derived from <xref:System.Configuration.ApplicationSettingsBase>, and the associated settings provider or providers, derived from <xref:System.Configuration.SettingsProvider>. This association is defined only by the <xref:System.Configuration.SettingsProviderAttribute> applied to the wrapper class or its individual properties. If a settings provider is not explicitly specified, the default provider, <xref:System.Configuration.LocalFileSettingsProvider>, is used. As a result, this architecture supports creating and using custom settings providers.
 
  For example, suppose that you want to develop and use `SqlSettingsProvider`, a provider that will store all settings data in a Microsoft SQL Server database. Your <xref:System.Configuration.SettingsProvider>-derived class would receive this information in its `Initialize` method as a parameter of type <xref:System.Collections.Specialized.NameValueCollection?displayProperty=nameWithType>. You would then implement the <xref:System.Configuration.SettingsProvider.GetPropertyValues%2A> method to retrieve your settings from the data store, and <xref:System.Configuration.SettingsProvider.SetPropertyValues%2A> to save them. Your provider can use the <xref:System.Configuration.SettingsPropertyCollection> supplied to <xref:System.Configuration.SettingsProvider.GetPropertyValues%2A> to determine the property's name, type, and scope, as well as any other settings attributes defined for that property.
@@ -148,4 +156,4 @@ This topic describes how the Application Settings architecture works, and explor
 - [Application Settings Overview](application-settings-overview.md)
 - [Application Settings for Custom Controls](application-settings-for-custom-controls.md)
 - [ClickOnce and Application Settings](/visualstudio/deployment/clickonce-and-application-settings)
-- [Application Settings Schema](https://docs.microsoft.com/dotnet/framework/configure-apps/file-schema/application-settings-schema)
+- [Application Settings Schema](/dotnet/framework/configure-apps/file-schema/application-settings-schema)

dotnet-desktop-guide/framework/winforms/advanced/application-settings-for-windows-forms.md

@@ -9,9 +9,11 @@ helpviewer_keywords:
 ms.assetid: 64090a34-8556-4904-8ea0-20efe9f8c886
 ---
 # Application Settings for Windows Forms
+
 The Applications Settings feature of Windows Forms makes it easy to create, store, and maintain custom application and user preferences on the client. With Application Settings, you can store not only application data such as database connection strings, but also user-specific data, such as toolbar positions and most-recently used lists.  
 
 ## In This Section  
+
  [Application Settings Overview](application-settings-overview.md)  
  Discusses how to create and store settings data on behalf of your application and your users.  
 
@@ -32,7 +34,7 @@ The Applications Settings feature of Windows Forms makes it easy to create, stor
 
 ## Related topics
 
-[Windows Forms Configuration Section](https://docs.microsoft.com/dotnet/framework/configure-apps/file-schema/winforms/index)
+[Windows Forms Configuration Section](/dotnet/framework/configure-apps/file-schema/winforms/index)
 Documents the settings to enable High DPI support in Windows Forms Application starting with the .NET Framework 4.7.
 
 ## See also