Jeff, Thanks for the reply. I've done some more testing on various scenarios, including having the COM components registered as opposed to using the manifest file. With these particular COM components, the behavior is the same.
After doing some exhaustive searches on the net, I've come up with this, which implies that the issue is both apartment-related as well as having to do with the way the COM components were developed (i.e. requires the proxy/stub). http://support.microsoft.com/?kbid=309330 Now, for my particular case, I have found that I can get it to work with this particular combination only: Main app is MTA (which is the default) TestFixture set to ApartmentState.STA This makes sense to me that the thread the TestFixture runs under needs to be STA. However, what I still can't figure out is why the main app needs to be MTA. If I also put [STAThread] onto Main(), effectively making main thread an STA, and subsequent threads as their own STA, then it fails. None of this is really specific to MbUnit, but I figured I would post the follow-up here anyway in case others run into similar problems. On Apr 26, 12:18 am, "Jeff Brown" <[EMAIL PROTECTED]> wrote: > Hmm. > Well, I'm not sure it would really be an Apartment Threading issue. > Anyways, you could always double-check by creating your own thread inside of > a test and settings its apartment state (thus bypassing MbUnit's own > mechanism) to see. > > I imagine the problem has more to do with the use of a manifest file. > > Here's what I think is happening: > > 1. You create an instance of a COM object. > 2. You try to cast the Runtime Callable Wrapper (RCW) for the COM object to > some Interop type you made. > 3. The framework tries to resolve the type library and registered interop > assembly for the RCW and fails because it can't find one. > 4. You get an InvalidCastException. > > Try registering your wrapper first then running your tests. I know you'd > rather use a manifest, but I'm not sure this mechanism is really working as > you would expect. Perhaps it fails because MbUnit uses multiple > AppDomains... Dunno. I've never tried it. > > Jeff. > > -----Original Message----- > From: [email protected] [mailto:[EMAIL PROTECTED] On > > Behalf Of gambitx > Sent: Friday, April 25, 2008 7:57 PM > To: MbUnit.User > Subject: MbUnit Re: AutoRunner - COM Interop (using manifest) not working > > OK, actually I misstated something. The test I ran trying to create a > simple console app wasn't exactly coded as I expected. After changing to > what I described, it also failed similar to what the MbUnit AutoRunner exe > was doing. So this is probably more of a general COM apartment-threading > issue. > > On Apr 25, 4:57 pm, gambitx <[EMAIL PROTECTED]> wrote: > > I just started trying out MbUnit to see if it can meet my testing > > requirements. I have some assemblies that make use of COM components > > via Interop. However, additionally, I need to avoid registering these > > COM components, so am using manifest files to locate them. > > > MbUnit has the AutoRunner class, allowing one to change the test > > assembly into a self-contained executable to run those tests. This > > seems ideal, as it would allow me to create the EXE, add a manifest > > file to it that has all the references for my COM components, and I > > should be good to go. > > > However, I have tried many different ways to get this to work, and I > > continue to get a System.InvalidCastException when trying to make a > > call on the COM object. The manifest file does appear to be picked up > > when the exe is loaded . I thought this could be an apartment- > > threading issue, and have added [STAThread] attribute into Main() as > > well as specifying the test fixture as > > [TestFixture(ApartmentState=ApartmentState.STA)]. However, it didn't > > help. > > > Some other tests that I have tried are to create a simple console > > application that doesn't use MbUnit, create a thread, mark the thread > > as being STA, and calling the function that uses the COM objects. > > This works just fine. I'm not sure what else the AutoRunner class > > does and how the EXE generated using MbUnit is different from the > > simple test app that I created. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "MbUnit.User" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/MbUnitUser?hl=en -~----------~----~----~----~------~----~------~--~---
