Tie the Revit connection to the process and apply the parallel limit - #109
Closed
sweco-sealqg wants to merge 1 commit into
Closed
Tie the Revit connection to the process and apply the parallel limit#109sweco-sealqg wants to merge 1 commit into
sweco-sealqg wants to merge 1 commit into
Conversation
… limit Revit's core cannot be loaded into a process twice, but a host such as Visual Studio Test Explorer in testing platform server mode starts a new test session per run in one process, so every run after the first failed in RevitSessionSetup with the injector's catch-all message "Attempted to write protected memory". - InitializeRevitConnection injects once per process; later sessions reuse the connection. RevitSessionCleanup no longer runs as a hook and is obsolete. RevitApplicationLifetime, an ITestHostApplicationLifetime registered through build/Nice3point.TUnit.Revit.props, ejects on the Revit thread when the test application finishes: the last point where the dispatcher still accepts work in both the console and server hosts. - RevitApplicationTest carries ParallelLimiter<RevitCountParallelLimit>. TUnit's TestExecutorAttribute does not forward OnTestRegistered to the executor, so the executor's own limit was never applied and tests interleaved on the Revit thread. Tests cover a second session setup in the same process and the limiter.
Owner
|
Both findings landed. The process-wide connection and the release from an Three of the measurements behind that came from this report: the second session failing whether or not the first ejected, the host not terminating when the connection is left open, and Closing in favour of #111. Thank you for the investigation. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Resolves #108.
What changes
Connection lifetime.
InitializeRevitConnectioninjects Revit the first time it is called in the process and is a no-op afterwards, so any number of test sessions share one connection.RevitSessionCleanupno longer runs as a hook; it stays callable and is marked obsolete. The newRevitApplicationLifetime(ITestHostApplicationLifetime) ejects on the Revit thread fromAfterRunAsync, which bothConsoleTestHostandServerTestHostcall after the last session and before runtime shutdown. It is wired into the consumer's generated entry point bybuild/Nice3point.TUnit.Revit.propsthrough aTestingPlatformBuilderHookitem, the mechanism TUnit.Engine uses for its own hook, so consuming projects need no change. The test project imports the same props because a project reference does not deliver them.Why not eject on the last
After(TestSession): there is no way to know it is the last one in a server-mode host. Why notAppDomain.ProcessExit: the runtime's shutdown flag is already set, so the WPF dispatcher aborts anything queued to the Revit thread. Ejecting from another thread throws and leaves a one-thread zombie; skipping the eject makes the native teardown stall for minutes.Parallel limit.
RevitApplicationTestcarries[ParallelLimiter<RevitCountParallelLimit>], which TUnit's generator copies onto every derived test class.RevitCountParallelLimitbecomes public for that.RevitThreadExecutor.OnTestRegisteredstays as is, with a remark that TUnit does not forward the event.Tests
ProcessLifetimeTests.RevitSessionSetup_SecondSessionInSameProcess_ReusesConnectionruns the session hook a second time in the same process and expects the same application back.ProcessLifetimeTests.Limiter_RevitTest_RunsOneAtATimeexpectsTestContext.Current.Parallelism.Limiterto beRevitCountParallelLimitwith limit 1.Verification
The changes come from a consumer suite (37 Revit database tests on the published 2026.1.1 package) where the same two fixes are applied on top of the package. With them the suite passes twice in one server-mode host, passes standalone with default parallelism, and the host exits with code 0 in both cases; before, standalone only passed with
--maximum-parallel-tests 1and every Test Explorer run after the first failed.I could not run this repository's own test project:
Nice3point.Revit.Injectoris only on the Nice3point GitHub Packages feed, which I cannot access. The source and test projects compile forDebug.R26(net8.0-windows) andDebug.R24(net48) against a stub of the injector's public surface, and the generated code was checked for the builder hook call in both targets and the inherited limiter attribute on the test classes. The two new tests have not been executed here; please run the suite before merging.Docs: README (Visual Studio section), CHANGELOG (Unreleased), AGENTS.md (the inject/eject rule now describes the process-level pairing).