c# - 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] 属性の間違ったアセンブリをプローブするという障害モードを使用します。また、Connect フィードバック記事の奇妙な「Closed as external」却下についても説明しています。Fusion は、DevDiv ではなく Microsoft の Windows グループが所有しています。

とにかく、出力ファイルの名前を変更するだけで問題が解決することが示されています。プロジェクト+プロパティ、ビルドタブ、出力パス設定。

Answer 2

私はデバッガーの内部動作の専門家ではありませんが、ウォッチ ウィンドウに表示される値は、アプリケーションのメイン スレッド (スクリーンショットで一時停止されている) ではなく、Visual Studio スレッドによって評価されると考えていました。

したがって、矛盾は見られません。ウォッチ ウィンドウは、Visual Studio スレッドが MTA であると言っているだけです。

Debug.Writeメインスレッドのアパートメント状態を表示するために使用してみてください。