Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1733
  • Last Modified:

VB.NET 2013: Application Settings Vs. app.config

I am maintaining several applications.  Some of them use app.config files, the others use Application settings.  All of the applications use one or the other.  

It is my understanding that the app.config files are meant to be read-only from the application, where the Application settings can be modified from the application.  And that the app.config file has the benefit of being modifiable without needing a recompile.

-  Is my understanding correct?
-  Are there situations where using both would be good form?  For example, connection strings in the app.config (in case your database moves) and application settings that the user might change in the Application Settings?

Thanks in advance!

- Michael
0
mjs082969
Asked:
mjs082969
  • 2
1 Solution
 
it_saigeDeveloperCommented:
Basically App.config is your development environment's version of XYZ.exe.config.  When you compile your project, the IDE takes the app.config and turns it into xyz.exe.config.  If xyz.exe reads any setting using the System.Configuration classes, they will be read from xyz.exe.config.  The setting tab (Application settings), ultimately, has no relationship with either of these files (although, application-defined settings are stored in the xyz.exe.config).  Instead, the settings tab modifies a file called Settings.settings within your development environment (found in Show All Files --> My Project --> Settings.settings).  This file contains application-defined and user-defined settings that you can modify within your IDE.  The difference being that application-defined settings are read-only and user-defined settings are read-write enabled.  The configuration file generated from this is actually stored in the local profile of the user running your application (%USERPROFILE%\Local Settings\<Company Name>\<Assembly Name>\<version>\user.config).  These are known as My.Settings.

You are right in the thought that since they are xml files that the modification of the values contained within do not require a recompile (unless you do something the requires that you change the type associated with the value).

Check this blog for more answers:  http://ryanfarley.com/blog/archive/2004/07/13/879.aspx
MSDN on My.Settings:  http://msdn.microsoft.com/en-us/library/ms379611(VS.80).aspx

-saige-
0
 
mjs082969Author Commented:
Would it also be correct to say that to properly secure connection strings (which include the SQL server user name and password) that the connection string settings should be put into the app.config so that they may be encrypted?  I was under the impression that including them in the Application Settings was secure, because they would be in the compiled executable.  But the MSIL decompiler could be used to access this information....
0
 
it_saigeDeveloperCommented:
Choosing to place the connection string in the app.config does not make it any more or less secure than putting it into the registry, defining it as a constant or embedding it as a resource.

Choosing to place the connection string in the app.config is more about ease of accessibility from a development standpoint.  Regardless of the location you choose, I would definately encrypt the connection string.  Especially since the app.config is a xml file and everything is in clear text, e.g.  Sample app.config -
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
	<connectionStrings>
		<add name="CodeSampleCS.Properties.Settings.NORTHWNDConnectionString"
		    connectionString="TestToGetStringFrom App.config File"
		    providerName="System.Data.SqlClient" />
	</connectionStrings>
</configuration>

Open in new window


In short, no matter where you define sensitive information, encryption is usually recommended.

-saige-
0

Featured Post

Receive 1:1 tech help

Solve your biggest tech problems alongside global tech experts with 1:1 help.

  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now