1. Effective C# 50 Specific Ways to Improve Your C# Item 46~47 2012/09/25 1

2. Agenda Item 46: Minimize Interop Item 46: Minimize Interop Item 47: Prefer Safe Code Item 47: Prefer Safe Code

3. MINIMIZE INTEROP Item 46:

4. The cost of Data Transfer The cost and inefficiencies inherent in crossing the boundary between managed and unmanaged code The cost and inefficiencies inherent in crossing the boundary between managed and unmanaged code – The first toll is paid by marshalling data back and forth between the managed heap and the native heap – The second toll is the thunking cost of moving between managed code and unmanaged code – The third toll is yours alone: the amount of work you need to perform to manage this mixed environment. The third toll is the biggest

5. The cost of Data Transfer The cost and inefficiencies inherent in crossing the boundary between managed and unmanaged code The cost and inefficiencies inherent in crossing the boundary between managed and unmanaged code – The first toll is paid by marshalling data back and forth between the managed heap and the native heap – The second toll is the thunking cost of moving between managed code and unmanaged code – The third toll is yours alone: the amount of work you need to perform to manage this mixed environment. The third toll is the biggest Our design decisions should minimize the third cost. Our design decisions should minimize the third cost.

6. The cost of Data Transfer Try to limit the data types passed between the managed and unmanaged layers of your code to blittable types Try to limit the data types passed between the managed and unmanaged layers of your code to blittable types – Blittable type

7. blittable type A blittable type is one in which the managed and unmanaged representations of the type are the same A blittable type is one in which the managed and unmanaged representations of the type are the same The benefit The benefit – The contents can be copied without regard to the internal structure of the object System.ByteSystem.SbyteSystem.Int16 System.UInt16System.Int32System.UInt32 System.Int64System.UInt64System.UIntPtr The blittable types are listed here:

8. The cost of Data Transfer If you can't restrict your data types to the blittable types If you can't restrict your data types to the blittable types – Use InAttribute and OutAttribute to control when copies are made – Make sure you apply the most restrictive In/Out combination to avoid more copying than necessary

9. The cost of Data Transfer Increase performance by declaring how data should be marshaled Increase performance by declaring how data should be marshaled – This is most common with strings – Marshalling strings uses BSTRs by default.  That's a safe strategy  It is the least efficient For example: The following declaration marshals the string as a LPWStr, or wchar*: public void SetMsg ( [ MarshalAs( UnmanagedType.LPWStr ) ] string msg [ MarshalAs( UnmanagedType.LPWStr ) ] string msg ); );

10. Transfer program control How you can transfer program control between managed and unmanaged components How you can transfer program control between managed and unmanaged components – COM interop – Platform Invoke (P/Invoke) – Managed C++

11. COM interop Benefit Benefit – COM interop is the easiest way to leverage those COM components you are already using Disadvantage Disadvantage – COM interop is the least efficient way to access native code in.NET

12. Platform Invoke (P/Invoke) Benefit Benefit – This is the most efficient way to call any of the Win32 APIs because you avoid the overhead associated with COM Disadvantage Disadvantage – You need to hand-code the interface to each method that you call using P/Invoke – The more methods you invoke, the more method declarations you must hand-code

13. Managed C++ You must build a managed C++ library on top of your legacy code to provide the bridge between the unmanaged and managed types, providing the marshalling support between the managed and unmanaged heaps You must build a managed C++ library on top of your legacy code to provide the bridge between the unmanaged and managed types, providing the marshalling support between the managed and unmanaged heaps

14. Summary If you have existing COM objects written in any language, use COM interop. If you have existing C++ code, the /CLR switch and managed C++ provide the best strategy to access your existing native codebase from new development created in C#. Pick the strategy that takes the least time If you have existing COM objects written in any language, use COM interop. If you have existing C++ code, the /CLR switch and managed C++ provide the best strategy to access your existing native codebase from new development created in C#. Pick the strategy that takes the least time

15. PREFER SAFE CODE Item 37:

16. Prefer Safe Code Avoid accessing unmanaged memory whenever possible Avoid accessing unmanaged memory whenever possible Most common security concern is the file system Most common security concern is the file system

17. Avoid accessing unmanaged memory whenever possible A safe assembly is one that does not use any pointers to access either the managed or unmanaged heaps A safe assembly is one that does not use any pointers to access either the managed or unmanaged heaps Almost all the C# code that you create is safe Almost all the C# code that you create is safe Unless you turn on the /unsafe C# compiler option, you've created verifiably safe code Unless you turn on the /unsafe C# compiler option, you've created verifiably safe code

18. Avoid accessing unmanaged memory whenever possible When you use unsafe constructs, understand that unsafe code anywhere in an assembly affects the entire assembly When you use unsafe constructs, understand that unsafe code anywhere in an assembly affects the entire assembly When you create unsafe code blocks, consider isolating those algorithms in their own assembly When you create unsafe code blocks, consider isolating those algorithms in their own assembly – This limits the affect that unsafe code has on your entire application – If it's isolated, only callers who need the particular feature are affected

19. File system security concern Partially trusted assemblies can access their own specific isolated storage area, but nowhere else on the file system Partially trusted assemblies can access their own specific isolated storage area, but nowhere else on the file system You use isolated storage through the classes in the System.IO.IsolatedStorage namespace You use isolated storage through the classes in the System.IO.IsolatedStorage namespace The IsolatedStorageFile class contains methods very similar to the System.IO.File class The IsolatedStorageFile class contains methods very similar to the System.IO.File class

20. IsolatedStorageFile IsolatedStorageFile iso = IsolatedStorageFile.GetUserStoreForDomain( ); IsolatedStorageFileStream myStream = new IsolatedStorageFileStream( "SavedStuff.txt", FileMode.Create, iso ); StreamWriter wr = new StreamWriter( myStream ); wr.Close(); Reading is equally familiar to anyone who has used file I/O IsolatedStorageFile isoStore = IsolatedStorageFile.GetUserStoreForDomain( ); string[] files = isoStore.GetFileNames( "SavedStuff.txt" ); if ( files.Length > 0 ) { StreamReader reader = new StreamReader( new IsolatedStorageFileStream( "SavedStuff.txt", FileMode.Open,isoStore ) ); if ( files.Length > 0 ) { StreamReader reader = new StreamReader( new IsolatedStorageFileStream( "SavedStuff.txt", FileMode.Open,isoStore ) ); reader.Close(); }

21. IsolatedStorageFile The.NET environment defines limits on the size of isolated storage for each application. This prevents malicious code from consuming excessive disk space, rendering a system unusable The.NET environment defines limits on the size of isolated storage for each application. This prevents malicious code from consuming excessive disk space, rendering a system unusable Isolated storage is hidden from other programs and other users Isolated storage is hidden from other programs and other users Even though it is hidden, however, isolated storage is not protected from unmanaged code or from trusted users. Do not use isolated storage for high-value secrets unless you apply additional encryption Even though it is hidden, however, isolated storage is not protected from unmanaged code or from trusted users. Do not use isolated storage for high-value secrets unless you apply additional encryption

22. Summary Avoid accessing unmanaged memory whenever possible Avoid accessing unmanaged memory whenever possible Use isolated storage whenever possible Use isolated storage whenever possible