I'm working on a project that uses a bunch of WIN32 API calls and requires some unsafe code. From a best practices standpoint should I isolate this code in its own DLL compiled with /unsafe switch while keeping my main application safe?
To put it another way. Is there any reason not to compile a project with the /unsafe switch? Are there any potential risks?
An assembly is by definition the smallest unit of independently versionable, redistributable code in .NET. Therefore the first question I would ask myself is "am I ever going to want to make a new version of the unsafe code and distribute it independently of my application?"
If the answer is yes, then by all means, put that code in its own assembly.
If the answer is no, then consider other factors. For example, in "classic" .NET security you can have different assemblies running at different levels of trust in the same appdomain. (In the modern CLR the system is much simpler, there is just fully trusted code and everything else runs at the level of trust granted to the appdomain.) Your code which does something unsafe needs to be fully trusted, but the code which simply calls it could be less trusted if the unsafe code asserts the correct set of permissions.
Are you ever going to be in a situation where your safe code is partially trusted? If so, then by all means, put the unsafe code in its own assembly, and then document that this assembly must be fully trusted.
If you're not in those sorts of situations then I would not be inclined to put my unsafe code in its own assembly.
I would however be inclined to writing a pleasant managed object model on top of my unmanaged code, rather than simply exposing raw win32 calls. For example, the other day I needed to call some of the strong name verification win32 apis from C# and I just whipped up a little library that exposed them nicely, abstracting away all the nasty interop details to the private interior of the class.