You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/deployment/clickonce-and-application-settings.md
+20-20Lines changed: 20 additions & 20 deletions
Original file line number
Diff line number
Diff line change
@@ -17,39 +17,39 @@ manager: douge
17
17
ms.workload:
18
18
- "multiple"
19
19
---
20
-
# ClickOnce and Application Settings
20
+
# ClickOnce and application settings
21
21
Application settings for Windows Forms makes it easy to create, store, and maintain custom application and user preferences on the client. The following document describes how application settings files work in a ClickOnce application, and how ClickOnce migrates settings when the user upgrades to the next version.
22
22
23
-
The information below applies only to the default application settings provider, the <xref:System.Configuration.LocalFileSettingsProvider> class. If you supply a custom provider, that provider will determine how it stores its data and how it upgrades its settings between versions. For more information on application settings providers, see [Application Settings Architecture](/dotnet/framework/winforms/advanced/application-settings-architecture).
23
+
The information below applies only to the default application settings provider, the \<xref:System.Configuration.LocalFileSettingsProvider> class. If you supply a custom provider, that provider will determine how it stores its data and how it upgrades its settings between versions. For more information on application settings providers, see [Application settings architecture](/dotnet/framework/winforms/advanced/application-settings-architecture).
24
24
25
-
## Application Settings Files
26
-
Application settings consumes two files: *app*.exe.config and user.config, where *app* is the name of your Windows Forms application. user.config is created on the client the first time your application stores user-scoped settings. *app*.exe.config, by contrast, will exist prior to deployment if you define default values for settings. Visual Studio will include this file automatically when you use its **Publish** command. If you create your ClickOnce application using Mage.exe or MageUI.exe, you must make sure this file is included with your application's other files when you populate your application manifest.
25
+
## Application settings files
26
+
Application settings consumes two files: *\<app>.exe.config* and *user.config*, where *app* is the name of your Windows Forms application. *user.config* is created on the client the first time your application stores user-scoped settings. *\<app>.exe.config*, by contrast, will exist prior to deployment if you define default values for settings. Visual Studio will include this file automatically when you use its **Publish** command. If you create your ClickOnce application using *Mage.exe* or *MageUI.exe*, you must make sure this file is included with your application's other files when you populate your application manifest.
27
27
28
-
In a Windows Forms applications not deployed using ClickOnce, an application's *app*.exe.config file is stored in the application directory, while the user.config file is stored in the user's **Documents and Settings** folder. In a ClickOnce application, *app*.exe.config lives in the application directory inside of the ClickOnce application cache, and user.config lives in the ClickOnce data directory for that application.
28
+
In a Windows Forms applications not deployed using ClickOnce, an application's *\<app>.exe.config* file is stored in the application directory, while the *user.config* file is stored in the user's **Documents and Settings** folder. In a ClickOnce application, *\<app>.exe.config* lives in the application directory inside of the ClickOnce application cache, and *user.config* lives in the ClickOnce data directory for that application.
29
29
30
-
Regardless of how you deploy your application, application settings ensures safe read access to *app*.exe.config, and safe read/write access to user.config.
30
+
Regardless of how you deploy your application, application settings ensures safe read access to *\<app>.exe.config*, and safe read/write access to *user.config*.
31
31
32
-
In a ClickOnce application, the size of the configuration files used by application settings is constrained by the size of the ClickOnce cache. For more information, see [ClickOnce Cache Overview](../deployment/clickonce-cache-overview.md).
32
+
In a ClickOnce application, the size of the configuration files used by application settings is constrained by the size of the ClickOnce cache. For more information, see [ClickOnce cache overview](../deployment/clickonce-cache-overview.md).
33
33
34
-
## Version Upgrades
34
+
## Version upgrades
35
35
Just as each version of a ClickOnce application is isolated from all other versions, the application settings for a ClickOnce application are isolated from the settings for other versions as well. When your user upgrades to a later version of your application, application settings compares most recent (highest-numbered) version's settings against the settings supplied with the updated version and merges the settings into a new set of settings files.
36
36
37
37
The following table describes how application settings decides which settings to copy.
38
38
39
39
|Type of Change|Upgrade Action|
40
40
|--------------------|--------------------|
41
-
|Setting added to *app*.exe.config|The new setting is merged into the current version's *app*.exe.config|
42
-
|Setting removed from *app*.exe.config|The old setting is removed from the current version's *app*.exe.config|
43
-
|Setting's default changed; local setting still set to original default in user.config|The setting is merged into the current version's user.config with the new default as the value|
44
-
|Setting's default changed; setting set to non-default in user.config|The setting is merged into the current version's user.config with the non-default value retained|
41
+
|Setting added to *\<app>.exe.config*|The new setting is merged into the current version's *\<app>.exe.config*|
42
+
|Setting removed from *\<app>.exe.config*|The old setting is removed from the current version's *\<app>.exe.config*|
43
+
|Setting's default changed; local setting still set to original default in *user.config*|The setting is merged into the current version's *user.config* with the new default as the value|
44
+
|Setting's default changed; setting set to non-default in *user.config*|The setting is merged into the current version's *user.config* with the non-default value retained|
45
45
46
-
If you have created your own application settings wrapper class and wish to customize the update logic, you can override the <xref:System.Configuration.ApplicationSettingsBase.Upgrade%2A> method.
46
+
If you have created your own application settings wrapper class and wish to customize the update logic, you can override the \<xref:System.Configuration.ApplicationSettingsBase.Upgrade%2A> method.
47
47
48
-
## ClickOnce and Roaming Settings
49
-
ClickOnce does not work with roaming settings, which allows your settings file to follow you across machines on a network. If you need roaming settings, you will need either to implement an application settings provider that stores settings over the network, or develop your own custom settings classes for storing settings on a remote computer. For more information in settings providers, see [Application Settings Architecture](/dotnet/framework/winforms/advanced/application-settings-architecture).
48
+
## ClickOnce and roaming settings
49
+
ClickOnce does not work with roaming settings, which allows your settings file to follow you across machines on a network. If you need roaming settings, you will need either to implement an application settings provider that stores settings over the network, or develop your own custom settings classes for storing settings on a remote computer. For more information in settings providers, see [Application settings architecture](/dotnet/framework/winforms/advanced/application-settings-architecture).
50
50
51
-
## See Also
52
-
[ClickOnce Security and Deployment](../deployment/clickonce-security-and-deployment.md)
Copy file name to clipboardExpand all lines: docs/deployment/clickonce-and-authenticode.md
+12-12Lines changed: 12 additions & 12 deletions
Original file line number
Diff line number
Diff line change
@@ -26,21 +26,21 @@ ms.workload:
26
26
27
27
The following sections describe the different types of digital certificates used in Authenticode, how certificates are validated using Certificate Authorities (CAs), the role of time-stamping in certificates, and the methods of storage available for certificates.
28
28
29
-
## Authenticode and Code Signing
29
+
## Authenticode and code signing
30
30
A *digital certificate* is a file that contains a cryptographic public/private key pair, along with metadata describing the publisher to whom the certificate was issued and the agency that issued the certificate.
31
31
32
-
There are various types of Authenticode certificates. Each one is configured for different types of signing. For [!INCLUDE[ndptecclick](../deployment/includes/ndptecclick_md.md)] applications, you must have an Authenticode certificate that is valid for code signing. If you attempt to sign a [!INCLUDE[ndptecclick](../deployment/includes/ndptecclick_md.md)] application with another type of certificate, such as a digital e-mail certificate, it will not work. For more information, see [Introduction to Code Signing](http://go.microsoft.com/fwlink/?LinkId=179452).
32
+
There are various types of Authenticode certificates. Each one is configured for different types of signing. For [!INCLUDE[ndptecclick](../deployment/includes/ndptecclick_md.md)] applications, you must have an Authenticode certificate that is valid for code signing. If you attempt to sign a [!INCLUDE[ndptecclick](../deployment/includes/ndptecclick_md.md)] application with another type of certificate, such as a digital e-mail certificate, it will not work. For more information, see [Introduction to code signing](http://go.microsoft.com/fwlink/?LinkId=179452).
33
33
34
34
You can obtain a certificate for code signing in one of three ways:
35
35
36
36
- Purchase one from a certificate vendor.
37
37
38
38
- Receive one from a group in your organization responsible for creating digital certificates.
39
39
40
-
- Generate your own certificate by using the New-SelfSignedCertificate PowerShell cmdlet, or by using MakeCert.exe, which is included with the [!INCLUDE[winsdklong](../deployment/includes/winsdklong_md.md)].
40
+
- Generate your own certificate by using the New-SelfSignedCertificate PowerShell cmdlet, or by using *MakeCert.exe*, which is included with the [!INCLUDE[winsdklong](../deployment/includes/winsdklong_md.md)].
41
41
42
-
### How Using Certificate Authorities Helps Users
43
-
A certificate generated using New-SelfSignedCertificate or the MakeCert.exe utility is commonly called a *self-cert* or a *test cert*. This kind of certificate works much the same way that a .snk file works in the .NET Framework. It consists solely of a public/private cryptographic key pair, and contains no verifiable information about the publisher. You can use self-certs to deploy [!INCLUDE[ndptecclick](../deployment/includes/ndptecclick_md.md)] applications with high trust on an intranet. However, when these applications run on a client computer, [!INCLUDE[ndptecclick](../deployment/includes/ndptecclick_md.md)] will identify them as coming from an Unknown Publisher. By default, [!INCLUDE[ndptecclick](../deployment/includes/ndptecclick_md.md)] applications signed with self-certs and deployed over the Internet cannot utilize Trusted Application Deployment.
42
+
### How using certificate authorities helps users
43
+
A certificate generated using New-SelfSignedCertificate or the *MakeCert.exe* utility is commonly called a *self-cert* or a *test cert*. This kind of certificate works much the same way that a *.snk* file works in the .NET Framework. It consists solely of a public/private cryptographic key pair, and contains no verifiable information about the publisher. You can use self-certs to deploy [!INCLUDE[ndptecclick](../deployment/includes/ndptecclick_md.md)] applications with high trust on an intranet. However, when these applications run on a client computer, [!INCLUDE[ndptecclick](../deployment/includes/ndptecclick_md.md)] will identify them as coming from an Unknown Publisher. By default, [!INCLUDE[ndptecclick](../deployment/includes/ndptecclick_md.md)] applications signed with self-certs and deployed over the Internet cannot utilize Trusted Application Deployment.
44
44
45
45
By contrast, if you receive a certificate from a CA, such as a certificate vendor, or a department within your enterprise, the certificate offers more security for your users. It not only identifies the publisher of the signed software, but it verifies that identity by checking with the CA that signed it. If the CA is not the root authority, Authenticode will also "chain" back to the root authority to verify that the CA is authorized to issue certificates. For greater security, you should use a certificate issued by a CA whenever possible.
46
46
@@ -51,7 +51,7 @@ ms.workload:
51
51
52
52
To include a timestamp in an application server, a timestamp server must be available. For information about how to select a timestamp server, see [How to: Sign Application and Deployment Manifests](../ide/how-to-sign-application-and-deployment-manifests.md).
53
53
54
-
### Updating Expired Certificates
54
+
### Update expired certificates
55
55
In earlier versions of the .NET Framework, updating an application whose certificate had expired could cause that application to stop functioning. To resolve this problem, use one of the following methods:
56
56
57
57
- Update the .NET Framework to version 2.0 SP1 or later on Windows XP, or version 3.5 or later on Windows Vista.
@@ -60,12 +60,12 @@ ms.workload:
60
60
61
61
- Create a command-line assembly that updates the certificate. Step-by-step information about this process can be found at [Microsoft Support Article 925521](http://go.microsoft.com/fwlink/?LinkId=179454).
62
62
63
-
### Storing Certificates
63
+
### Store certificates
64
64
65
-
- You can store certificates as a .pfx file on your file system, or you can store them inside of a key container. A user on a Windows domain can have a number of key containers. By default, MakeCert.exe will store certificates in your personal key container, unless you specify that it should save it to a .pfx instead. Mage.exe and MageUI.exe, the [!INCLUDE[winsdkshort](../debugger/debug-interface-access/includes/winsdkshort_md.md)] tools for creating [!INCLUDE[ndptecclick](../deployment/includes/ndptecclick_md.md)] deployments, enable you to use certificates stored in either fashion.
65
+
- You can store certificates as a *.pfx* file on your file system, or you can store them inside of a key container. A user on a Windows domain can have a number of key containers. By default, *MakeCert.exe* will store certificates in your personal key container, unless you specify that it should save it to a *.pfx* instead. *Mage.exe* and *MageUI.exe*, the [!INCLUDE[winsdkshort](../debugger/debug-interface-access/includes/winsdkshort_md.md)] tools for creating [!INCLUDE[ndptecclick](../deployment/includes/ndptecclick_md.md)] deployments, enable you to use certificates stored in either fashion.
66
66
67
-
## See Also
68
-
[ClickOnce Security and Deployment](../deployment/clickonce-security-and-deployment.md)
0 commit comments