Add initial VB6 tests#8253
Conversation
Adds a really simple VB6 control to write tests against. Adds utility code for handling COM classes straight from their host assembly. Add a simple DynamicAxHost class to utilize these ComClass wrappers. Also skip needless throwing and catching exceptions from the connection cookie setup in AxHost. Note that I've renamed the control from .ocx to .vb6 to avoid having it accidentally picked up by anything.
|
Well, this is failing spectacularly. Trying to narrow it down. |
It looks like ISpecifyPropertyPages on the VB control might be corrupting the runtime state? Fiddled with a few things to see if I could get the problem to stop occurring. Made the ComClassFactory use an AgileReference, experimented quite a bit with the ISpecifyPropertyPages reference.
|
@AaronRobinsonMSFT this is where my question came from. I'm screwing up the runtime somewhere, and that could entirely be an artifact of me directly instantiating a VB control from LoadLibrary. Things work in isolation, but something is getting corrupted and I'm struggling to narrow the culprit down. I don't know if it is my direct usage of DllGetClassObject or some side effect of invoking the various interfaces on the object I'm getting back. I keep chasing red herrings sadly. The reason I was trying to go this route was to avoid registering COM controls for tests (not a great idea for CI, if it is even allowed). It seemed like a relatively straightforward workaround. I can't figure out the activation contexts to understand if I can go that route. |
|
@AaronRobinsonMSFT apparently it isn't my hack to create it directly. I've registered and used CoCreateInstance and I still get the corruption. |
Do we have a DMP? Can I reproduce this locally? I'll take a look later today and reach out offline.
I'd also check in the actual VB code as well. Just having a binary blob isn't all that helpful. Perhaps it is already checked in somewhere? |
It can be reproduced locally. With this branch run the following from the root: The test run will abort with no details. You can tell it aborted as you will get a In VS (use
I will check in the code eventually. Was trying to get a better handle on the project structure to know what I should include. It is an ActiveX Control project with a text box and a button that sets the text in the text box when clicked. Just dragged and dropped and set a click handler through the UI. |
| public class AxHostVisualBasic6Tests | ||
| { | ||
| [WinFormsFact] | ||
| public void AxHost_SimpleControl_Create() |
There was a problem hiding this comment.
Any specific reason to run this as a unit test and not as UI integration test? The latter are run serially.
|
This fails in the same way on .NET 7. :/ |
|
@JeremyKuhne Is it worth checking how this behaves on .NET Framework in the current test harness? I'd like to know how much effort I should put into looking into this as it is very hard to untangle these sorts of bugs when they only occur in while running in a process with many threads, the VB6 runtime just wasn't designed for that environment. |
@AaronRobinsonMSFT I'll keep trying to narrow down a repro for it. These tests are all on the same thread- which is what worries me a bit. It's quite possible it is some side effect of us never quite doing the COM right (thinking of how we don't handle casting to base interfaces for example). I'll keep you posted. |
|
This was merged disabled in #8322. |
ghost
locked as resolved and limited conversation to collaborators
4 participants
Adds a really simple VB6 control to write tests against.
Adds utility code for handling COM classes straight from their host assembly.
Add a simple DynamicAxHost class to utilize these ComClass wrappers.
Also skip needless throwing and catching exceptions from the connection cookie setup in AxHost.
Note that I've renamed the control from .ocx to .vb6 to avoid having it accidentally picked up by anything.
Microsoft Reviewers: Open in CodeFlow