NGWS SDK Documentation  

This is preliminary documentation and subject to change.
To comment on this topic, please send us email at ngwssdk@microsoft.com. Thanks!

Using Managed Wrapper Classes

Most applications and components (except secure libraries) should not directly call unmanaged code. There are several reasons for this. If code calls unmanaged code directly, it will not be allowed to run in many circumstances since code must be granted a high level of trust in order to call native code. If policy is modified to allow such an application to run, it can significantly weaken the security of the system, leaving the application free to perform almost any operation.

In addition, if code has permission to access unmanaged code, it can probably perform almost any operation by calling into an unmanaged API. For instance, if code has permission to call unmanaged code, then it doesn’t need FileIOPermission to access a file -- it can just call an unmanaged (Win32) file API directly without going through the managed file API that requires FileIOPermission. If managed code has permission to call into unmanaged code and it does call directly into unmanaged code, the security system will not be able to reliably enforce security restrictions, since the runtime cannot enforce security restrictions on unmanaged code.

If you want your application to perform an operation that requires accessing unmanaged code, then it should do so through a trusted, secure managed class that wraps the required functionality (if such a class exists). Do not create a wrapper class yourself if one already exists in a secure class library. The wrapper class, which must be granted a high degree of trust to be allowed to make the call into unmanaged code, is responsible for demanding that its callers have whatever permissions are appropriate. If you use the wrapper class, your code just needs to request and be granted the permissions that the wrapper class demands.