I am currently creating a managed wrapper for an unmanaged dll. Point - the shell makes TON calls an unmanaged dll, but exports very few methods. From the research I did, this should be safe, but I want to make sure that I understand it correctly. Essentially, this is how I do it.
[SuppressUnmanagedCodeSecurity()] internal static class SomeAPI { [DllImport("base.dll"] internal static extern bool Somefunc(); [...] Other internal DllImports } public class Wrapper : IDisposable { [SecurityPermission(SecurityAction.Demand, UnmanagedCode = true)] public Wrapper() { SomeAPI.SomeFunc(); } public void Dispose() { Dispose(true); GC.SuppressFinalize(this); } [SecurityPermission(SecurityAction.Demand, UnmanagedCode = true)] protected override void Dispose(bool disposeManagedResources) { SomeAPI.SomeFunc(); } }
Each method that I add that is protected or public should receive the attribute [SecurityPermission (SecurityAction.Demand, UnmanagedCode = true)]. And I mean everyone, to avoid the random code path that leads to the SomeAPI call.
Now, any method added to Wrapper that is internal or private is "safe." Is this assumption correct?
Sorry if I do not understand. I am writing a wrapper so that it does not reformat the hard drive or something like that. The wrapper will open in its own managed dll (along with other things). Since a single wrapper call can result in 100 unmanaged DLL calls, I do not want the CLR performance overhead to check all of these calls - thus using SuppressUnmanagedCodeSecurity. The docs mention "Use this attribute with extreme care." Improper use can create security flaws. "And here is what I ask, I am again" safe "using the above methodology.
user836755
source share