COM and .NET Interoperability
The funny thing about writing a book on COM and .NET interoperability is that one author could craft a five- to ten-page article describing the basic details that you must understand to get up and running with interop-related endeavors. At the same time, another author could write volumes of materia...
Wedi'i Gadw mewn:
| Prif Awdur: | |
|---|---|
| Fformat: | Llyfr |
| Iaith: | English |
| Cyhoeddwyd: |
Apress
2012
|
| Pynciau: | |
| Mynediad Ar-lein: | https://scholar.dlu.edu.vn/thuvienso/handle/DLU123456789/30928 |
| Tagiau: |
Ychwanegu Tag
Dim Tagiau, Byddwch y cyntaf i dagio'r cofnod hwn!
|
| Thư viện lưu trữ: | Thư viện Trường Đại học Đà Lạt |
|---|
| Crynodeb: | The funny thing about writing a book on COM and .NET interoperability is that one author could craft a five- to ten-page article describing the basic details that you must understand to get up and running with interop-related endeavors. At the same time, another author could write volumes of material on the exact same subject. So, you may be asking, how could this massive discrepancy between authors possibly exist?
Well, stop and think for a moment about the number of COM-aware programming languages and COM application frameworks that exist. Raw C++/IDL, ATL, MFC, VB 6.0, and Object Pascal (Delphi) each have their own syntactic tokens that hide the underbelly of COM from view in various ways. Thus, the first dilemma you face as an interop author is choosing which language to use to build the COM sample applications.
Next, ponder the number of .NET-aware programming languages that are either currently supported or under development. C#, VB .NET, COBOL .NET, APL .NET, PASCAL .NET, and so on, each have their own unique ways of exposing features of the CTS to the software engineer. Therefore, the next dilemma is choosing which language to use to build the .NET applications. |
|---|