Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Version 3.0.0 breaks directoryPath on network paths #224

Open
davisnw opened this issue Jun 28, 2023 · 0 comments
Open

Version 3.0.0 breaks directoryPath on network paths #224

davisnw opened this issue Jun 28, 2023 · 0 comments

Comments

@davisnw
Copy link

davisnw commented Jun 28, 2023

Version 3.0.0 breaks directoryPath on network paths

I've been using https://www.nuget.org/packages/Microsoft.Configuration.ConfigurationBuilders.KeyPerFile/2.0.0 successfully for some time where directoryPath is set to a network path (e.g. directoryPath="\\blah.blah.com\blah\AppSettings")

However, upon updating to https://www.nuget.org/packages/Microsoft.Configuration.ConfigurationBuilders.KeyPerFile/3.0.0, I get the YSOD error

Parser Error Message: The configBuilder 'KeyPerFileAppSettings' failed while processing the configuration section 'appSettings'.: 'KeyPerFileAppSettings' Initialization Error: 'directoryPath' does not exist.

If I downgrade to version 2.0.0, it works again.

This is an ASP.NET WebForms application targeting .NET Framework 4.8

Functional Impacts

Application will not run when directoryPath in web.config is set to a network path.

Minimal repro steps

  1. Create a ASP.NET Web application targeting .NET Framework 4.8
  2. Add the version 2.0.0 nuget package Microsoft.Configuration.ConfigurationBuilders.KeyPerFile
  3. Edit the web.config to configure the KeyPerfile configuration with directoryPath attribute set to a network path (be sure the path actually exists, the application pool identity or current user has permissions, and the file for the corresponding appsetting key exists)
    <configuration>
      <configSections>
        <section name="configBuilders" 
             type="System.Configuration.ConfigurationBuildersSection, 
             System.Configuration, Version=4.0.0.0, Culture=neutral, 
             PublicKeyToken=b03f5f7f11d50a3a"
             restartOnExternalChanges="false" requirePermission="false" />
      </configSections>
      <configBuilders>
        <builders>
          <add name="KeyPerFileAppSettings"
             mode="Strict"
             directoryPath="\\mynetworkpath\subpath1\AppSettings"
             type="Microsoft.Configuration.ConfigurationBuilders.KeyPerFileConfigBuilder, Microsoft.Configuration.ConfigurationBuilders.KeyPerFile" />
        </builders>
      </configBuilders>
      <appSettings configBuilders="KeyPerFileAppSettings">
        <add key="TestKey1" value="" />
     </appSettings>
     </configuration>
  4. Observe that the key loads successfully with version 2.0.0 of the package
  5. Upgrade the NuGet package to version 3.0.0, rebuild, and run. Observe that now the network path is not found.

Expected Result

Keys are successfully loaded from files under the specified network path (assuming the path exists and appropriate application pool identity permissions are applied to the network path).

Actual Behavior

Configuration errors out with:

Parser Error Message: The configBuilder 'KeyPerFileAppSettings' failed while processing the
configuration section 'appSettings'.: 'KeyPerFileAppSettings' 
Initialization Error: 'directoryPath' does not exist.

However, in fact the network path actually does exist.

Further Technical Details

I did not find any explicit mention of directoryPath support in the V3 updates of README.md.

However, I wonder if it could be related to the new "fallback" functionality:

  • Utils.MapPath - This was somewhat broken in ASP.Net scenarios previously. It should now reliably go against Server.MapPath() in ASP.Net scenarios. It has also been updated to fall back against the directory of the config file being processed when resolving the app root in the case of a Configuration object being created by ConfigurationManager.OpenConfiguration* API's rather than being part of a fully-initialized runtime configuration stack.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant