You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In fixing issue #1914, I had to comment out a test in LowTrustFixture.cs, which ran code in a separate AppDomain created by the user.
The problem is that the TestExecutionContext is marshalled by reference, while some of it's members are neither MBR nor serializable. Accessing any such member causes a remoting error. This is a consequence of the fact that we don't explicitly support running tests in a separate AppDomain but nothing stops a user from creating an AppDomain in their tests.
The particular test commented out uses Assert.Throws, which now creates an isolated context for the delegate it executes. Creating the context in a separate domain involves copying members across the remoting boundary. I think we can avoid this by using a public method of TestExecutionContext to create the isolated domain in the original context.
We have a few other issues that relate to problems in user-created AppDomains: #42 and #71. They may be due to the same phenomenon, so I'll look at them at the same time.
The text was updated successfully, but these errors were encountered:
In fixing issue #1914, I had to comment out a test in LowTrustFixture.cs, which ran code in a separate AppDomain created by the user.
The problem is that the TestExecutionContext is marshalled by reference, while some of it's members are neither MBR nor serializable. Accessing any such member causes a remoting error. This is a consequence of the fact that we don't explicitly support running tests in a separate AppDomain but nothing stops a user from creating an AppDomain in their tests.
The particular test commented out uses Assert.Throws, which now creates an isolated context for the delegate it executes. Creating the context in a separate domain involves copying members across the remoting boundary. I think we can avoid this by using a public method of TestExecutionContext to create the isolated domain in the original context.
We have a few other issues that relate to problems in user-created AppDomains: #42 and #71. They may be due to the same phenomenon, so I'll look at them at the same time.
The text was updated successfully, but these errors were encountered: