为什么忽略STAThread属性？

Question

与奇怪的行为......

嗨，全部！

有人能解释我，怎么可能？

谢谢， 亚历克斯。

Answer 1

我仍然觉得链接的答案有点难以理解，特别是因为OP承认他不实际上有一个与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 Hell的奇怪和充足的潜力。使用故障模式，CLR以某种方式探测[STAThread]属性的错误程序集。此外，解释了连接反馈文章中奇怪的“关闭外部”解雇，Fusion归微软的Windows组所有，而不是DevDiv。

Anyhoo，迹象表明只需重命名输出文件即可解决问题。项目+属性，构建选项卡，输出路径设置。

Answer 2

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

因此我没有看到矛盾，监视窗口只是说Visual Studio线程是MTA。

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