We Keep Coding

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

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:
COM allows DLLs to expose their components by implementing some specific interfaces/methods
Excel only supports COM, and therefore only works with COM objects although it's a .NET Application.
.NET provides COM interop for applications such as Excel that cannot work with .NET components directly
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?
Does the .COM interop also allow .NET applications that do not rely on COM, unlike Excel, to also use COM objects?
What exactly does the language neutralization? COM or .NET? How?

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://learn.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

Creation of .Ocx File from a .Net Dll

I have a .Net Com Dll is it possible to use this dll and create .OCX file in c++ or MFC. If yes what are all the steps which needs to be followed. If any sample code is availabe that would be a great help

You could expose the .NET assembly as COM object using the regasm.exe tool. You could use the [ComVisible(true)] to indicate that all classes should be visible by COM clients when registered. This assembly level attribute could also be set in the properties of the project in Visual Studio. You could also apply it only to some classes that need to be exported. Once the assembly registered as COM object you could instantiate any class from unmanaged clients as with any standard COM object.

There is nothing particularly special about an .ocx file, it is just a DLL. Microsoft came up with that filename extension back in the Visual Basic version 4 days to make it obvious to VB programmers that they had a DLL that contains controls. ActiveX controls as opposed to VBX controls from the 16-bit days.
If you made the .NET assembly [ComVisible] then you already have a COM server that's usable in other projects. Provided you registered it properly, .NET assemblies must be registered with Regasm.exe instead of Regsvr32.exe. Done automatically in a .NET project with the Project + Properties, Build tab, "Register for COM interop" option. And at installation time with a Setup and Deployment project. If you need a type library then use Regasm.exe with the /tlb and /codebase options. Or Tlbexp.exe
If this really needs to be a traditional .ocx, in other words have controls, then you can use a Winforms UserControl or your own class derived from a Winforms control. Winforms automatically implements the plumbing to make classes derived from the Control class function properly in an ActiveX host.

If you're wanting to use a .NET library in normal C++, there are ways, mostly involving COM Interop. Microsoft has a whole section of MDSN dedicated to COM Interop: http://msdn.microsoft.com/en-us/library/6bw51z5z%28v=VS.71%29.aspx.
If the .NET DLL supports COM Interop, use that.
Try using VC++'s #import directive to read the .NET DLL in as a COM object. When compiled, VC++ should output a .tlh file and a .thi file (header and implementation respectively) which will be automatically compiled into your project. But this may or may not work depending on the DLL's construction, dependencies, etc.
Look at creating your own COM Interop .NET wrapper library that marshals calls to the base .NET DLL.

How to create native DLL in Visual Studio from C# code?

I have the source code of a C# program. I want to create a DLL out of it which I want to use in C++.
Is it possible to create a native DLL in Visual Studio 2008 which can be used in C++?

native <-> .Net interop is one of my pet disciplines, which is why I needed this as straightforward and reliable as possible.
The result was that I made me an MSBuild task which I just need to drag into a project to allow me to export static methods from pretty much any .Net language. And since the whole marshalling infrastructure works for exports as well, you can do pretty much anything with it that you want (like passing native/managed objects as IUnknown).
The resulting assembly will look to the consuming process like a real DLL, which means you can't have it to scale up to 64bit automatically anymore.
However, since you do have native bits in your application, you already have this issue anyways. ;-)
When you do not specifiy the CPU target in your C# project, my task will emit a warning that it created a folder for all targets (x86,x64 and Itanium), and there you'll have *.dll and *.pdb for each platform.

If you want the program to be native, and not managed, you'll need to port it to C++, instead of using C#.
That being said, you can compile it in C# into a library, and use it from C++ by using C++/CLI. This just requires that you compile the files that use the C# library with the /clr flag. This provides C++ access to the .NET framework, and lets you use libraries made in C# directly from C++.
Alternatively, you can use .NET's COM interop to expose the C# class(es) as COM objects, and then use those from native C++.

It is possible in Visual Studio 2008, but you're not going to be able to write it using C#.
To create a native DLL, you'll have to write your code using one of the unmanaged C++ project types.

You can expose the DLL to COM. Have a look here for some examples.

yes you can.
you need to create second project.
the project must be unmanaged (like "visual c++"->class library).
the name of this procedure is "calling from unmanaged code to managed code".
good to read unmanaged to managed (codeproject)
you must be aware, that any computer that using your dll must have preinstalled DotNet and Visual C++ Redistributable Package

Java to C# Translator

I heard that JNBridge will translate C# code to native Java code.( I haven't tested it).
Is there any tool available in market to translate Java code to native C# ?(or Will JNBridge also translate Java code to C# ?)

Are you talking about a source code converter, or the ability to run Java code in a CLR?
If it's the latter, you might want to look at IKVM:
IKVM.NET is an implementation of Java
for Mono and the Microsoft .NET
Framework. It includes the following
components:
A Java Virtual Machine implemented in
.NET
A .NET implementation of the Java
class libraries
Tools that enable Java
and .NET interoperability

Microsoft's Visual Studio 2005 included a Java to C# conversion tool (the Java Language Conversion Assistant). Although they announced in 2007 it wouldn't be developed further (and it isn't in VS 2008) it is still a supported product until 2015.

I don't think that direct "code translating" could be possible, what with invoking API functions? (like, each technology has it's own collections, etc.). Link that you have given, doesn't seem to be code translator, rather - libraries that allows one to connect components, like embedding java GUI inside WPF app etc.
Also, on the main page of JNBridge, they are writing:
Bridge anything Java to .NET
Bridge anything .NET to Java
So it might a good idea to check someone's site before asking about possibilities of their platform.

Calling C# from native C++, without /clr or COM?

I have a class library written in C#, and I want to call it from a legacy native C++ application. The host application is truly native, compiled on Windows and Linux, and it’s a console application. So how can I make it call the C# class library, assuming using Microsoft .NET on Windows, and Mono on Linux?
I have looked at SWIG and wrapping with COM interfaces on Windows, but is there a standard recognized solution that works cross platform? I.e., that is generic, works with both Microsoft .NET and Mono. A write-once-use-everywhere implementation.
Solutions should expose the full class interfaces from the C# domain to the C++ domain.
Similar questions focus only on the Windows solutions, for example -
Call C# methods from C++ without using COM

If you want to do this cross platform, I would recommend going with a 100% Mono approach.
Mono has a clean Embedding API which works on Linux and Windows.

With .NET 5.0 (the successor of .NET Core) this is now possible to call C# from C++ in a cross-platform way without using Mono. Please see the solution explained in this GitHub issue using DNNE to generate a shared library and GCHandles to access C# objects.
With this you get a shared library that can be used from C or C++. Note that this will give a C-like API (no objects, like when using extern C in C++), in the future there may be tools like SWIG for C++ to overcome this limitation.