VB dotnet application runs without app.exe.config file??

[mmcd79]

I built a VB.net application that makes use of a machine level DB
connection string setting, and a user level starting location setting.

The machine level setting and the default user based setting is of
course stored in the app.exe.config file located in the same directory
as the exe. Upon closing the form, I save the user setting which then
creates a user.config file in the appdata directory in my profile.

This is all well and good. My issue is this:

I was testing something, and removed my app.exe.config file from the
directory that my application is in. I also deleted the user.config
file that was created after first successful runs. Essentially, my
app has no config file to reference, so it should bomb on load,
right? (my app connects to a seperate SQL server to gather some data
that is presented on load.).

I loaded up the app, expecting an error, and for some reason, it did
not error!!! It loaded as if it used the default starting location I
specified in the config (0,0), and it connected to the database and
returned data with no problem!! How is this possible?!

The one thing to note is I have a local sql instance containing
roughly the same information as the production sql box. The only
difference is the prod sql server has a differently named database
than what I have local. With the config file, it connects to the
production sql server and pulls data from a db called "DB1". Without
the config file, the program connects to my local sql instance and
pulls data from a db called "DB2". I can't for the life of me
understand how this is happening.

 

[Daniel Bass]

I suppose you've already searched your code for "DB1"? ;-)

 

[Michel Posseth [MCP]]

The default settings are compiled in the assembly manifest

so even without a config file , it will stil use the default values , that
you specified in the designer ,
however if you change the values in the config file it wil use these values


handy huh ??? ;-)

regards

Michel

 

[mmcd79]

OK, so where is this assembly manifest? I don't find this handy.
When I deploy this app, if the config file is missing, I don't want
the program just trying to connect to some 'cached' value. I want it
to bomb like it is supposed to. Can I remove this from the manifest?

Here's another thing to note. I coded this program with only one
configuration setting initially, which was the DB string. I was
running this on my test computer fine. Because I did not code a
specific starting point, the app loads using the default setting which
I set via the IDE to "windows default". The application started as
such (near the middle of the screen).

I then made the changes to remember the starting location and added
the user based setting with default values 0,0. My application now
loads at 0,0. On subsequent opens, it will load in the last location
I had it. This works fine. Here's where it gets strange though.

On my test computer that ran the previous version of the app (without
starting location in config) will run the new EXE without a config
file, and it will default to 0,0. This is the issue I first
described.

I put v2 of the program on a new computer (one that has never ran any
version of the app before) and tried to run it without the config
file. The app bombed hardcore because it could not find the "starting
point" setting from the config file!!

On machine 1 (with previous copy of program), the app will run fine
without config file and run as if it "knew" about the starting
location setting even without the config file. But the new machine,
the program behaves as expectedly.. it doesn't detect the config file
setting, so it bombs.

This is weird!

 

[Michel Posseth [MCP]]

If you want the program to crash or behave different wel this is easy just
set a default value in the settings designer wich you detect at runtime
for the connection string you could set #var:notset# for instance for
numeric values you could use -1 or another value that you may detect as an
invalid parameter and detect this

I put v2 of the program on a new computer (one that has never ran any
version of the app before) and tried to run it without the config
file. The app bombed hardcore because it could not find the "starting
point" setting from the config file!!

On machine 1 (with previous copy of program), the app will run fine
without config file and run as if it "knew" about the starting
location setting even without the config file. But the new machine,
the program behaves as expectedly.. it doesn't detect the config file
setting, so it bombs.

This is weird!

That is indeed strange ,,,,,,, and i do not have a explanation for it ,
except if you provided a config file without the specific entry then it
would have made sense
in the case of not having a config file at all it should default to the
designer specific values ( 0,0 )

regards

Michel

 

[mcdonamw]

I don't know.. I'm confused.

That is indeed strange ,,,,,,, and i do not have a explanation for it ,
except if you provided a config file without the specific entry then it
would have made sense
in the case of not having a config file at all it should default to the
designer specific values ( 0,0 )

I don't know.. this is just crazy haha. All I know is

1) "new machine with no config file = bomb due to inability to find
value when my code tries to load it (starting point =
my.settings.startingpoint)".
2) Not sure if I noted previously, but the first version of the app
did not have this particular setting. I added it after the fact in a
subsequent rebuild. So a machine that was working with the original
config, can run the new app, even if the new setting isn't specified
at all (or even if the config file is flat out deleted, including from
user's appdata folder).
3) If I run the new version with latest config file at least once on
the new machine, and later delete the config file (including the user
stored config file in appdata) or simply just remove that value from
the config file, the program will start as if it can load that
settings, even though the setting doesn't exist.

I'll have to try some more testing when I get time.