views:

625

answers:

1

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?

+2  A: 

Your problem is that user-scoped settings are read by the executing application. Because you are referencing Program A from Program B rather than executing Program A, the classes in Program A are attempting to get settings that weren't read by Program B.

The point is that Program B has its own settings that are separate from Program A, and any class that's being executed by Program B (regardless of where it's defined) will use Program B's settings.

So with your setup the way it is, you're out of luck.

If you control both Program A and Program B, you can write a custom settings provider for both that would allow them to share common user-scope settings.

The Application Settings Architecture article has a section on how to do this.

Randolpho
I was afraid it was something like that, but I didn't know for sure. That's a bummer; I'm going to have to re-think how I do data exchange between the two programs...
Keithius
Your best bet is to make both applications aware of the shared settings and provide them to the classes rather than have the classes get those settings from the user settings.
Randolpho