My.Settings feature not compatible with Inventor Add-Ins?

[ryan]

My application makes use of the My.Settings feature to store some pathing information and such so that it can be easily tweaked after installation. However, the compiled DLL file appears to "burn in" these values so if the .config file is edited after the fact, the add-in continues to use the values that were set during development. In fact, you can even delete the .config file which stores these settings and the application works; proving that the values are being read from the assembly and not the configuration file (Note - These settings are defined as "Application" level settings).



Example:



My.Computer.Network.Ping(My.Settings.ServerName, 5000)



If at the time of development, ServerName was localhost but then after the application is deployed, the configuration file is modified so that this value is EngServer, the application will not read the updated value from the configuration file; and therefore, continues to use localhost.



Please, can someone give me some insight here?



Thanks,



Ryan Edited by: ryan on Apr 11, 2009 1:15 AM

[jeff.pek]

.NET will not use DLL-level configuration information, so the xxx.dll.config file you have is never being used. In order to get this information read for an Inventor addin, you'd need to add this information to the inventor.exe.config file.

You can, however, write code to read the values from your dll.config file during addin activation if you want. It's unfortunate that MS hasn't yet chosen to support the use of dll-specific configuration files.

You could also use a secondary application domain, but that may be more of a pain than it's worth. See this article for some more info. Google will certainly have a bunch of hits on this topic.

http://bytes.com/groups/net-c/226001-problem-app-config-dll

Jeff

[Anonymous]

I read Jeff's response here, and am wondering what you are talking
about? I looked for the original post and could not find it on the
nntp side. The reason I ask, is because I have been using the
My.Settings net feature to store settings in my renumber balloons
addin (read dll) for over a year now, with no problems at all.
Well, there were a couple problems I had to resolve, the main one
being where the settings file was stored. Found the "user.config"
file for the settings at {$userpath}\Local Settings\Application Data\_
Autodesk,_Inc\DefaultDomain_Path_gyhigsay53p42fls50jshjbsv5cgrpyc\_
Autodesk®_Inventor™_2009.

Only thing I can think of you may be talking about is an actual
xxx.dll.config file that you can distribute with the addin? I did
find out but also found out that the default info you create
for the dll is stored right inside the dll when it is compiled, so
you do not distribute the config file, but it gets created at
regasm time it appears (not sure where the DefaultDomain_Path_gibberish
part is determined though).

Bob S.

jeff.pek@autodesk.com wrote:
> .NET will not use DLL-level configuration information, so the
> xxx.dll.config file you have is never being used. In order to get this
> information read for an Inventor addin, you'd need to add this
> information to the inventor.exe.config file. You can, however, write
> code to read the values from your dll.config file during addin
> activation if you want. It's unfortunate that MS hasn't yet chosen to
> support the use of dll-specific configuration files. You could also use
> a secondary application domain, but that may be more of a pain than it's
> worth. See this article for some more info. Google will certainly have a
> bunch of hits on this topic.
> http://bytes.com/groups/net-c/226001-problem-app-config-dll Jeff

[jeff.pek]

Yes, this is right too. What I was referring to was changing the default values, which are typically stored in an application's .exe.config file. As I explained, this doesn't work the same way for DLLs.

But, using the My.Settings object's Save() and Reload() methods, you can still save user-modified settings values, and reload them, to and from disk for use in subsequent sessions.

Jeff

[ryan]

So putting together the previous replies, this is what I get:

A .NET application compiled as a .DLL will not inherently read from the corresponding .config file in the same manner that a .EXE will. Therefore, there are two options:

1) Use the .DLL.CONFIG file to store my values but manually write the code to read in the values.
2) Use "User level" configuration files (which causes the .DLL.CONFIG file to get created at the time of installation in the \etc directory).

Thanks!

[Anonymous]

So far I have been opting for the user level config files
created at time of installation (or registration) as the
easiest route (for me).

Bob S.

ryan wrote:
> So putting together the previous replies, this is what I get: A .NET
> application compiled as a .DLL will not inherently read from the
> corresponding .config file in the same manner that a .EXE will.
> Therefore, there are two options: 1) Use the .DLL.CONFIG file to store
> my values but manually write the code to read in the values. 2) Use
> "User level" configuration files (which causes the .DLL.CONFIG file to
> get created at the time of installation in the \etc directory). Thanks!