• <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
            <2012年3月>
            26272829123
            45678910
            11121314151617
            18192021222324
            25262728293031
            1234567

            常用鏈接

            留言簿(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 鷹擊長空 閱讀(325) 評論(0)  編輯 收藏 引用
            国产女人aaa级久久久级| 热99re久久国超精品首页| 久久久精品波多野结衣| 亚洲精品国产自在久久| 无码AV波多野结衣久久| 亚洲国产精品久久| 久久精品不卡| 久久午夜羞羞影院免费观看| 国产一级做a爰片久久毛片| 精品久久久久久无码免费| 亚洲国产精品一区二区久久hs| 久久se精品一区精品二区| 久久亚洲精品国产精品婷婷 | 久久笫一福利免费导航| 久久综合精品国产二区无码| 久久99精品久久久久久不卡| 久久发布国产伦子伦精品 | 久久精品亚洲乱码伦伦中文| 久久久久久久免费视频| 岛国搬运www久久| 久久福利青草精品资源站| 欧美日韩精品久久免费| 国产一区二区精品久久岳| 99热成人精品热久久669| 精品国产乱码久久久久软件| 爱做久久久久久| 国产午夜精品久久久久免费视| 久久久久免费精品国产| 一级女性全黄久久生活片免费| 国产精品女同一区二区久久| 狠狠久久亚洲欧美专区| 精品永久久福利一区二区| 久久综合狠狠综合久久综合88| 一本色道久久88综合日韩精品| 国产精品美女久久久久av爽| 久久91综合国产91久久精品| 日本久久久久久中文字幕| 国产精品丝袜久久久久久不卡| 久久精品国产亚洲欧美| 青青草原综合久久大伊人精品| 色综合久久中文色婷婷|