为什么 STAThread 属性被忽略了？

Question

VS的奇怪行为...

大家好！

有人能解释一下这是怎么回事吗？

谢谢， Alex。

- Alex

---

可能相关：STAThread 丢失，但其实是存在的？ - Cody Gray

启用非托管代码调试并显示调用堆栈。 - Hans Passant

请尝试在“Main”开头调用“Thread.CurrentThread.SetApartmentState（ApartmentState.STA）”。 - Ruben

然后如果没有效果，请尝试从调试器监视窗口调用它。 - Ruben

[STAThread] 只是提示运行时为 COM 对象设置单线程应用程序模型，如果未设置的话。一旦设置了该模型，就无法更改。显然，在调用 Main 函数之前初始化了某些其他组件，这就是为什么应用程序模型已经被设置的原因。 - Hristo Iliev

Answer 1

我发现链接的答案有点难以接受，特别是因为提问者承认他实际上没有与EXE同名的DLL。我也无法重现它。

然而，这个解释有一定的可信度，我注意到当Fusion被要求搜索一个程序集时会出现一些奇怪的事情。你可以通过Fuslogvw.exe看到这个过程，启用“记录所有绑定”选项。奇怪的是，当要求加载一个程序集时，它会同时搜索DLL和EXE。以下是一个测试控制台应用程序的日志条目片段：

LOG: Attempting download of new URL file:///C:/projects/ConsoleApplication3/bin/Debug/ConsoleApplication3.DLL.
LOG: Attempting download of new URL file:///C:/projects/ConsoleApplication3/bin/Debug/ConsoleApplication3/ConsoleApplication3.DLL.
LOG: Attempting download of new URL file:///C:/projects/ConsoleApplication3/bin/Debug/ConsoleApplication3.EXE.
LOG: Assembly download was successful. Attempting setup of file: C:\projects\ConsoleApplication3\bin\Debug\ConsoleApplication3.exe
LOG: Entering run-from-source setup phase.

向右滚动以查看它如何首先查找DLL。以及它在与程序集同名的子目录中的外观。这里很奇怪，也有很多潜在的DLL地狱问题。如果CLR以某种方式探测到错误的程序集，则会出现故障模式，该程序集用于[STAThread]属性。还解释了连接反馈文章的奇怪“作为外部关闭”的解雇，Fusion归Windows组拥有，而不是DevDiv。

总之，迹象表明，简单地重命名输出文件将解决您的问题。项目+属性，生成选项卡，输出路径设置。

- Hans Passant

Answer 2

我并非调试器内部工作的专家，但我认为在观察窗口中显示的值是由Visual Studio线程评估的，而不是应用程序的主线程（在截图中暂停）。

因此，我没有看到矛盾之处，观察窗口只是说Visual Studio线程是MTA。

尝试使用Debug.Write来显示主线程的公寓状态。

- Joe

---

这是正确的，但在这种情况下不是这样，他使用了断点，以便执行线程可以用于评估监视表达式。 - Hans Passant