Are strings in web.config compiled into the executable?-CodePudding

The storage admins where I work have bought and configured a new huge NAS system. Over time all current storage will migrate over there. This means that various network paths will change and this will break some in-house applications. We are reviewing a bunch of old apps the find the ones that use current paths like: \\old-file-system.company.com\Users so that we can modify them.

The old apps I have found all set these paths as strings in the project web.config file. My question is: are these paths compiled into the executable or are they read at runtime from this config file? Can we just modify the paths in the config files and not have to potentially rebuild them or upgrade them to newer .Net versions?

Cheers

CodePudding user response：

The values are read from the config file.

That is precisely the point of config files: to provide the ability to alter these values without needing to redeploy the application.

Note that this may need you to restart the app pool on IIS after making changes. Usually, it should automatically do that when it detects changes to the config file, but from historical experience this sometimes breaks without you noticing.

As an aside: don't forget about alternative config storage methods such as databases.

CodePudding user response：

yes, they are!

it will then depend on the code.

So, As a general rule no.

However, if you added new config items, then they may well not show up.

And if the code used the built in class in place of often used configuration manager to get values?

then you have to re-compile.

But, we also might use this:

vb.net:

   Dim rstData As New DataTable
    Using cmdSQL As New SqlCommand(strSQL, New SqlConnection(My.Settings.TEST3))
        cmdSQL.Connection.Open()
        rstData.Load(cmdSQL.ExecuteReader)
    End Using

So, in place of config manager, I often use My.Settings.TEST3.

(you get intel-sense). So on build, a class is created for some of those web config files.)

In c#, the above is:

Properties.Settings.Default.TEST3

And again often used due to intel-sense in place of configuration manager.

That class is re-build at compile time. So, if the code used to get web.config values is always configuration manager, then you would/should be ok.

However, if code used the built-in class like above?

The values ARE pulled from web.config at compile (build) time.

the class is called

c# Settings.Desinger.Cs

vb.net

Settings.Desinger.vb

So, I would check the above two files. That class tends to come from here:

Now the above when we add say a connection string to the project?

The above DOES update and put the above settings into web.config.

However, the class created (settings.Desing.cs/vb?

It is re-generated each time, and it DOES COPY the values from web.config.

So this means that after changing the settings in that project, you REALLY do have to re-build.

As noted, if one came from desktop land, then we just add settings to above, and use them. They actually are created in web config, but we often use the above - since as noted ANY new setting we add to the project now has intel-sense.

So, I would search the source code for:

vb:

My.Settings.TEST3

(search for My.Settings.)

or c#

Properties.Settings.Default.TEST3
(search for Properties.Settings.)

if either of above are used in the code? Then yes, you have to re-build since they are re-created at compile time into a class, and the values ARE pulled from web.config at compile time.

If configuration manager was used in all cases, then you are ok.

however, if the designer class was used, then a re-build is required, and worse a change in web.config will not be reflected in that class until a re-build.