Assembly Settings baked into dll?

[Reverend]

I'm out of ideas at this point. I have a WinForms application and an
Assembly (dll). The Assembly, lets call it "Foo" has an App.config file
located in Foo/Bin/Debug
If I modify this file outside the IDE and reload the Settings file in the
IDE it will pick up the change and ask if I want to update. Good, the file
is backing the settings, I get that.

When I build my solution the Foo/Bin/Debug/App.config file is copied to the
primary application output folder and renamed. So it will now be
WinFormApp/Bin/Debug/Foo.dll.config

What is really throwing me for a loop is that if I modify a value in this
file my application is NOT picking up the modified value. I have tried
exiting the application, modifying the Foo.dll.config file, restarting the
application and it's still pulling the values that it was compiled with.

What is the point of the configuration file if they are ignored?

I also just noticed that the Foo Settings file is not setup to copy to the
output directory (Copy to Output Directory = Do Not Copy) and the Build
Action is None.

Anyone know what's going on? Is there a way to make the settings ACTUALLY
read the values from the config file?
Thanks for any help.

 

[Mr. Arnold]

I'm out of ideas at this point. I have a WinForms application and an
Assembly (dll). The Assembly, lets call it "Foo" has an App.config file
located in Foo/Bin/Debug
If I modify this file outside the IDE and reload the Settings file in the
IDE it will pick up the change and ask if I want to update. Good, the
file
is backing the settings, I get that.

When I build my solution the Foo/Bin/Debug/App.config file is copied to
the
primary application output folder and renamed. So it will now be
WinFormApp/Bin/Debug/Foo.dll.config

What is really throwing me for a loop is that if I modify a value in this
file my application is NOT picking up the modified value. I have tried
exiting the application, modifying the Foo.dll.config file, restarting the
application and it's still pulling the values that it was compiled with.

What is the point of the configuration file if they are ignored?

I also just noticed that the Foo Settings file is not setup to copy to the
output directory (Copy to Output Directory = Do Not Copy) and the Build
Action is None.

Anyone know what's going on? Is there a way to make the settings ACTUALLY
read the values from the config file?
Thanks for any help.

I don't know. Maybe, you need to use the System.Configuration namespace and
the Configuration Manager to ACTUALLY read the data out of the app.config.

 

[Tim Roberts]

I'm out of ideas at this point. I have a WinForms application and an
Assembly (dll). The Assembly, lets call it "Foo" has an App.config file
located in Foo/Bin/Debug
If I modify this file outside the IDE and reload the Settings file in the
IDE it will pick up the change and ask if I want to update. Good, the file
is backing the settings, I get that.

When I build my solution the Foo/Bin/Debug/App.config file is copied to the
primary application output folder and renamed. So it will now be
WinFormApp/Bin/Debug/Foo.dll.config

What is really throwing me for a loop is that if I modify a value in this
file my application is NOT picking up the modified value. I have tried
exiting the application, modifying the Foo.dll.config file, restarting the
application and it's still pulling the values that it was compiled with.

Do you copy Foo.dll to WinFormApp\Bin\Debug as well? Doesn't Foo.dll look
for Foo.dll.config file in the directory that contains Foo.dll?

 

[Peter Bromberg[C# MVP]]

App.Config files (which get translated to "myexename.config" at compilation
are only valid for executables, not dll assemblies.
There isn't sufficient information in your post to understand why you would
have a Foo.dll.config file and how it gets generated.
Rest assured that if it is for a dll assembly, it is not getting "read".
Peter

 

[Steve K]

Do you copy Foo.dll to WinFormApp\Bin\Debug as well?

Yes, WinFormApp has a Project Output reference to Foo.dll. When I build my solution Foo.dll is copied to
WinFormApp/Bin/Debug.
In this folder I have WinFormApp.exe.config and I also have Foo.dll.config

Doesn't Foo.dll look
for Foo.dll.config file in the directory that contains Foo.dll?

This is what I would expect which is the source of my problem. I change the Foo.dll.config and when I run my
application Foo.dll is not pulling/reading/loading/whatever the modified data from the Foo.dll.config file.

 

[Steve K]

App.Config files (which get translated to "myexename.config" at
compilation are only valid for executables, not dll assemblies.

Correct, I may have been unclear in my original post. The Foo.dll.config is NOT an Application Configuration file
(although it has a .config extension) but rather is the file created when adding a Settings file to a project.

There isn't sufficient information in your post to understand why you
would have a Foo.dll.config file and how it gets generated.

I right-clicked on my Foo project node in the Solution Explorer in VS2005
Selected Add > New Item > Settings File

I then added some keys to this Settings file and built my application. This then
adds these keys to an app.config file (I'm honestly not sure if it originally created it or if I did it explicitly -
it's versioned controlled and I'm reluctant to mess with deleting it.)

When I build my application, it copies and renames (as you know) this config file to the main project output directory.
If I then edit this file changing the values of one of the keys the changes are not reflected in the application
(after a restart of course)

Sorry for being unclear before, I hope that makes a bit more sense.
Thanks,
Rev

 

[Steve K]

I don't know. Maybe, you need to use the System.Configuration namespace
and the Configuration Manager to ACTUALLY read the data out of the
app.config.

I was hoping that it would just load the settings from the config file during startup.

Thanks,
Rev

 

[Steve K]

I then added some keys to this Settings file and built my application.
This then
adds these keys to an app.config file (I'm honestly not sure if it
originally created it or if I did it explicitly - it's versioned
controlled and I'm reluctant to mess with deleting it.)

This was actually a pretty lame comment on my part. I took the whopping 90 seconds to verify that:
Adding a Settings file DOES create a default app.config file.

Just wanted to clear that up....