Re: C# and org.apache.log4j.PropertyConfigurator - C# Discussion Boards

C# and org.apache.log4j.PropertyConfigurator

20-Sep-04 13:54

Please redirect your question to the appropriate forum, the ASP.NET[^] forum.

This posting is provided "AS IS" with no warranties, and confers no rights.

Software Design Engineer
Developer Division Sustained Engineering
Microsoft

[My Articles]

devvvy20-Sep-04 4:22

20-Sep-04 4:22

Hi people, is there anything in C# that resembles "org.apache.log4j.PropertyConfigurator"[^]?

I'm looking for something that can loads configuration files and do all the dirty work for me... It should..., for instance:

PropertyConfigurator configurator = new PropertyConfigurator();
configurator.load(configFilePath);
System.Collections.Hashtable params=configurator.ConfigParams;
...
IDictionaryEnumerator enum = params.GetEnumerator();
while ( myEnumerator.MoveNext() ) {
Console.WriteLine("\t{0}:\t{1}", myEnumerator.Key, myEnumerator.Value);
... do whatever else you'd like with the parameters ...
}
...
configurator.save(configFilePath);

If it's not part of dot-NET Framework, any Open Source you'd recommend? Thanks in advance.

Norman Fung

Heath Stewart20-Sep-04 6:46

20-Sep-04 6:46

There's already a configuration framework in place for the .NET Framework. Read about the IConfigurationSectionHandler interface at http://msdn.microsoft.com/library/en-us/cpref/html/frlrfSystemConfigurationIConfigurationSectionHandlerClassTopic.asp[^], as well as many configuration section handlers that are already implemented like NameValueSectionHandler[^] and others listed as implementations on the documentation for IConfigurationSectionHandler. Using this framework for configuration files unifies configuration - from runtime settings to application settings - for .NET applications.

To read more about how configuration files work in .NET as well as how to implement your own sections, read Configuring Applications[^] in the .NET Framework.

So, if you wanted a key/value pair configuration section, you could reuse the NameValueSectionHandler like so:

<configuration>
  <configSections>
    <section name="mysettings"
      type="System.Configuration.NameValueSectionHandler, System" />
  </configSections>
  <mysettings>
    <add key="opt1" value="myvalue" />
    <add key="opt2" value="somevalue" />
  </mysettings>
</configuration>

To use this in your code:

using System;
using System.Configuration;
 
class Test
{
  static void Main()
  {
    NameValueCollection settings = ConfigurationSettings.GetConfig("mysettings");
    foreach (DictionaryEntry setting in settings)
      Console.WriteLine("{0} = {1}", setting.Key, setting.Value);
  }
}

