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
* Add KeyPerFile config builder, similar in concept/behavior as the KeyPerFile config source in .Net Core.
* Add Json.NET to sample app via nuget reference.
* Update Readme.md with KeyPerFile.
* Remove documentation about msbuild magic to grab UserSecretsId, as this is no longer a feature.
* Add KeyPerFile to sample app.
* Add example secrets.xml in Readme.md
* Update Readme language.
Copy file name to clipboardExpand all lines: README.md
+35-3Lines changed: 35 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -87,13 +87,25 @@ builder, the json format for Core secrets is technically an implementation detai
87
87
There are three additional configuration attributes for this config builder:
88
88
*`userSecretsId` - This is the preferred method for identifying an xml secrets file. It works similar to .Net Core, which uses a 'UserSecretsId' project
89
89
property to store this identifier. (The string does not have to be a Guid. Just unique. The VS "Manage User Secrets" experience produces a Guid.) With this
90
-
attribute, the `UserSecretsConfigBuilder` will look in a well-known local location for a secrets file belonging to this identifier. In MSBuild environments,
91
-
the value of this attribute will be replaced with the project property $(UserSecretsId) in the output directory iff the initial value is '${UserSecretsId}'.
92
-
One of this attribute or the 'userSecretsFile' attribute is required.
90
+
attribute, the `UserSecretsConfigBuilder` will look in a well-known local location (%APPDATA%\Microsoft\UserSecrets\<userSecretsId>\secrets.xml in
91
+
Windows environments) for a secrets file belonging to this identifier.
93
92
*`userSecretsFile` - An optional attribute specifying the file containing the secrets. The '~' character can be used at the start to reference the app root.
94
93
One of this attribute or the 'userSecretsId' attribute is required. If both are specified, 'userSecretsFile' takes precedence.
95
94
*`optional` - A simple boolean to avoid throwing exceptions if the secrets file cannot be found. The default is `true`.
96
95
96
+
The next Visual Studio update will include "Manage User Secrets..." support for WebForms projects. When using this feature, Visual Studio will create an
97
+
empty secrets file outside of the solution folder and allow editing the raw content to add/remove secrets. This is similar to the .Net Core experience,
98
+
and currently exposes the format of the file - which as mentioned above - should be considered an implementation detail. A non-empty secrets file would look like this:
99
+
100
+
```xml
101
+
<?xml version="1.0" encoding="utf-8" ?>
102
+
<root>
103
+
<secretsver="1.0">
104
+
<secretname="secretFoo"value="valueBar" />
105
+
</secrets>
106
+
</root>
107
+
```
108
+
97
109
### AzureKeyVaultConfigBuilder
98
110
```xml
99
111
<addname="AzureKeyVault"
@@ -117,6 +129,26 @@ up connection information from the execution environment if possible, but you ca
117
129
this attribute to 'false', and secrets will be retrieved one at a time. This could also be useful if the vault allows "Get" access but not
118
130
"List" access. (NOTE: Disabling preload is incompatible with Greedy mode.)
<addkey="WINDIR"value="Will be replaced by 'Environment' in Strict and Greedy modes." />
22
23
<addkey="SYSTEMDRIVE"value="Will initally be replaced by 'Environment' in Strict and Greedy modes... but then superceded by 'Secrets' in the same modes." />
0 commit comments