Unblock SDK merge by fixing Assembly.GetCallingAssembly()

[steveharter]

SDK merge is blocked due to test failures; see dotnet/sdk#25317 (comment).

The issue is that the test is calling Assembly.GetCallingAssembly() which returns the "Anonymously Hosted DynamicMethods Assembly" instead of the expected assembly. This broke due to the recent Invoke+Emit work where a DynamicMethod is created to invoke that method and the native code that attempts to skip the reflection stack frames was not correct.

Todo:

• This issue can be reproduced in a stand-alone console app by simply using reflection to invoke a method that calls GetCallingAssembly(). However, adding the equivalent to an Xunit test I was unable to reproduce the issue. The console app included several more stack frames, including the "InvokeStub_" frame and the MethodInvoker or ConstructorInvoker frame however the xUnit test did not include those frames. We need to determine why this is the case and add an appropriate test.
• The fix here simply checks for a dynamic method starting with "InvokeStub_"; ideally it also checks to see if that dynamic method is the one generated for invoke vs. some other code that also generates a dynamic method that starts with "InvokeStub_".

[ghost]

Tagging subscribers to this area: @dotnet/area-system-reflection
See info in area-owners.md if you want to be subscribed.

Issue Details

---

SDK merge is blocked due to test failures; see dotnet/sdk#25317 (comment).

The issue is that the test is calling Assembly.GetCallingAssembly() which returns the "Anonymously Hosted DynamicMethods Assembly" instead of the expected assembly. This broke due to the recent Invoke+Emit work where a DynamicMethod is created to invoke that method and the native code that attempts to skip the reflection stack frames was not correct.

Todo:

• This issue can be reproduced in a stand-alone console app by simply using reflection to invoke a method that calls GetCallingAssembly(). However, adding the equivalent to an Xunit test I was unable to reproduce the issue. The console app included several more stack frames, including the "InvokeStub_" frame and the MethodInvoker or ConstructorInvoker frame however the xUnit test did not include those frames. We need to determine why this is the case and add an appropriate test.
• The fix here simply checks for a dynamic method starting with "InvokeStub_"; ideally it also checks to see if that dynamic method is the one generated for invoke vs. some other code that also generates a dynamic method that starts with "InvokeStub_".

Author:	steveharter
Assignees:	steveharter
Labels:	area-System.Reflection, area-VM-coreclr
Milestone:	-

[jkotas]

Agree with the TODOs

[AaronRobinsonMSFT]

@steveharter Do we want an issue to track this or is this next on your plate?

[steveharter]

Test failures due to #69232

[steveharter]

@steveharter Do we want an issue to track this or is this next on your plate?

Added #69251

[steveharter]

SDK merge is blocked due to test failures; see dotnet/sdk#25317 (comment).

The issue is that the test is calling Assembly.GetCallingAssembly() which returns the "Anonymously Hosted DynamicMethods Assembly" instead of the expected assembly. This broke due to the recent Invoke+Emit work where a DynamicMethod is created to invoke that method and the native code that attempts to skip the reflection stack frames was not correct.

Todo:

• This issue can be reproduced in a stand-alone console app by simply using reflection to invoke a method that calls GetCallingAssembly(). However, adding the equivalent to an Xunit test I was unable to reproduce the issue. The console app included several more stack frames, including the "InvokeStub_" frame and the MethodInvoker or ConstructorInvoker frame however the xUnit test did not include those frames. We need to determine why this is the case and add an appropriate test.
• The fix here simply checks for a dynamic method starting with "InvokeStub_"; ideally it also checks to see if that dynamic method is the one generated for invoke vs. some other code that also generates a dynamic method that starts with "InvokeStub_".

[ghost]

Tagging subscribers to this area: @dotnet/area-system-reflection
See info in area-owners.md if you want to be subscribed.

Issue Details

---

SDK merge is blocked due to test failures; see dotnet/sdk#25317 (comment).

The issue is that the test is calling Assembly.GetCallingAssembly() which returns the "Anonymously Hosted DynamicMethods Assembly" instead of the expected assembly. This broke due to the recent Invoke+Emit work where a DynamicMethod is created to invoke that method and the native code that attempts to skip the reflection stack frames was not correct.

