I have a stand-alone WinForms application, let's call it "Program A." Program A let's a user create a file and save some information to it. Program A also exposes some public classes.
Another stand-alone WinForms application ("Program B") references Program A, and uses some of its public classes.
However, some of Program A's classes need to open the file the user created in order to retrieve data from it. In Program A, the location of the user's file is saved in the "Settings" (as user-scope settings of course) and are retrieved (this is a VB.NET app) via My.Settings
.
This is all well and good until Program B runs - when it runs and uses the classes from Program A that need to read from Program A's My.Settings
, the settings are blank - it's as if they were reset (as when you run Program A for the first time or under a new user account). Any application-scope settings are kept, but any user-scope settings are reset to their default values (whatever they were set to in the IDE when Program A was written).
Here is a pseudo-code example:
Program A:
Namespace ProgramA
Public Class Foo
Public Shared Function GetStuff() as Object
File = OpenFile(My.Settings.UserFileName)
Return File.ReadStuff()
End Function
End Class
End Namespace
Program B:
TheStuffIWant = ProgramA.Foo.GetStuff()
Assume that the user has already run Program A at least once and opened a file, so Program A's My.Settings.UserFileName
should be set.
When Program B calls Foo.GetStuff()
, it doesn't return anything because My.Settings.UserFileName
doesn't contain the user's file name - more accurately, it contains whatever the "default" value for that setting was (as set in the IDE when you set up the setting in the first place). But, if you turn around and launch Program A, it remembers the user's setting for UserFileName
.
So - the question is: When calling a function in a referenced assembly, why are the user's settings not retained? Is there an explanation for the behavior I'm seeing, or am I missing something terribly obvious? Or perhaps I'm just going about this all wrong, and I shouldn't have made any of the public classes in Program A rely on anything in My.Settings
in the first place?