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 ?
Related
Is there any way, I can prevent my c++ cli project from being decompiled if someone uses a C# decompiler, because I tried to decompile the .exe i made in ILSpy and it showed my whole code, so is there any way I can prevent this?
Thanks
as ancient as this thread is, I ran across it with the same question, and a newish answer. Can't specify the minimum version for this one, but
[module:System::Runtime::CompilerServices::SuppressIldasmAttribute];
on top of each .cpp module did the trick for me:
I didn't investigate much further, yet.
Another useful thing is to add
#pragma unmanaged
to each .cpp that does not contain .net code.
You can
Use a .NET obfuscator.
Or
Only use C++CLI for the boundaries of your app which require to Interact with .NET. And implement your logic in a native C++ library.
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.
I need to convert all types of audio formats to the mp3.
I think I need to add the refrence of the dll (lame_enc.dll) into my .net application.
When I try to add the DLL reference to my project, I get an error: "A reference to C:\Lame_Enc.dll could not be added. Please make sure this file is accessible and that it is a valid assembly or COM component"
Is there any other solution that I can convert all types of audio formats to the mp3 and also I need to convert all types of video formats to the flv.
Many thanks for your consideration.
Why reinvent the wheel? Here
http://www.codeproject.com/KB/audio-video/MP3Compressor.aspx
you find a .NET wrapper library for lame_enc.dll. It is written in C#, but usage from VB.NET should be no problem.
By the way, if you want to use native DLLs (no COM, no .NET) from a VB.NET program, you don't have to add a reference to that DLL, you just have to copy that DLL into your working directory of your VB.NET program and use PInvoke. Read this tutorial (C# only, sorry)
http://msdn.microsoft.com/en-us/library/aa288468%28v=vs.71%29.aspx
to learn more about it.
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.
When creating dlls (Add-ins) for a third party program that loads Native DLLs dynamically, is there a way, in a Mixed Mode DLL (C++/cli) to natively catch the fact that the .Net framework is not available. So that the Parent program that is dynamically trying to consume this DLL does not throw an error?
It might be possible to do something with a custom entry point in the dll, but I expect you are walking in 'undocumented' territory.
The only 'simple' way I can think to do this would be to create a native shim dll that performs the check and handles the condition in whatever way you see fit. If the framework is present it in turn loads the real plugin DLL and mirrors all calls through to it.
How easy this is will depend on the complexity of the plugin interface you are working with.