Todo:

• This issue can be reproduced in a stand-alone console app by simply using reflection to invoke a method that calls GetCallingAssembly(). However, adding the equivalent to an Xunit test I was unable to reproduce the issue. The console app included several more stack frames, including the "InvokeStub_" frame and the MethodInvoker or ConstructorInvoker frame however the xUnit test did not include those frames. We need to determine why this is the case and add an appropriate test.
• The fix here simply checks for a dynamic method starting with "InvokeStub_"; ideally it also checks to see if that dynamic method is the one generated for invoke vs. some other code that also generates a dynamic method that starts with "InvokeStub_".

Author:	steveharter
Assignees:	steveharter
Labels:	area-System.Reflection, area-VM-coreclr
Milestone:	-

[jkotas]

Agree with the TODOs

[AaronRobinsonMSFT]

@steveharter Do we want an issue to track this or is this next on your plate?

[steveharter]

Test failures due to #69232

[steveharter]

@steveharter Do we want an issue to track this or is this next on your plate?

Added #69251

[steveharter]

SDK merge is blocked due to test failures; see dotnet/sdk#25317 (comment).

The issue is that the test is calling Assembly.GetCallingAssembly() which returns the "Anonymously Hosted DynamicMethods Assembly" instead of the expected assembly. This broke due to the recent Invoke+Emit work where a DynamicMethod is created to invoke that method and the native code that attempts to skip the reflection stack frames was not correct.

Todo:

• This issue can be reproduced in a stand-alone console app by simply using reflection to invoke a method that calls GetCallingAssembly(). However, adding the equivalent to an Xunit test I was unable to reproduce the issue. The console app included several more stack frames, including the "InvokeStub_" frame and the MethodInvoker or ConstructorInvoker frame however the xUnit test did not include those frames. We need to determine why this is the case and add an appropriate test.
• The fix here simply checks for a dynamic method starting with "InvokeStub_"; ideally it also checks to see if that dynamic method is the one generated for invoke vs. some other code that also generates a dynamic method that starts with "InvokeStub_".

[ghost]

Tagging subscribers to this area: @dotnet/area-system-reflection
See info in area-owners.md if you want to be subscribed.

Issue Details

---

SDK merge is blocked due to test failures; see dotnet/sdk#25317 (comment).

The issue is that the test is calling Assembly.GetCallingAssembly() which returns the "Anonymously Hosted DynamicMethods Assembly" instead of the expected assembly. This broke due to the recent Invoke+Emit work where a DynamicMethod is created to invoke that method and the native code that attempts to skip the reflection stack frames was not correct.

Todo:

• This issue can be reproduced in a stand-alone console app by simply using reflection to invoke a method that calls GetCallingAssembly(). However, adding the equivalent to an Xunit test I was unable to reproduce the issue. The console app included several more stack frames, including the "InvokeStub_" frame and the MethodInvoker or ConstructorInvoker frame however the xUnit test did not include those frames. We need to determine why this is the case and add an appropriate test.
• The fix here simply checks for a dynamic method starting with "InvokeStub_"; ideally it also checks to see if that dynamic method is the one generated for invoke vs. some other code that also generates a dynamic method that starts with "InvokeStub_".

Author:	steveharter
Assignees:	steveharter
Labels:	area-System.Reflection, area-VM-coreclr
Milestone:	-

[jkotas]

Agree with the TODOs

[AaronRobinsonMSFT]

@steveharter Do we want an issue to track this or is this next on your plate?

[steveharter]

Test failures due to #69232

[steveharter]

@steveharter Do we want an issue to track this or is this next on your plate?

Added #69251

[steveharter]

SDK merge is blocked due to test failures; see dotnet/sdk#25317 (comment).

The issue is that the test is calling Assembly.GetCallingAssembly() which returns the "Anonymously Hosted DynamicMethods Assembly" instead of the expected assembly. This broke due to the recent Invoke+Emit work where a DynamicMethod is created to invoke that method and the native code that attempts to skip the reflection stack frames was not correct.

Todo:

