VB.NET项目引用场景下配置文件加载问题：调用子功能连接串异常

1. 引用项目的函数执行时，会读取哪个配置文件？ #

当你的ASP.NET站点调用引用的VB.NET控制台EXE里的函数时，实际跑代码的是ASP.NET的进程（比如IIS的w3wp.exe），所以代码会读取ASP.NET项目的web.config，而不是控制台EXE自己的exe.config。

道理很简单：.NET里每个进程启动时只会加载自己对应的配置文件——控制台程序独立运行时读自己的xxx.exe.config，Web应用运行时读web.config。你把EXE当作类库引用后，它的代码是在Web进程里执行的，自然不会去加载它自身的配置文件。

2. 异常连接串的来源是什么？ #

你碰到的“调用时用原始连接串而非修改后配置”的问题，大概率是下面几种情况之一：

情况一：控制台项目的连接串被编译进程序集了 #

如果你的VB.NET控制台用了项目属性里的“设置”（Settings.settings），而且把连接串设成了Application范围（不是User范围），那这个连接串的值会被直接编译到程序集的元数据中。运行时根本不会去读exe.config，直接用编译时的原始值——哪怕你后来改了配置文件也没用。

情况二：控制台读取配置的方式不对 #

要是控制台代码没正确用ConfigurationManager读取配置，比如硬编码了连接串，或者读错了配置节点，那肯定会用旧值。举个例子：

• 直接写死连接串：Dim connStr As String = "Server=OldServer;Database=OldDB;..."
• 或者读取配置时指定了错误的路径，没有从当前进程的配置中读取。

情况三：exe.config没复制到Web的bin目录，控制台代码 fallback 到默认值 #

虽然Web进程不会加载exe.config，但如果控制台代码尝试自己加载配置（比如用ConfigurationManager.OpenExeConfiguration(Assembly.GetExecutingAssembly().Location)），但exe.config没被复制到Web的bin目录，那ConfigurationManager就会 fallback 到编译时的默认设置，也就是你最初的那个连接串。

解决建议 #

针对这些问题，你可以试试这些办法：

• 检查控制台的连接串读取逻辑：确保用ConfigurationManager.ConnectionStrings["你的连接串名称"].ConnectionString来读取，别用Application范围的Settings（要么改成User范围，要么直接读取配置节点）。
• 把控制台需要的连接串配置到ASP.NET的web.config里，让控制台代码直接读取Web进程的配置——这样配置管理也更统一。
• 如果控制台非得读自己的配置，那得手动把xxx.exe.config复制到Web的bin目录，还要在控制台代码里显式加载这个文件（不过不太推荐，Web应用的配置最好统一在web.config里管理）。

内容的提问来源于stack exchange，提问作者EraldoMarziano