MyApp.exe.Config & App.Config

Topics: Cryptography Application Block, Data Access Application Block, Enterprise Library Core, General discussion, Security Application Block
Mar 28, 2007 at 10:44 AM
help These Config files are getting me confused, can someone point me in the direction of the ladybird guide to config files. Specifically what is the relationship between App.Config, MyAppname.exe.Config and My.Settings. Visual Studio appears to use some random node generator in changing my carefully crafted config files and when I try to look at the config file for my Data Access using Enterprise Library Configuration it insists on adding a LocalSqlServer node whether I want one (which I don't) or not.
Also all the information I can find on encrypting connection strings keep directing me to the ASP.Net utility. Can a mere mortal that wants to write a desktop application (remember those?), also encrypt his/her Connection Strings (or any other part of the Config file)?
All help or direction would be greatly appreciated.
Mar 28, 2007 at 2:58 PM
Mike,

I couldn't find any authoritative documentation on App.config. But, the simple version is that when you build your application the app.config file in your solution is copied to the bin directory with a name based on the application file name. Hence if you application name is demo.exe, the app.config file gets copied to the bin directory with a name of demo.exe.config. They are the same files, just renamed during the build process.

As for My.Settings I did find an article that may help, but I am sure there are others out there:

http://msdn2.microsoft.com/en-us/library/ms379611(VS.80).aspx

If you don't like the ASP.NET Utility, you can programmatically encrypt sections of the config file as I mention here:

Encrypt Connection Strings AppSettings and Web.Config in ASP.NET 2.0 - Security Best Practices

but that is still a bit of a pain. I created a simple console app that does it for me.

The good news is that the Enterprise Library 3.0 Configuration Editor allows you to encrypt connection strings ( all configuration sections actually ) by the selection of a dropdown menu, which is what you are looking for. You can download the Feb 2007 CTP right now or wait a couple of weeks for the release of Enterprise Library 3.0 and do it then.

The LocalSqlServer connection string is in your machine.config, which is why it shows up. If you don't want it to show up, you need to delete it from your machine.config file.

Regards,

Dave

_________________________

David Hayden
Microsoft MVP C#
Apr 1, 2007 at 5:51 AM
David's got it pretty much nailed. I just wanted to clarify a little bit about app.config.

When running an .exe, the CLR will use the exe's name, slap ".config" on the end of it, and that'll be the config file. The Visual Studio guys had a useful thought - what if the exe name changes, do we have to rename the config file? So instead, they added "app.config", which at compile time they copy to the bin directory and change the name to match the exe. So the two files are essentially identical.

As for where the LocalSqlServer node is coming from, that's actually coming from machine.config. So if you want to get rid of it, you'll need to edit machine.config, which is really not recommended unless you really know what you're doing.
Apr 3, 2007 at 2:31 PM
Does anybody know what would cause the following code:

return ConfigurationManager.ConnectionStrings[name].ConnectionString

...to return information from the Machine.Config file instead of my app.config file? This is occurring in a VSTO Shared Addin project that I'm working on. Same exact code works fine in other projects, however. ???

Thx,
Allen
Apr 3, 2007 at 3:03 PM
Configuration Manager merges connections strings in both Machine.config and App.Config and makes them available to you in its ConnectionStrings Collection. This functionality is application independent and is how ConfigurationManager works. It does not vary from application to application.

Here it looks like you are requesting a connection string by its name, and obviously the named connection string is found in the Machine.config on the PC in question.

You can, however, do things in the app.config to have connection strings in machine.config removed from the ConnectionStrings Collection. For example, adding <clear /> at the beginning will remove connection strings from the ConnectionStrings collection before adding the connection strings in app.config, <remove name="xxx" /> will also remove existing connection strings:

<connectionStrings>
  <clear/>
  <add name="ConnectionString" connectionString="..." />
  <add name="ConnectionString1" connectionString="..." />
  <remove name="ConnectionString1" />
</connectionStrings>

My guess is that you are either working on different PC's with different machine.config settings or you are manipulating the ConnectionStrings Collection in app.config as mentioned above.

Regards,

Dave

_________________________

David Hayden
Microsoft MVP C#
Apr 5, 2007 at 7:57 PM
Edited Apr 5, 2007 at 7:59 PM
Dave,
I am only running only on 1 machine (my work desktop). I am not manipulating the ConnectionString collection. When I do a "? ConnectionStrings.Count" (in the problem app) I'm getting a count of 1. Printing it out shows:
Name="LocalSqlServer" connectionString="data source=.\SQLEXPRESS;Integrated Security=SSPI;AttachDBFilename=|DataDirectory|aspnetdb.mdf;User Instance=true" providerName="System.Data.SqlClient"

...which matches exactly with machine.config. I'm definitely not asking for the name 'LocalSqlServer' in my app.

I also happen to have 3 other (different) items in my app.config, but it isn't reading them at all.


Thx,
Allen
Apr 16, 2007 at 10:13 PM
Hi David.

I just downloaded EntLib 3.0 and I can't see how the Configuration Manager can encrypt sections of the app.config file. Can you give me some more detailed instructions??? I must be a little slow today! :-)

Mike


DavidHayden wrote:
Mike,

I couldn't find any authoritative documentation on App.config. But, the simple version is that when you build your application the app.config file in your solution is copied to the bin directory with a name based on the application file name. Hence if you application name is demo.exe, the app.config file gets copied to the bin directory with a name of demo.exe.config. They are the same files, just renamed during the build process.

As for My.Settings I did find an article that may help, but I am sure there are others out there:

http://msdn2.microsoft.com/en-us/library/ms379611(VS.80).aspx

If you don't like the ASP.NET Utility, you can programmatically encrypt sections of the config file as I mention here:

Encrypt Connection Strings AppSettings and Web.Config in ASP.NET 2.0 - Security Best Practices

but that is still a bit of a pain. I created a simple console app that does it for me.

The good news is that the Enterprise Library 3.0 Configuration Editor allows you to encrypt connection strings ( all configuration sections actually ) by the selection of a dropdown menu, which is what you are looking for. You can download the Feb 2007 CTP right now or wait a couple of weeks for the release of Enterprise Library 3.0 and do it then.

The LocalSqlServer connection string is in your machine.config, which is why it shows up. If you don't want it to show up, you need to delete it from your machine.config file.

Regards,

Dave

_________________________

David Hayden
Microsoft MVP C#

Apr 18, 2007 at 8:58 PM
I figured it out. I thought you could encrypt an individual encryption string as opposed to the whole section.

Mike

michaelloveusa wrote:
Hi David.

I just downloaded EntLib 3.0 and I can't see how the Configuration Manager can encrypt sections of the app.config file. Can you give me some more detailed instructions??? I must be a little slow today! :-)

Mike


DavidHayden wrote:
Mike,

I couldn't find any authoritative documentation on App.config. But, the simple version is that when you build your application the app.config file in your solution is copied to the bin directory with a name based on the application file name. Hence if you application name is demo.exe, the app.config file gets copied to the bin directory with a name of demo.exe.config. They are the same files, just renamed during the build process.

As for My.Settings I did find an article that may help, but I am sure there are others out there:

http://msdn2.microsoft.com/en-us/library/ms379611(VS.80).aspx

If you don't like the ASP.NET Utility, you can programmatically encrypt sections of the config file as I mention here:

Encrypt Connection Strings AppSettings and Web.Config in ASP.NET 2.0 - Security Best Practices

but that is still a bit of a pain. I created a simple console app that does it for me.

The good news is that the Enterprise Library 3.0 Configuration Editor allows you to encrypt connection strings ( all configuration sections actually ) by the selection of a dropdown menu, which is what you are looking for. You can download the Feb 2007 CTP right now or wait a couple of weeks for the release of Enterprise Library 3.0 and do it then.

The LocalSqlServer connection string is in your machine.config, which is why it shows up. If you don't want it to show up, you need to delete it from your machine.config file.

Regards,

Dave

_________________________

David Hayden
Microsoft MVP C#


Apr 19, 2007 at 9:49 AM
michaelloveusa,
Could you share your encryption illumination, as I'm still struggling with it. I'm also unclear as to the relationship between the Configuration information manipulated and used by the .Net Framework (incl. Visual Studio) and the Patterns & Practices libraries. If I encrypt my connection string, will the DatabaseFactory.CreateDatabase() method still be able to figure out where to connect?
I'm beginning to really dislike these config files, I've also been looking at .Net remoting and it's even worse as all the examples include references to XML nodes, which are obviously critical, but are nowhere explained.

Any help and direction would be greatly appreciated - or maybe I should just write my own wrapper for the old style .ini files (anyone else remember those :o)

Mike the lost
May 14, 2007 at 3:58 PM
Take a look here: Using Encrypted Connection Strings.

Charly