• This issue can be reproduced in a stand-alone console app by simply using reflection to invoke a method that calls GetCallingAssembly(). However, adding the equivalent to an Xunit test I was unable to reproduce the issue. The console app included several more stack frames, including the "InvokeStub_" frame and the MethodInvoker or ConstructorInvoker frame however the xUnit test did not include those frames. We need to determine why this is the case and add an appropriate test.
• The fix here simply checks for a dynamic method starting with "InvokeStub_"; ideally it also checks to see if that dynamic method is the one generated for invoke vs. some other code that also generates a dynamic method that starts with "InvokeStub_".

[ghost]

Tagging subscribers to this area: @dotnet/area-system-reflection
See info in area-owners.md if you want to be subscribed.

Issue Details

---

SDK merge is blocked due to test failures; see dotnet/sdk#25317 (comment).

The issue is that the test is calling Assembly.GetCallingAssembly() which returns the "Anonymously Hosted DynamicMethods Assembly" instead of the expected assembly. This broke due to the recent Invoke+Emit work where a DynamicMethod is created to invoke that method and the native code that attempts to skip the reflection stack frames was not correct.

Todo:

• This issue can be reproduced in a stand-alone console app by simply using reflection to invoke a method that calls GetCallingAssembly(). However, adding the equivalent to an Xunit test I was unable to reproduce the issue. The console app included several more stack frames, including the "InvokeStub_" frame and the MethodInvoker or ConstructorInvoker frame however the xUnit test did not include those frames. We need to determine why this is the case and add an appropriate test.
• The fix here simply checks for a dynamic method starting with "InvokeStub_"; ideally it also checks to see if that dynamic method is the one generated for invoke vs. some other code that also generates a dynamic method that starts with "InvokeStub_".

Author:	steveharter
Assignees:	steveharter
Labels:	area-System.Reflection, area-VM-coreclr
Milestone:	-

[jkotas]

Agree with the TODOs

[AaronRobinsonMSFT]

@steveharter Do we want an issue to track this or is this next on your plate?

[steveharter]

Test failures due to #69232

[steveharter]

@steveharter Do we want an issue to track this or is this next on your plate?

Added #69251

[steveharter]

SDK merge is blocked due to test failures; see dotnet/sdk#25317 (comment).

The issue is that the test is calling Assembly.GetCallingAssembly() which returns the "Anonymously Hosted DynamicMethods Assembly" instead of the expected assembly. This broke due to the recent Invoke+Emit work where a DynamicMethod is created to invoke that method and the native code that attempts to skip the reflection stack frames was not correct.

Todo:

• This issue can be reproduced in a stand-alone console app by simply using reflection to invoke a method that calls GetCallingAssembly(). However, adding the equivalent to an Xunit test I was unable to reproduce the issue. The console app included several more stack frames, including the "InvokeStub_" frame and the MethodInvoker or ConstructorInvoker frame however the xUnit test did not include those frames. We need to determine why this is the case and add an appropriate test.
• The fix here simply checks for a dynamic method starting with "InvokeStub_"; ideally it also checks to see if that dynamic method is the one generated for invoke vs. some other code that also generates a dynamic method that starts with "InvokeStub_".

[ghost]

Tagging subscribers to this area: @dotnet/area-system-reflection
See info in area-owners.md if you want to be subscribed.

Issue Details

---

SDK merge is blocked due to test failures; see dotnet/sdk#25317 (comment).

The issue is that the test is calling Assembly.GetCallingAssembly() which returns the "Anonymously Hosted DynamicMethods Assembly" instead of the expected assembly. This broke due to the recent Invoke+Emit work where a DynamicMethod is created to invoke that method and the native code that attempts to skip the reflection stack frames was not correct.

Todo:

• This issue can be reproduced in a stand-alone console app by simply using reflection to invoke a method that calls GetCallingAssembly(). However, adding the equivalent to an Xunit test I was unable to reproduce the issue. The console app included several more stack frames, including the "InvokeStub_" frame and the MethodInvoker or ConstructorInvoker frame however the xUnit test did not include those frames. We need to determine why this is the case and add an appropriate test.
• The fix here simply checks for a dynamic method starting with "InvokeStub_"; ideally it also checks to see if that dynamic method is the one generated for invoke vs. some other code that also generates a dynamic method that starts with "InvokeStub_".

