4

vs strange behavior …

vs strange behavior

Hi, All!

Could anyone explain me, how could it be?

Thanks, Alex.

Frank Boyne
  • 4,400
  • 23
  • 30
Alex
  • 131
  • 8
  • 2
    Possibly related: [STAThread missing, but it is there](http://stackoverflow.com/q/3584434) ? – Cody Gray - on strike May 20 '12 at 11:00
  • 1
    Enable unmanaged code debugging and show the call stack. – Hans Passant May 20 '12 at 11:07
  • Please, try to call `Thread.CurrentThread.SetApartmentState(ApartmentState.STA)` at the begin of `Main`. – Ruben May 20 '12 at 11:42
  • And then if it has no effect, please, try to call it from debugger watch window. – Ruben May 20 '12 at 11:53
  • 1
    The `[STAThread]` is just a hint to the runtime to set the single-threaded appartment model for COM objects if **it was not already set**. Once set the model cannot be changed. Apparently some other component is being initialised before the `Main` function is invoked and that's why the apratment model is already set. – Hristo Iliev May 20 '12 at 17:11

2 Answers2

6

I still find the linked answer a bit hard to take, especially because the OP acknowledged that he did not in fact have a DLL with the same name as the EXE. I also can't repro it.

However, there's some credibility to the explanation, I noticed that Fusion does something weird when it is asked to search for an assembly. You can see this at work with Fuslogvw.exe, enable the "Log all binds" option. Odd thing is, it searches for both a DLL and an EXE when asked to load an assembly. Here's a snippet from a log entry for a test console application:

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.

Scroll to the right to see how it first looks for a DLL. And how it looked in a subdirectory with the same name as the assembly. Strange and plenty of potential for DLL Hell here. With the failure mode that the CLR probes the wrong assembly for the [STAThread] attribute somehow. Also explains the strange "Closed as external" dismissal of the Connect feedback article, Fusion is owned by the Windows group at Microsoft, not DevDiv.

Anyhoo, indications are that simply renaming the output file will fix your problem. Project + Properties, Build tab, Output path setting.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
0

I'm not an expert on the inner workings of a debugger, but I would have thought that values displayed in a watch window are evaluated by a Visual Studio thread, not the application's main thread (which is paused in the screenshot).

Hence I don't see a contradiction, the watch window is just saying that the Visual Studio thread is MTA.

Try using Debug.Write to display the main thread's apartment state.

Joe
  • 122,218
  • 32
  • 205
  • 338
  • 1
    That's true but not in this case, he used a breakpoint so the executing thread can be used to evaluate watch expressions. – Hans Passant May 20 '12 at 15:02