different behaviour design time / run time

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi Code guru's

I have created a user control which has access, and thus makes use of a shared singleton class like:
Dim MyAppSettings As DLAppSettings = DLAppSettings.GetAppSettings

This singleton class has amongst other stuff the following line of code in it:
Private m_DL_DBPath As String = System.Configuration.ConfigurationSettings.AppSettings("DMDatabasePath")

As you guess, it must read a string containing the path. Based on this string, a connection string is build later in the code.

Now the control is placed onto a form, and when I open the form (in design time) in the editor, it seems code is executed. And the code fails because the m_DL_DBPath variable has the value nothing.

Yet everything works as it is supposed to be when compiling and running the code.

1) Why is code executing in the designer when I throw user controls on a form?
2) Does System.Configuration.ConfigurationSettings.AppSettings work in design time?

Help is much appreciated as I am already hammering for three days on this.

eMKa
 
Hello eMKa,

Thanks for your post. As I understand, the problem you are facing is that
your application works when running without debugger, while it fails when
starting from VS .NET. Please correct me if there is any misunderstanding.
I think more information is needed before moving forward:

Where does your config file locate, the projects' folder?
Could you post a simple project which is able to reproduce the problem?

I look forward to hearing from you.

Regards,

HuangTM
Microsoft Online Partner Support
MCSE/MCSD

Get Secure! -- www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.
 
Dear HuangTM,

No, that's not exactly correct.
My program runs correctly if compiled and executed outside VS
But it also runs fine when being debugged in VS.
The strange thing is that when I open a form in the editor which contains the user control, then code seems executed (no idea why!) I ams sure because I put msgboxes in the code, and they are appearing, hence code is being executed.

I am trying to reproduce the problem in a small project, because the current project is big and complex.
 
Hi,

I have not received it yet. Could you please send it to me at
(e-mail address removed)?

Regards,

HuangTM
Microsoft Online Partner Support
MCSE/MCSD

Get Secure! -- www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.
 
I did send you an example last Friday. To be sure I have send it again today. B.t.w. can't you attach files to posts?
 
Hi,

Thanks for your sample. I tested on my side, however, I am not able to
reproduce the problem. The Path is read properly, and I only get the
following message box:
"Configuration file problem -- [DDbs][SetDatabases] Got path=D:\Visual
Studio Projects\DT\DT.mdb"

For further investigation, I suggest you to use FileMon to check whether or
which .config file was loaded .

FileMon
http://www.sysinternals.com/ntw2k/source/filemon.shtml

I look forward to your response.

Regards,

HuangTM
Microsoft Online Partner Support
MCSE/MCSD

Get Secure! -- www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.
 
Hi TiM

That is odd ... I have put the project in source safe, and another colleague loaded it on his machine. Then he BUILD the solution. Opened the form, and there is NO PATH. So it is reproducible on another machine. Are U sure you build the solution

Furthermore, I monitored file access (with FileMon) and when the solution gets build it does access the comfit file, whereas if it is opened after a rebuild it is NOT

I send you (by separate mail) the following capture files

FirstTime.log - shows file access when opening the form after a rebuil
SecondTime - shows the access if I open the form a second tim
Rebuild.log - the access when rebuildin

In all cases I filtered on devenv
 
Hi,

Thanks for your response. I checked your project again, I noticed that you
get the appsettings in the New of the constructor of DCtrl. You know, this
function is generated by WinForm Designer and will be used in the Designer.
To work around this problem, I suggest you to move the following code from
New() to Init() method:

MyAppSettings = DAppSettings.GetAppSettings
MyDBs = DDbs.GetDDbs

Hope this helps.

Regards,

HuangTM
Microsoft Online Partner Support
MCSE/MCSD

Get Secure! -- www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.
 
Hi TiM

Thanks for bringing this up. Actually I moved the code to the ‘new’ as an experimnt. Usually I do not put code up there. Originally I had put it in the declaration section (in the Dctrl user-control class) like this;
Dim MyAppSettings As DAppSettings = DAppSettings.GetAppSetting
Dim MyDBs As DDbs = DDbs.GetDDb

Which gives the same (error) result. Also the ‘Init’ function was put there as an experiment and as a last resort to get rid of the error messages during design-time (like you also suggested). I feel an ‘Init’ function is not a good way of practicing OO-programming. Because now I must assure that the ‘Init’ function is called in the Form Load event of each and every form that is hosting the control. Do you agree

The point is that I am not trying to get rid of the error; I am trying to understand what is happening and why it is happening. My argument is: Why does it work at runtime and not at design-time. And what is actually happening at design-time? Why is code executed at design time? And why does it work if I move these lines to the ‘Init’ function

Hope you can give me some clues

Marti
 
Hi ,

Since this issue is closly related to winform design time behavior, Tim has
transferred this issue to me. I'd like to confirm if I have understood your
scenario correctly.
You have a component which in its constructor will read
ConfigurationSettings.AppSettings collection to get the path setting from a
.config file. the path setting could be get correctly in run-time
regardless in or not in the debugger, however you could not get the value
if put the component onto form in design-time. If there is any
mis-understanding, please feel free to correct me.

I could reproduce the behavior described above on my system, after some
investigation, I found this is because the .NET configuration system always
try to load the .config file with the same name as the executable name
from the Application Base, when the component are created in design-time,
it's actually running in the AppDomain of Vs.NET IDE, so that it tries to
retrieve the corresponding data from
"<path_to_devenv.exe>\devenv.exe.config"
here, the Application Base is where the app start from
and the entry assembly name is devenv.exe
Of course by default devenv.exe.config does not contain "appSettings"
section and your settings, that's why you could not get the corresponding
settings.

Does it answer your question?
If you have anything unclear about my reply, please feel free to reply this
thread.

By the way, we have a special group for design-time programming in windows
forms, you may post design-time issues to that group next time.

Thanks!

Best regards,

Ying-Shen Yu [MSFT]
Microsoft Community Support
Get Secure! - www.microsoft.com/security

This posting is provided "AS IS" with no warranties and confers no rights.
This mail should not be replied directly, please remove the word "online"
before sending mail.
 
Dear Ying-Shen Yu and Tim

Thanks for explaining this. It is perfectly clear answer. I expected that the config file would be (temporarily) copied to that directory automatically. Also I have been experimenting with copying the config file to the bin directory, but that did not help either, so I got confused and wanted to know what was going on. I will try copying it to the right spot tomorrow. This issue should be resolved then

Thanks again

Marti
 
Dear Ying-Shen and Ti

OK, I can confirm that putting the information in the devenv.exe.config does indeed work
This is of course not a "good programming practice" and a potentially confusing solution. It is something that could be improved in the next version of Visual Studio. E.g. it would be better if the application's own config file was copied to this location during design time.

Thanks again for explaining this feature

Martin
 
Back
Top