Author:	steveharter
Assignees:	steveharter
Labels:	area-System.Reflection, area-VM-coreclr
Milestone:	-

[jkotas]

Agree with the TODOs

[AaronRobinsonMSFT]

@steveharter Do we want an issue to track this or is this next on your plate?

[steveharter]

Test failures due to #69232

[steveharter]

@steveharter Do we want an issue to track this or is this next on your plate?

Added #69251

[steveharter]

SDK merge is blocked due to test failures; see dotnet/sdk#25317 (comment).

The issue is that the test is calling Assembly.GetCallingAssembly() which returns the "Anonymously Hosted DynamicMethods Assembly" instead of the expected assembly. This broke due to the recent Invoke+Emit work where a DynamicMethod is created to invoke that method and the native code that attempts to skip the reflection stack frames was not correct.

Todo:

• This issue can be reproduced in a stand-alone console app by simply using reflection to invoke a method that calls GetCallingAssembly(). However, adding the equivalent to an Xunit test I was unable to reproduce the issue. The console app included several more stack frames, including the "InvokeStub_" frame and the MethodInvoker or ConstructorInvoker frame however the xUnit test did not include those frames. We need to determine why this is the case and add an appropriate test.
• The fix here simply checks for a dynamic method starting with "InvokeStub_"; ideally it also checks to see if that dynamic method is the one generated for invoke vs. some other code that also generates a dynamic method that starts with "InvokeStub_".

[ghost]

Tagging subscribers to this area: @dotnet/area-system-reflection
See info in area-owners.md if you want to be subscribed.

Issue Details

---

SDK merge is blocked due to test failures; see dotnet/sdk#25317 (comment).

The issue is that the test is calling Assembly.GetCallingAssembly() which returns the "Anonymously Hosted DynamicMethods Assembly" instead of the expected assembly. This broke due to the recent Invoke+Emit work where a DynamicMethod is created to invoke that method and the native code that attempts to skip the reflection stack frames was not correct.

Todo:

• This issue can be reproduced in a stand-alone console app by simply using reflection to invoke a method that calls GetCallingAssembly(). However, adding the equivalent to an Xunit test I was unable to reproduce the issue. The console app included several more stack frames, including the "InvokeStub_" frame and the MethodInvoker or ConstructorInvoker frame however the xUnit test did not include those frames. We need to determine why this is the case and add an appropriate test.
• The fix here simply checks for a dynamic method starting with "InvokeStub_"; ideally it also checks to see if that dynamic method is the one generated for invoke vs. some other code that also generates a dynamic method that starts with "InvokeStub_".

Author:	steveharter
Assignees:	steveharter
Labels:	area-System.Reflection, area-VM-coreclr
Milestone:	-

[jkotas]

Agree with the TODOs

[AaronRobinsonMSFT]

@steveharter Do we want an issue to track this or is this next on your plate?

[steveharter]

Test failures due to #69232

[steveharter]

@steveharter Do we want an issue to track this or is this next on your plate?

Added #69251

[steveharter]

SDK merge is blocked due to test failures; see dotnet/sdk#25317 (comment).

The issue is that the test is calling Assembly.GetCallingAssembly() which returns the "Anonymously Hosted DynamicMethods Assembly" instead of the expected assembly. This broke due to the recent Invoke+Emit work where a DynamicMethod is created to invoke that method and the native code that attempts to skip the reflection stack frames was not correct.

Todo:

• This issue can be reproduced in a stand-alone console app by simply using reflection to invoke a method that calls GetCallingAssembly(). However, adding the equivalent to an Xunit test I was unable to reproduce the issue. The console app included several more stack frames, including the "InvokeStub_" frame and the MethodInvoker or ConstructorInvoker frame however the xUnit test did not include those frames. We need to determine why this is the case and add an appropriate test.
• The fix here simply checks for a dynamic method starting with "InvokeStub_"; ideally it also checks to see if that dynamic method is the one generated for invoke vs. some other code that also generates a dynamic method that starts with "InvokeStub_".

[ghost]

Tagging subscribers to this area: @dotnet/area-system-reflection
See info in area-owners.md if you want to be subscribed.

Issue Details

---

SDK merge is blocked due to test failures; see dotnet/sdk#25317 (comment).

The issue is that the test is calling Assembly.GetCallingAssembly() which returns the "Anonymously Hosted DynamicMethods Assembly" instead of the expected assembly. This broke due to the recent Invoke+Emit work where a DynamicMethod is created to invoke that method and the native code that attempts to skip the reflection stack frames was not correct.

Todo:

• This issue can be reproduced in a stand-alone console app by simply using reflection to invoke a method that calls GetCallingAssembly(). However, adding the equivalent to an Xunit test I was unable to reproduce the issue. The console app included several more stack frames, including the "InvokeStub_" frame and the MethodInvoker or ConstructorInvoker frame however the xUnit test did not include those frames. We need to determine why this is the case and add an appropriate test.
• The fix here simply checks for a dynamic method starting with "InvokeStub_"; ideally it also checks to see if that dynamic method is the one generated for invoke vs. some other code that also generates a dynamic method that starts with "InvokeStub_".

Author:	steveharter
Assignees:	steveharter
Labels:	area-System.Reflection, area-VM-coreclr
Milestone:	-

[jkotas]

Agree with the TODOs

[AaronRobinsonMSFT]

@steveharter Do we want an issue to track this or is this next on your plate?

[steveharter]

Test failures due to #69232

[steveharter]

@steveharter Do we want an issue to track this or is this next on your plate?

Added #69251

[steveharter]

SDK merge is blocked due to test failures; see dotnet/sdk#25317 (comment).

The issue is that the test is calling Assembly.GetCallingAssembly() which returns the "Anonymously Hosted DynamicMethods Assembly" instead of the expected assembly. This broke due to the recent Invoke+Emit work where a DynamicMethod is created to invoke that method and the native code that attempts to skip the reflection stack frames was not correct.

Todo:

• This issue can be reproduced in a stand-alone console app by simply using reflection to invoke a method that calls GetCallingAssembly(). However, adding the equivalent to an Xunit test I was unable to reproduce the issue. The console app included several more stack frames, including the "InvokeStub_" frame and the MethodInvoker or ConstructorInvoker frame however the xUnit test did not include those frames. We need to determine why this is the case and add an appropriate test.
• The fix here simply checks for a dynamic method starting with "InvokeStub_"; ideally it also checks to see if that dynamic method is the one generated for invoke vs. some other code that also generates a dynamic method that starts with "InvokeStub_".

[ghost]

Tagging subscribers to this area: @dotnet/area-system-reflection
See info in area-owners.md if you want to be subscribed.

Issue Details

---

SDK merge is blocked due to test failures; see dotnet/sdk#25317 (comment).

The issue is that the test is calling Assembly.GetCallingAssembly() which returns the "Anonymously Hosted DynamicMethods Assembly" instead of the expected assembly. This broke due to the recent Invoke+Emit work where a DynamicMethod is created to invoke that method and the native code that attempts to skip the reflection stack frames was not correct.

Todo:

• This issue can be reproduced in a stand-alone console app by simply using reflection to invoke a method that calls GetCallingAssembly(). However, adding the equivalent to an Xunit test I was unable to reproduce the issue. The console app included several more stack frames, including the "InvokeStub_" frame and the MethodInvoker or ConstructorInvoker frame however the xUnit test did not include those frames. We need to determine why this is the case and add an appropriate test.
• The fix here simply checks for a dynamic method starting with "InvokeStub_"; ideally it also checks to see if that dynamic method is the one generated for invoke vs. some other code that also generates a dynamic method that starts with "InvokeStub_".

Author:	steveharter
Assignees:	steveharter
Labels:	area-System.Reflection, area-VM-coreclr
Milestone:	-

[jkotas]

Agree with the TODOs

[AaronRobinsonMSFT]

@steveharter Do we want an issue to track this or is this next on your plate?

[steveharter]

Test failures due to #69232

[steveharter]

@steveharter Do we want an issue to track this or is this next on your plate?

Added #69251