StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>To do what I believe you want to do -- give your DLL a configuration file about which referencing assemblies need no nothing, you can[1] do something like the following code.</p> <pre><code>static class DllConfigurationFactory { public static Configuration GetConfigurationInstance() { string callingAssemblyPath = Assembly.GetCallingAssembly().Location ; string configFilePath = string.Concat( callingAssemblyPath , ".config" ) ; // getAttributes hurls with a multitude of exceptions FileAttributes attributes = File.GetAttributes( configFilePath ) ; bool isDirectory = ( (attributes&FileAttributes.Directory) == FileAttributes.Directory ? true : false ) ; if ( isDirectory ) { throw new FileNotFoundException() ; } // check for (and die with an SecurityException) if we dont' have read access new FileIOPermission( FileIOPermissionAccess.Read , configFilePath ).Demand() ; ExeConfigurationFileMap configMap = new ExeConfigurationFileMap(); configMap.ExeConfigFilename = configFilePath ; Configuration instance = ConfigurationManager.OpenMappedExeConfiguration(configMap, ConfigurationUserLevel.None); return instance ; } } </code></pre> <p>This factory method does the following:</p> <ol> <li><p>Finds the fully-qualified path of the assembly of the caller ((not that of the assembly containing the factory -- it, after all, might be in its own DLL).</p></li> <li><p>Tacks a ".config" on to the end of that path (thus yielding something like 'C:\usr/bin/local/foo/myAssembly.dll.config'.</p></li> <li><p>Ensures that that file exists and is readable, throwing an appropriate exception if not.</p></li> <li><p>Using that path as the source, instantiates a new instance of System.Configuration.Configuration and returns it to the caller.</p></li> </ol> <p><strong>Notes</strong></p> <ul> <li>Visual Studio will take an app.config in your DLL project and turn it into a foo.dll.config file, <strong>but</strong> your build/deploy/install system is responsible for copying it to the correct location(s). Visual Studio will put it in the bin directory for the DLL project, but it won't get copied any further up the line.</li> <li>You may need to do some experimenting -- you might need to include appropriate entries in the element, even for "standard" sections, since you're outside the normal config file hierarchy. I'm not sure on this, though. In my test, it found and loaded the element without a element defined, so you might have full access to the user and machine config files as well, but I don't make any guarantees about that. YMMV and all that.</li> </ul> <p>Good Luck!</p> <p>[1] TMTOWTDI as they say in Perl (There's more than one way to do it). You could also, for instance, create a custom section and park it in machine.config.</p> <p>And there's no requirement that you use the .Net configuration system for this: your factory method could slurp in any arbitrary XML and deserialize it into an object of your choice. This would give you a strongly typed, bound access to the configuration properties, albeit at the expense of automatic refreshing when the config file gets changed. Although...you could also just put a wrapper around the standard Configuration object that would provide the same thing.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload