Replies: 1 comment
-
The security restriction of .NET Core should be less strict than .NET Framework. If the code worked on .NET Framework with all feature supported, it should probably work on .NET Core without modification. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hi,
I've recently started working on dynamic code coverage for .NET apps (built in VS). Our solution is instrumenting .NET core and .NET framework IL code dynamically using CLR Instrumentation Engine or Intellitrace. We are basically adding few instructions which are setting associated place as covered in array (ldc.i4/ldc.i8, ldc.i4.1, stind.i1).
Such instrumentation was causing issues for Silverlight and other "less-than-full trust" applications. So we introduced another way of instrumentation which was just calling method in different assembly (fully-trusted). This method was marking block as covered in array.
I found here that: "CAS is not supported in .NET Core, .NET 5, or later versions. CAS is not supported by versions of C# later than 7.0."
Does this mean that we never need to use other assemblies for marking inside array for .NET Core and .NET 5? In other words adding for every block set of instructions: ldc.i4/ldc.i8, ldc.i4.1, stind.i1 should never lead to security exception for .NET Core and .NET 5?
How to find out in runtime if app running is .NET Core or .NET Framework inside profiling environment? Is it available in ICorProfilerInfo[n] intefrace?
BR,
Jakub
Beta Was this translation helpful? Give feedback.
All reactions