Question

我有一个独立的WinForms应用程序，我们称之为“程序A”。程序A让用户创建一个文件并保存一些信息。计划A还公开了一些公共课程。

另一个独立的WinForms应用程序（“程序B”）引用程序A，并使用它的一些公共类。

但是，程序A的某些类需要打开用户创建的文件，以便从中检索数据。在程序A中，用户文件的位置保存在“设置”中（当然是用户范围设置），并通过My.Settings检索（这是一个VB.NET应用程序）。

在程序B运行之前，这一切都很好 - 当它运行并使用程序A中需要从程序A的My.Settings读取的类时，设置为空白 - 就像它们被重置一样（如当您第一次运行程序A或在新用户帐户下运行时）。保留任何应用程序范围设置，但任何用户范围设置都将重置为其默认值（无论在编写程序A时在IDE中设置它们）。

这是一个伪代码示例：

计划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

计划B：

TheStuffIWant = ProgramA.Foo.GetStuff()

假设用户已经至少运行过一次程序A并打开了一个文件，那么应该设置程序A的My.Settings.UserFileName。

当程序B调用Foo.GetStuff()时，它不会返回任何内容，因为My.Settings.UserFileName不包含用户的文件名 - 更准确地说，它包含该设置的“默认”值（在首次设置设置时在IDE中设置）。但是，如果你转身并启动程序A，它会记住用户对UserFileName的设置。

所以 - 问题是：在引用的程序集中调用函数时，为什么不保留用户的设置？对于我所看到的行为有没有解释，或者我错过了一些非常明显的东西？或者也许我只是认为这一切都错了，我不应该让程序A中的任何公共课程首先依赖My.Settings中的任何内容？

Answer 1

您的问题是执行的应用程序会读取用户范围的设置。因为您从程序B引用程序A而不是执行程序A，所以程序A中的类正在尝试获取程序B未读取的设置。

关键是程序B有自己的设置与程序A分开，程序B执行的任何类（无论它在何处定义）都将使用程序B的设置。

因此，按照您的设置，您运气不好。

如果您同时控制程序A和程序B，则可以为这两者编写自定义设置提供程序，以便它们共享通用用户范围设置。

Application Settings Architecture文章有一节介绍如何执行此操作。

当.NET程序集“引用”时，用户范围设置会发生什么？

1 个答案: