By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,491 Members | 3,273 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,491 IT Pros & Developers. It's quick & easy.

Me vs. VS2003 IDE Part 2: The config-settings that wouldn't die

P: n/a
Hello everybody,

I put this in a separate thread because altough it is connected to the localization-problem in my former thread this is a completely
different "joke" of the IDE.

While waiting for some hint on how to include my own ressources in IDE-generated satellite-assemblies (because there can only be on
assembly per each language) I decided to try to use the XML-editor for the IDE-generated .resx-files again.

I noticed that the IDE starts with the .resx-file for the language which is currently set as the form's property. As soon as you
change the language property of the form the IDE will inadvertedly rewrite the current .resx-file (removing all entries made by
myself) and open the one of the language you have switched to. Thus, for the moment, I provided all elements with neutral and
localized language texts in the designer and afterwards added my own strings with the XML-editor to the neutral .resx-file and to
the localized .resx-files. As long as I do not switch language properties of the form again these files will remain untouched.

I rebuilt the project and noticed, that the MyApp.exe in the obj\Debug-directory will correctly load MyApp.resources.dll, but not so
the MyApp.exe in the bin\Debug-directory (checked it with FusLogVW).

The difference lies in the MyApp.exe.config-files:

Earlier I had tried to add some dynamic properties to some elements in the form. Although I had removed these later on the
config-file in bin-directory still contained the entries in the <appsettings>-section.

The config-file in obj-directory only contained

<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">

which can not be found in the other config-file.
Some things are striking here:

- The <assemblyBinding> - element gives no information (redirection or the like), yet it is obviously necessary for the application
to load the satellite-assemblies.

- It is the only element in the obj-config-file but omitted in the bin-config-file. On the other hand the <appsettings>-section does
not appear in the obj-config-file.

- Adding the <runtime>-section to the bin-config-file will not work, still the assemblies are NOT loaded. Only completely removing
the <appsettings>-section and putting in the <runtime>-section (which essentially means copying the obj-config-file to the
bin-directory) will lead to success.

- Upon building the project the IDE recovers the bin-config-file (only <appsettings>-section again), although I already removed the
dynamic properties earlier. I wonder from where the IDE has got this information.
The IDE might be helpful, but this goes a little bit far. Can someone explain me if I am doing something wrong?

How can I prevent the IDE from overwriting my changes to the config-file in bin\Debug?

How can I include BOTH <assemblyBinding> and <appsettings> information so that assembly-loading still works?

Why is there a difference between config-files in bin- and obj-directories?
Best regards

Nov 17 '05 #1
Share this Question
Share on Google+
1 Reply

P: n/a
O.k., I hope that I'm not only talking to myself all the time :-) ...

Some update on the MyApp.exe.config-file in bin\Debug-directory:

It is NOT about the <assemblyBinding>-section (which does not give information at all) that satellite-assemblies are not loaded. If
I delete the MyApp.exe.config-file in bin\Debug the satellites are loaded perfectly.

Thus my conclusion is:
Not the (empty) <assemblyBinding>-section does detain the application from loading the satellites but rather does the presence of
the <appsettings>-section (which contains formerly removed dynamic properties).

This returns a BIT of believe in Logic to me since an empty <assemblyBinding>-section really should not affect the way assemblies
are loaded.

But still:

Why can assembly-loading and presence of an <appsettings>-section in the MyApp.config.exe not cohabitate? What should I do if later
on I indeed want to make use of dynamic properties?

Why does the <appsettings>-section reappear upon building even if I removed the dynamic properties in designer and manually deleted
the section from MyApp.exe.config?

I appreciate if someone even asked what I'm talking about :-)

Nov 17 '05 #2

This discussion thread is closed

Replies have been disabled for this discussion.