• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            隨筆 - 42  文章 - 3  trackbacks - 0
            <2025年6月>
            25262728293031
            1234567
            891011121314
            15161718192021
            22232425262728
            293012345

            常用鏈接

            留言簿(2)

            隨筆檔案

            文章檔案

            網頁收藏

            搜索

            •  

            最新評論

            閱讀排行榜

            評論排行榜


            This note is about book .NET and COM.

            Think of XML Web services simply as components or Application Programming Interfaces (APIs) exposed on a Web site rather than a DLL residing on your own computer.

            An assembly is a self-describing logical component. Assemblies are units of deployment, units of security, units of versioning, and units of scope for the types contained within. Although an assembly is typically one executable or one DLL, it could be made up of multiple files. 

            Any assemblies with type definitions contain corresponding type information describing them. This information is called metadata (data about data). 

            Reflection
             is the process of programmatically obtaining type information. Programs can dynamically inspect (“reflect upon”) the metadata for any assemblies, dynamically instantiate objects and invoke members, and even emit metadata dynamically (a technology called Refection Emit). Reflection provides late binding facilities like COM’s IDispatch and IDispatchEx interfaces, type inspection like COM’s ITypeInfo and ITypeInfo2 interfaces, and much more.

            How Unmanaged Code Interacts with Managed Code

            Three technologies exist that enable the interaction between unmanaged and managed code:

            • Platform Invocation Services (PInvoke)

               1 static class GameSharp
               2 {
               3     /// The native methods in the DLL's unmanaged code.
               4     internal static class UnsafeNativeMethods
               5     {
               6     const string _dllLocation = "CoreDLL.dll";
               7     [DllImport(_dllLocation)]
               8     public static extern void SimulateGameDLL(int a, int b);
               9     }
              10 }

              Choosing a Calling Convention

              The calling convention of an entry point can be specified using another DllImportAttribute named parameter, called CallingConvention. The choices for this are as follows:

              • CallingConvention.Cdecl. The caller is responsible for cleaning the stack. Therefore, this calling convention is appropriate for methods that accept a variable number of parameters (like printf).

              • CallingConvention.FastCall. This is not supported by version 1.0 of the .NET Framework.

              • CallingConvention.StdCall. This is the default convention for PInvoke methods running on Windows. The callee is responsible for cleaning the stack.

              • CallingConvention.ThisCall. This is used for calling unmanaged methods defined on a class. All but the first parameter is pushed on the stack since the first parameter is the this pointer, stored in the ECX register.

              • CallingConvention.Winapi. This isn’t a real calling convention, but rather indicates to use the default calling convention for the current platform. On Windows (but not Windows CE), the default calling convention is StdCall.

              Declare always uses Winapi, and the default for DllImportAttribute is also Winapi. As you might guess, this is the calling convention used by Win32 APIs, so this setting doesn’t need to be used in this chapter’s examples.

               1 using System;
               2 using System.Runtime.InteropServices;
               3 
               4 public class LibWrap
               5 {
               6 // C# doesn't support varargs so all arguments must be explicitly defined. 
               7 // CallingConvention.Cdecl must be used since the stack is  
               8 // cleaned up by the caller. 
               9 
              10 // int printf( const char *format [, argument] )
              11 
              12 [DllImport("msvcrt.dll", CharSet=CharSet.Unicode, CallingConvention=CallingConvention.Cdecl)]
              13 public static extern int printf(String format, int i, double d); 
              14 
              15 [DllImport("msvcrt.dll", CharSet=CharSet.Unicode, CallingConvention=CallingConvention.Cdecl)]
              16 public static extern int printf(String format, int i, String s); 
              17 }
              18 
              19 public class App
              20 {
              21     public static void Main()
              22     {
              23         LibWrap.printf("\nPrint params: %i %f", 99, 99.99);
              24         LibWrap.printf("\nPrint params: %i %s", 99, "abcd");
              25     }
              26 }
            • Mixed-Mode Programming Using Managed Extensions to C++

            • COM Interoperability

                     

                  Good COM server implementation in C#

                  Building COM Objects in C#

                 Building COM Servers in .NET








            posted on 2013-06-27 03:32 鷹擊長空 閱讀(333) 評論(0)  編輯 收藏 引用
            久久综合亚洲色HEZYO社区 | 欧美日韩精品久久久久| 69久久夜色精品国产69| 四虎国产精品免费久久5151| 精品无码人妻久久久久久| 久久久久久国产精品无码下载| 蜜臀av性久久久久蜜臀aⅴ麻豆| 99久久精品免费| 亚洲精品无码久久久久sm| 精品国产一区二区三区久久蜜臀 | 97精品依人久久久大香线蕉97| 亚洲乱码中文字幕久久孕妇黑人| 丰满少妇人妻久久久久久4| 久久99久久99精品免视看动漫| 狠狠色丁香婷婷久久综合不卡 | 久久婷婷久久一区二区三区| 亚洲?V乱码久久精品蜜桃 | 国产精品毛片久久久久久久| 久久综合给合综合久久| 91精品国产高清久久久久久io| 伊人精品久久久久7777| 亚洲成色999久久网站| 欧美熟妇另类久久久久久不卡| 久久精品女人天堂AV麻| 日本免费一区二区久久人人澡| 久久久久久国产精品无码超碰 | 国产精品久久网| 99久久er这里只有精品18| 国产A三级久久精品| 久久人人爽人人人人爽AV| 色综合久久久久综合99| 久久精品国产第一区二区| 国产69精品久久久久99| 香港aa三级久久三级| 久久99久久99小草精品免视看| 97精品伊人久久大香线蕉app| 欧美喷潮久久久XXXXx| AV色综合久久天堂AV色综合在| 久久99久久99精品免视看动漫| 久久久久久久人妻无码中文字幕爆| 亚洲日本va中文字幕久久|