It's important that your configuration file match the executable name for your Windows Forms application or Windows Service (i.e., if your .EXE is named myapp.exe, then you're .config file is named myapp.exe.config) and be located in the same directory as your .EXE (this means that libraries - .dlls - use settings from the .exe that loads them), or use Web.config for ASP.NET applications and be located in the virtual host root (/), in the web application's root (/myapp, for example, which inherit settings from the virtual host's root Web.config), or in a sub-directory of your application (also named Web.config, but can only override some sections like <authorization>.

All .config files inherit settings from machine.config that is in the config sub-directory of your Framework installation for whichever version the application has loaded (or is loaded into).

You can find more about this from the link above.

This posting is provided "AS IS" with no warranties, and confers no rights.

Software Design Engineer
Developer Division Sustained Engineering
Microsoft

[My Articles]

Steven Campbell20-Sep-04 7:06

Steven Campbell

20-Sep-04 7:06

I recently did this, and you should note that it may not be enough to have type="System.Configuration.NameValueSectionHandler,System". With multiple versions of .NET installed, I found it to be necessary to expand this to include the strong version information, i.e.

"System.Configuration.NameValueSectionHandler, System, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"

my blog

Heath Stewart20-Sep-04 7:11

20-Sep-04 7:11

In some cases, yes it is necessary, but in most cases - including this case (which I've used countless times, as well as defined my own section handlers) - you can specify a partial name depending on the runtime settings on your machine (so long as an assembly is resolvable using a partial name). For example, if your application was loaded into an AppDomain that loaded .NET 1.1, it would use System.dll as you've described above.

If the AppDomain were created under .NET 1.0, the partial name would match System, Version=1.0.3300.0, Culture=neutral, PublicKeyToken=b77a5c561934e089.

In both cases, however, the runtime settings of your machine as well as enforcement of which runtime was loaded (using the <requiredRuntime> and <supportRuntime> runtime config elements) can change this behavior.

This posting is provided "AS IS" with no warranties, and confers no rights.

Software Design Engineer
Developer Division Sustained Engineering
Microsoft

[My Articles]

devvvy21-Sep-04 7:53

21-Sep-04 7:53

Thanks, steve.

Norman Fung

devvvy21-Sep-04 7:52

21-Sep-04 7:52

Thanks. That's very informative and I think it might just do. Our license files look like:

hash=.....
x509path=.....
serial=....

module1=enable&expiry='1/10/2005'&cal=10
module2=disable
...
...
...

Instead, we could:

<configuration>
<configSections>
<section name="securityinfo" type="System.Configuration.NameValueSectionHandler, System" />
<section name="licenseinfo" type="System.Configuration.NameValueSectionHandler, System" />
</configSections>
<licenseinfo>
<add key="encrypedhash" value="........." />
<add key="x509path" value="..." />
</licenseinfo>
<licenseinfo>
<add key="serial" value="..." />
<add key="module1" value="enable&expiry='1/10/2005&cal=10" />
<add key="module2" value="disable" />
<add key="module3" value="disable" />
</licenseinfo>
</configuration>

In application startup sequence:

NameValueCollection securityinfo = ConfigurationSettings.GetConfig("securityinfo");
NameValueCollection licenseinfo = ConfigurationSettings.GetConfig("licenseinfo");

Certificate cert=loadVendorCert(securityinfo);
byte[] encrypedhash=loadLicenseSectionHash(securityinfo);

//decrypt "encryptedhash" with public key from "cert":
byte[] hash=getLicenseSectionHash(cert, encrypedhash);

//Compare hash:
if( !ValidateLicenseSection(hash, licenseinfo)) {
... app config/license section has been tampered with...
} else {
... the rest of the startup sequence ...
}

Any thoughts...?

Norman Fung

Heath Stewart21-Sep-04 11:01

21-Sep-04 11:01

To what end? If you're trying to encrypt communication, simply install a SSL cert on the server with the "Server authentication" OID (from VeriSign[^], Thawte[^], or a handful of others) and encrypt HTTP over SSL (HTTPS). Done. ASP.NET honors this because the SSL handshaking happens before the HTTP protocol.

If you need a way to encrypt data, consider using what ASP.NET already exposes: read about the <machineKey> element, which is auto-generated by default in your machine.config file, and can be explicitly set in your machine.config file, your site Web.config (the one in the root, or /), and your application Web.config file.

For a simle way to generate validation (public) and decryption (private) keys, read How to create keys by using Visual C# .NET for use in Forms authentication[^].

Now, if neither of these scenarios work, then I would recommend you do what you're doing with a slight modification: group your sections together under a section group like so:

<configuration>
  <configSections>
    <sectionGroup name="mycompany">
      <section name="securityInfo" type="System.Configuration.NameValueSectionHandler, System" />
      <section name="licenseInfo" type="System.Configuration.NameValueSectionHandler, System" />
    </sectionGroup>
  </configSections>
  <!-- other stuff -->
  <mycompany>
    <securityInfo>...</securityInfo>
    <licenseInfo>...</licenseInfo>
  </mycompany>
</configuration>

Make sure to change ConfigurationSettings.GetConfig("securityInfo") to ConfigurationSettings.GetConfig("mycompany/securityInfo"), for example.

This helps group related sections together so as not to be confused with others, or just to form a better hierarchy of settings. For example, the <system.web> element is another section group with child elements handled by lots of different section handlers.

This posting is provided "AS IS" with no warranties, and confers no rights.

Software Design Engineer
Developer Division Sustained Engineering
Microsoft

[My Articles]

devvvy22-Sep-04 17:26

22-Sep-04 17:26

No, not SSL. The intended application is to generate application config files with licensing options and sign them. First you hash the licenseinfo section, then you use your private key to encrypt the hash. The encrypted hash would then become another key/value pair in securityinfo section of the generated application config file to be installed on client's machine.

Clients are given:
1. The application, the dlls and stuff
2. Generated application config file
3. Vendor certificate

On client side, application uses public key (from vendor certificate) to decrypt the hash - which is used to compare with hash computed on licenseinfo section to see if the settings has been tampered with... just dont fall asleep on me yet Sleepy | :zzz:

Norman Fung

Heath Stewart22-Sep-04 20:21

22-Sep-04 20:21

With specifics, I only offered suggestions for different scenarios.

If all you're looking to do is sign the .config file - an XML file - you might want ot take a look at my article, Using XML Digital Signatures for Application Licensing[^], which discusses the industry-support WS-Signature specification, support for which is in the .NET base class libraries (BCL).

This posting is provided "AS IS" with no warranties, and confers no rights.

Software Design Engineer
Developer Division Sustained Engineering
Microsoft

[My Articles]

devvvy22-Sep-04 20:39