Does "native" and "unmanaged" code refer to the same concept! or they are different!
Is there an unmanaged code which is not native!
There are three modes the C++/CLI compiler can operate in:
Compiling standard C++ "native types" to machine code (unmanaged)
Compiling standard C++ "native types" to MSIL (managed)
Compiling managed types to MSIL (managed)
As you can see, it is possible for standard ISO C++ code to be compiled and executed in the managed environment.
Unmanaged code refers to native code. It means that it's not managed by the .NET Framework.
Related
I've read the documentation on .NET programming in C++/CLI, and understand at a high level that it can compile C or C++ to .NET MSIL. I also understand that native structures are translated in the process.
The question is, can I compile a C/C++ codebase into a .NET Portable Class Library using C++/CLI? The intention is to use the result across various platforms, e.g. the Xamarin platforms and UWP.
Edit: Is it easier to do this for plain C, rather than C++?
Short answer: AFAIK no.
Long answer:
As far as I know the C++/CLI source code is compiled in "mixed" mode. It means that if you learn C++/CLI language and create managed classes with it, they run in .NET natively. That's good. But if you simply take your existing C++ code and compile it, the result is the native x86/Windows code, which cannot be used on other platforms. It is called "mixed" because the compiler puts native and .NET IL code together to single executable file.
C++/CLI is usually used in situations where you want to use the existing C++ code
as a part of .NET program in Windows. So you create a library in C++/CLI and create an interface for it in managed C++/CLI. This managed C++/CLI interface is a bridge between native C++ code and the rest of your program in .NET.
Also, as far as I know, C++/CLI is generally not supported by CoreCLR.
When programming in C++/CLI, you occassionally receive compilation errors, since some C++ features (like std::thread for instance) are not supported when compiling with /clr.
I wonder if there is a (resonably up-to-date) document clarifying which C++ constructs are not possible in managed code? Does anybody have a link or a hint where to find something?
Just to make clear: I'm pretty aware that in a managed class, i.e. ref class etc., the subset of possible C++ features is restricted even further. My question is targeting ordinary unmanaged code that happens to be compiled with /clr switched on.
MSDN has a "Migrate to clr" guide, try reading it for a start.
I am writing a dll in native code (C++) that is to be consumed by other native C++ applications.
One of the tasks of the dll is to perform XML file operations. C++ has poor support in dealing with XML files, e.g searching, writing, reading, as far as I know.
So, I am thinking if I can compile my dll code in clr:mixed mode and use the .NET XML assembly to do the XML related stuff. However, I still want my dll to be consumed by native C++ applications without any added hassles.
Will this approach work ? Any caveats to this ? Btw, is there any other XML library for C++ besides XMLlite ?
I am interested to learn more about how the .NET framework works internally. I have downloaded Reflector and also SSCLI. The following link says: "The Shared Source CLI is a compressed archive of the source code to a working implementation of the ECMA CLI and the ECMA C# language specification": http://www.microsoft.com/en-gb/download/details.aspx?id=4917.
Does the SSCLI not include the source code for the implementation of VB.NET i.e. only C sharp?
I realise that the VB.NET specification can be downloaded here: http://www.microsoft.com/en-us/download/details.aspx?id=15751
The SSCLI distribution was intended to help anybody to port a compliant implementation of the CLR to another platform. Most of it is C++ source code, the language used to implement the CLR, just-in-time compiler and the C# and JScript compilers. The .NET framework libraries were written in C#, that's included as well. They are a pretty decent snapshot of the source code used in .NET 2.0, albeit that it is hard to tell what might have been removed or substituted. I've never run into an obvious mismatch, but it gets less and less obvious with this source code aging and departing more and more from current .NET releases.
But no, there is no VB.NET compiler included, nor the source code for the classes in the Microsoft.VisualBasic namespace. Nor is there a C++/CLI compiler. The included C# and JScript compilers are also not a complete implementation of the Microsoft version of those compilers, the Windows and VS specific bits were removed. Particularly the C# compiler source code is dated, a lot of work was done on it since.
When I was reading about DLLs on StackOverflow I came accross the word "Native DLLs" a lot of times. I found questions regarding them but I couldn't understand what a "Native DLL" actually is.
What is a native DLL?
Native DLL's are usually DLL's containing raw processor directly-executable code (such as that found in the Win32 API's) as opposed to, for example, managed (MSIL) which contain code that is consumed and JIT compiled to native processor instructions by a runtime such as the .NET CLR.
In .NET it is also possible to create mixed-mode DLL's that contain both native binary code and managed code.
this term came out when managed code that comes from .net assemblies was invented, to distinguish between managed and unmanaged =native code.
every .net assembly gets "nativied" by the JIT-compiler during execution. this means it gets translated to asm code that is "natively" understandable to the CPU.
The term native DLL was originally used before managed code existed. It was originally intended to refer to DLLs that are not COM DLLs. It is intended to refer to DLLs like the ones in Windows originally.
Note that Kev said "In .NET it is also possible to create mixed-mode DLL's that contain both native binary code and managed code." but that is not relevant; such a DLL is not a native DLL because it has CLI (.Net) metadata. Also, mixed-mode DLL's can only be developed using C++/CLI; no other language supports it.
See my article Native Windows Dynamic Link Libraries (DLLs) for more.
From what I understand a "Native DLL" will be a basic Win32 dll for example. A DLL that contains non managed code.
With .NET you write Managed assemblies. These will call the base level Windows code which is the same that a non-managed application will call.
A quick look through these MSDN search results will answer your question:
http://social.msdn.microsoft.com/Search/en-US?query=define:%20native%20dll&ac=8
It's simple a DLL that contains machine code, rather than MSIL.