|
|
This article is also available in blog
Overview
In this article and the
few following it, we'll try to take a tour in Interoperability in .NET
Framework.
In this lesson, we'll start by an introduction to the concept
of Interoperability. In the next few lessons, we'll have a look at
Interoperability and how it fits into the .NET Framework and other
technologies.
Since Interoperability is a very huge topic and cannot be
covered in just a few articles, we'll concentrate on Interoperability in .NET
Framework (not any other technologies) and summarize its uses.
Here we
go!
Introduction
Let's get hands on the concept of
Interoperability and it's relation to the .NET
Framework.
Concept
Interoperability (reduced to Interop) is
the ability of two diverse systems or different systems to communicate (i.e.
inter-operate) with each other. When I say 'two systems' I assume that the first
one is always the .NET Framework, since we are interested in .NET and also the
interoperability is a very huge topic and cannot be summarized in just a few
articles. The other system might be any other software, component, or service
based on any technology other than the .NET Framework. For example, we could
interoperate with Win32 API, MFCapplications, COM/ActiveX components, and so
on.
So we have two different systems, the first is the .NET Framework,
while the other is any other technology. Our goal is to communicate with that
stranger; that's the main goal of Interoperability in .NET
Framework.
Goals and Benefits
Here comes a question (or a
few questions!), why do I need interoperation? Why I do need to communicate with
other systems at all? If I need specific features, couldn't I just use existing
functionalities of .NET Framework to accomplish my tasks? I can even redevelop
them!
We can summarize the answer of those questions in a few
points:
First, in many cases, you can't redevelop those components
because the functionalities they offer is either very difficult (sometimes
impossible) or maybe you don't sufficient knowledge to redevelop them! Unless if
you are very brilliant and have enough knowledge of the Assembly language, you
can develop your API that would replace current system API, and then you'll have
also to interoperate with your API to be able to call it from your .NET
Framework application.
If you're not convinced yet, this is should be for
you. You might be not having enough time to redevelop the component that may
take a very long time and effort to complete. Imagine how much time would take
to code, debug, and test your component. Plus, you can rely on existing
components and trust them, many bugs can appear in your code from time to time
and you'll have to fix them all!
Other 3rd party component might not
exist, or maybe the company you work for require you to use such those
components.
You don't need to reinvent the wheel, do you?
So,
including Interop code in your .NET projects is sometimes inevitable (especially
when working with Windows API) that you definitely can't keep yourself away from
them.
Summary
So you have now basic understanding of what
Interoperability means. As a reminder, Interoperability is the process of two
diverse systems communicate with each other. For us, the first system is the
.NET Framework. The other system is any other technology (Windows API, MFC,
COM/ActiveX, etc.)
You can't live without Interop, actually you did some
interoperation in your work (you may be actually do that every day.)
Now
you are ready to take a look at how Interop fits in .NET Framework.
| | Responses | |
No response found. Be the first to respond this post
| |
You must Sign In To post reply |
| | | Find More Articles on C#, ASP.Net, Vb.Net, SQL Server and more Here |
|
|