Read this article in my
blog here.
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.