How does COM complement the .NET Framework when building DLLs?

Question

Over the past couple of weeks I was working on building a custom DLL extension for Excel that I wrote in C# and built as a COM object with COM interop enabled through Visual Studio. The DLL itself works fine but I want to understand the technology behind it.

After reading a few articles and posts I got confused quite a bit and can't seem to find the information that explains exactly how COM and the .NET Framework work together to allow us to build these DLLs and why we need both of them.

My current understanding:

COM - a way to create binary objects that are language-independent and can be used in different environments. (For example you write a C# object, build it as a COM object, and then you can use it in your VB Script in Excel)

.NET Framework - a framework that provides a common run-time environment for all supported languages and allows language interoperability between them. (In other words a C# object can be used by a VB Script due to the CLR)

The Confusion:

In one of the articles COM was presented as a predecessor to the .NET Framework that requires a lot of extra logic from developers in order to manage their code(COM => unmanaged code). The .NET Framework takes care of that now and has a way to deal with unmanaged code as if it were managed code under the .NET Framework.

If COM and .NET Framework objects are technically cross-language compatible, why can't we simply use Visual Studio to build a C# DLL, build it and reference it in Excel as an add-in? Why do we need to register the assembly as COM object and enable it for COM interop if the .NET framework should already provide this language interoperability and all the code management features?

Perhaps it would be best if you can really explain the relationship between the 2 technologies and how exactly the "make assembly COM visible" and "register for COM interop" settings in Visual Studio tie in together with them.

Thanks, Dimitar

EDIT:

Update 04/22/19:

After reading your feedback below I get the following:

1. COM allows DLLs to expose their components by implementing some specific interfaces/methods

2. Excel only supports COM, and therefore only works with COM objects although it's a .NET Application.

3. .NET provides COM interop for applications such as Excel that cannot work with .NET components directly

4. The COM visible setting tells COM which parts of your object you want to be available for COM use. The COM interop decorates the C# object with the necessary interfaces/methods in order to make it usable by COM.

Things I still need clarified:

1.Is my C# object in Visual Studio considered a .NET component if not COM enabled? I assume yes.

2.Is COM interop the main thing that turns Excel into a .NET application?

3. Does the .COM interop also allow .NET applications that do not rely on COM, unlike Excel, to also use COM objects?

4. What exactly does the language neutralization? COM or .NET? How?

Answer 1

COM is an older technology and existed much before .NET , Component Object Model was created by MS and used to allow DLLs to expose their components and callers to simply query if a loaded component would implement the specific interface the caller was looking for.

Every COM library or object is implementing at least one interface called IUnknowk and a method called QueryInterface could be used to check if that object implemented a specific interface.

When MS introduced .NET Framework in 2001, it has decided to support, by design, from day one and natively a paradigm called COM / .NET interoperability, this means that from .NET you can consume COM libraries and also that by selecting the COM Interop flag in project properties you get the .NET compiler to decorate your assembly with such extra parts required by COM; like the IUnknown and QueryInterface attributes.

Excel and any other COM consumer can then use that approach to find objects and methods in your COM enabled .NET assembly.

As Excel COM loader ( or VBA or VB Script languages ) are older than .NET, these tools cannot find .NET objects natively as those were designed to consume COM only and so look for iUnknown interface etc.

hope it helps, there is lots of documentation online about this matter, for instance here

https://docs.microsoft.com/en-us/dotnet/visual-basic/programming-guide/com-interop/index

but also much much more depends on which aspect i particular you are interested about