Hi.
I am programming in C#. I would like to use unsafe code for improve the performance of a scientific library.
However, I am not sure about the implications of the unsafe code on the portability of the library.
The Visual Studio documentation says:
“In the common language runtime (CLR), unsafe code is referred to as unverifiable code. Unsafe code in C# is not necessarily dangerous; it is just code whose safety cannot be verified by the CLR. The CLR will therefore only execute unsafe code if it is in a fully trusted assembly”.
What is a fully trusted assembly?
I know that it is not possible to run unsafe code directly from the Internet. However this is not a problem for my library because is not designed for that. Is there another limitation?
Can all use my library or what do the users need to do?
I have the same library in Fortran. However I would like to use unsafe code in C# because I eliminate the overhead associated whit the unmanaged calls?
Which library do you think is better to distribute, the Fortran o the C# library with unsafe code?
Best Regards.
AlanPosted Jan 2, 2008, 4:26 PM
A fully trusted assembly is essentially one where verification is considered unnecessary, the most obvious examples being the .NET framework dlls themselves.
If your users will only be installing your library on their local machine, then the use of unsafe code should not be a problem as verification is turned off by default in that situation.
In other situations, the dll assembly would need to be a given a strong name, installed in the user's GAC and added to the user's fully trusted assembly list by the administrator using caspol.exe:
http://msdn2.microsoft.com/en-us/library/771ss30w(VS.80).aspx
If these limitations are acceptable to the user, then I'd use unsafe C# rather than P/Invoking Fortran functions. If not, then you'll have to do the latter.
If it's not practicable to support both ways of working, then I think I'd go for P/Invoking Fortran to be on the safe side.
One other point is that if your unsafe C# functions take parameters and/or have return types which are pointers, then you won't be able to call them from VB.Net which some of your potential users may be using. If that's a problem, then you could try and provide an alternative function whose signature doesn't require explicit pointers.