Setting STAThreadAttribute doesn't work because your startup code is not
the _real_ startup code for the process. IE already started the code.

Luckily for you, IE didn't cause any other COM components to be invoked
in the AppDomain before your code got to run, or else setting
ApartmentState wouldn't work either. That only works up to the point
where you first interact with COM...

This is the root of a problem in ASP.NET. ASP.NET not only defaults to
an MTA, but it invokes COM before any of your code ever runs. This means
that it is not possible to interact with STA components directly on your
main thread in a Web Form...

COM interop handles the details - so your code _looks_ like it works in
simple cases, but what really happens is that your COM calls go to the
MTA, then to an STA. Ugly and slow.

That's why they recommend using aspcompat if you have to interact with
an STA component in a Web Form. Of course _that_ has a bunch of negative
side-effects too...

Rocky

> -----Original Message-----
> From: Anton van der Merwe [mailto:antonvdmerwe@h...] 
> Sent: Friday, March 07, 2003 5:26 PM
> To: expert_vb_business_objects
> Subject: [expert_vb_business_objects] RE: Odd behaviour in 
> Auto deployment
> 
> 
> Yes, thanks very much, that definately explains it.  So that 
> is why it ran 
> fine under NetRun (or any other similar VB.NET program), and had the 
> problem when IEExec was the host, and forced my program to 
> use MTA for the 
> COM interop.
> 
> And it also confirmed that if I still want to run my app 
> directly from the 
> browser (no NetRun-type utility),  setting the ApartmentState 
> explicitly 
> to STA is the solution.  I still don't understand why the 
> STAThreadAttribute didn't have any effect, and that I had to set the 
> property instead, they are suppose to do the same thing?
> 
> Once again, very valuable forum!  :)
> 
> Thanks,
> Ant.
> 
> 
> > I put the answer on my web site
> 
http://www.lhotka.net/Articles.aspx?id=6542e188-d2e2-4e89-8880-c82025a45
c49

Hopefully this helps.

Rocky