I'm working on a project that involves receiving a byte[] from a web page in a .net program, then loading that byte[] as a dll. However, the dll is not a .net assembly, it is a native assembly. I can't use loadlibrary because I would have to write to disk, and I want to keep the native dll in memory. I can't use c++ /cli, because this is all being done in mono, and mono doesn't support c++ /cli. Is there a library or project somewhere that allows me to load a native dll from a byte[], in c#? I've seen this tutorial: https://www.joachim-bauch.de/tutorials/loading-a-dll-from-memory/, but this is c++.
This will help you, or lead you somewhere.
This is basically a wrapper for the project you have sent, I will keep the repo up for anyone who wishes to look at It. Untested on 32bit OS, so It might do an overhead.
https://github.com/dretax/DynamicDllLoader
It basically does what you want. Expects a native dll's byte array, and loads it into the current process.
Just use Assembly.Load (if that's .Net assembly) https://msdn.microsoft.com/en-us/library/h538bck7(v=vs.110).aspx.
Otherwise, use PInvoke with unmanaged DLL's.
I will give you a short rundown on where problems with that lie:
You are receiving a DLL from the internet. Every adminsitrator will wonder if he just got insane or that really stands in the "how it works" description. We had enough problems with remote code excecution and code injection on data arrays in the last century to know how this will fail without needing to try.
Anything in the design of the managed .NET Runtime is there so you can not do shit like that. You propably have to go to unamanged code. And at that point, you might as well write in native C++.
It might even trip over some run off the mill virus scanners heuristics just for trying to pull this. Because that is on the short list of things a visitor to my Operating System should never try to pull.
You really, really should just burry that idea and live without it. If you got a boss that wants this, say him it is between impossible and figuratively insane. Possibly even literally insane. Even if you could make it, no admin of sound mind would install it.
If that has not detered you: It might be best to move this into a helper process of some sort, then transmit data/results via Interprocess Communication. When calling old, umanaged, never-migrated-to-64-bit DLL's from a .NET Application, missmatching binarity is often a problem. A helper process (that always runs at x32 to match the DLL) can help with that. And once you got a helper process, it can be programming in something like Native C++ where these kinds of shenanigans are easier and you even go a example.
Related
I have C++ Qt application together with a lot of .net C# assemblies, that I would need to use in the C++. Before doing any research I was expecting there is existing solution to generate C++/CLI wrapper DLL for usage in pure C++ app, but to my surprise I wasn't able to find anything except SharpCpp, but that's just experiment.
As the amount of classes that need to be exposed might be pretty extensive, I was looking for as much as automatic solution possible ( like what I'm used to when wrapping C++ for Python using shiboken)
As far as I can tell my possibilities are (as just compiling the app with /clr is not an option):
Manually write C++/CLI bridge DLLs, but this could take a lot of time.
use COM, but that would also mean a need to implement the COM exposure to all C# assemblies also. Or is there any automated solution?
use CLR Hosting. Not an option without automatic generation of the wrapper also.
try using something like Alter-Native or cs2cpp, but I don't know how much production ready this is.
So I was wondering, if someone was facing similar problem, and what turned out to be the best, and most maintainable solution.
I don't know why but today myOpenID doesn't seem to work. Anyway ... I have this problem: I have a unmanaged C++ library (DLL) which I have to embed in an existing C# project. Now ... I have created a mini-wrapper (DLL) in managed C++ which calls the library so that I can load it from the C# code and, when I try it from a command-line C# project, it perfectly works, right results, right behavior ecc.
Now, when I load it in the real project, it starts giving me strange System.AccessViolationException coming from the mini-wrapper DLL. I am not experienced in C#, nor in general manged/unmanaged C++ development under Windows, and I just can't understand why should this work from a C# project, and not work from another.
More information: the original library uses OGRE3D rendering engine to do calculations, and the project in which I have to use this library uses OGRE under the hood, could this cause problems?
Any suggestions?
Here are some ideas for you to try sir...
It's hard to know whats going on exactly but the first thing I would try to do is remove this managed c++ dll from the mix. It might be confusing things. Somewhere here this feels like data is not being marshalled correctly between the managed and unmanaged world. Also, just because it doesn't crash from the console, doesn't necesarilly mean the code is working correctly, it could still be breaking, just not in a way thats triggering an access violation. The first thing I would look at is using p/invoke to call your unmanaged dll directly, if it breaks, you should know pretty quickly:
Calling Win32 DLLs in C# with P/Invoke
It could be that somewhere in the mix, this pointer is being moved to a different address space where that pointer makes no sense. Are there any process boundaries here?
I'm currently in a project that need to work both on Mac and Windows. We are using standard portable C++ for all the application logic. However, since we want the app to feel totally native on both platform, the GUI will be written with C#/WPF for Windows and Objective-C/Cocoa for Mac.
However, for the windows part, I am wondering what is the best way to use the C++ code with C#. C# is managed, and I know that we can use managed C++ too. However I worry that using C++ inside the CLR may introduce unexpected bugs, or that we will need to put an awful lot of #ifdef WIN32 everywhere in the C++ code to make it work both with the managed CLR and the unmanaged environnement of Mac OS X (note that we sure expect to put some ifdef, but we'd like to keep it under control if possible). So basically, what is the best way to use the C++ code with the C# code? Right now, I'm thinking of three solutions
1- Compile the C++ as C++/CLI and directly use the classes and function from C#.
2- Compile and wrap the C++ in an unmanaged win32 dll and call it from C# using DllImport
3- Wrap the C++ in a COM wrapper and use the .NET COM Interop to link it with C#
Which one is the best way? Or, if there is a better solution, what is it?
C++/CLI has several restrictions over standard C++ that don't always make it easy to recompile standard C++ as C++/CLI. Keep in mind that you'll have to distinguish 'managed' and 'unmanaged' pointers, for starters. As these are using different symbols, you've got your first set of #ifdefs right there. And then you get to ref and value classes and all that sort of fun.
You can however use C++/CLI to bridge the gap between native code and the .NET world. The last time I did something along the lines of what you're planning to do, I used C++/CLI to write the bridging layer that did the necessary translation and conversion work between .NET types and classes and the native world. The C++/CLI layer can obviously be used from any .NET language.
You can't always use (2) - this depends very much on the data types you're trying to exchange between the two worlds. The .NET marshalling code is pretty good at dealing with C PODs but anything more complicated and you've got a problem.
(3) is overkill IMHO and introduces another point of failure, plus you're then doing .NET <-> COM <-> native instead of the simpler .NET <-> native if you created your own bridging code. Not to mention that you add complication to your code that won't benefit the other OS you're targeting, namely OS X.
Our development team has been using C++/CLI compiled code with ASP.NET and WPF front ends for while now.
The first major issue we had was build time. The code base would be 150k lines (40+ projects) and took forever to link (due to linker issues we could not build the individual projects as DLL's). We were only able to resolve this issue by wrapping the code with managed C++ classes and building our projects as assemblies.
The second major issue was performance. We originally compiled with /clr (before pure option existed) and this resulted in double thunking of most of our calls that occurred in the managed C++ layer. We fixed this by switching to /clr:pure. By doing so we ran into an
issue where our assemblies resulted in having too many 'global' methods in the assemblies so they would not load. We had to split our assemblies further to solve this issue.
Best and easier way is to do it with .NET <-> COM because COM has much stronger bridge compared to native dll access inside .NET because it may lead to lots of memory issues and lots of troubleshooting time. Its easier to test COM inside any MFC project and get the trace information for debugging and when the component is ready it can be easily used inside .NET.
CLI will not let you use all features and unfortunately its fairly new so less documentation is available and you will not get good support for your questions.
Win32 dll and DLLImport has problems mainly to troubleshoot, because the exception thrown inside Win32 dll will not travel further along the stack instead it will simply crash and you will not get the reason. Where else in COM you can catch exception internally and the COMException thrown inside .NET will not crash your entire application.
COM will be little slower in performance, but it will be more organized and good design pattern to develop.
Preliminary: The caller is a native EXE that exposes a type of "plugin" architecture. It is designed to load a DLL (by name, specified as a command line arg). That DLL must be native, and export a specific function signature. The EXE is C++, which isn't too important since the EXE is a black box (cannot be modified/recompiled). The native DLL can meet the application needs by completely implementing the solution natively, in said DLL. However, a requirement is to allow the real work (thus turning the native DLL into a thin wrapper/gateway) to be coded in C#. This leads me to 3 options (if there are more, please share):
Native DLL loads a C++/Cli DLL that internally makes use of a C# class library
Native DLL interacts with a C# COM object via CCW
Native DLL hosts CLR and makes calls to C# assembly
One more requirement is that not only does the native DLL need a way to send messages (call functions) on the C#, but the C# needs to be able to fire events/callback to the native DLL when certain extraordinary things occur (as opposed to shutting down and returning). Now this last thing I'm not sure how to handle in the 3rd option, but that is another question altogether.
So to the point: performance. Any info regarding those approaches (assuming they all meet the requirements)? From my investigation, my understanding is 2 would have more overhead than 1, but I'm not 100% confident, which is why I'm here. As for 3, I just don't have any info yet.
So if anyone has dealt with these (or knows of another elegant option), please chime in.
Thanks!
I've done option 1 before, with reasonable success. I don't remember any significant performance implications, though my application wasn't terribly performance-intensive. It seems to me that if performance problems occur, a likely culprit might be the frequent, small native-to-managed transitions. Would it be possible to batch those at the C++/CLI layer?
I learned windows programming using Visual C++, and the Win32 API. Nowadays, it seems most apps are being developed in .NET using C#. I understand that most of the time there isn't much performance difference between native code and managed code. So I'm wondering, if I were to start writing a new desktop app today, is there any reason (other than the fact that I'm more familiar with C++), that I might want to write it in non-managed C++ instead of .NET? Are there still some advantages to using C++ and native code? Or has that method been more-or-less replaced with .NET on the Windows platform?
Of course I know that people who are writing low-level device drivers and similar programs wouldn't do it in .NET. I'm asking with reference to typical client-facing apps that don't make direct hardware calls.
IMO the most important one for small downloadable applications is that native code does not need the .NET runtime. While broadband becomes more and more common not nearly everybody has it yet.
Some people may be disappointed to see that your 2 MB application actually requires another 20MB of framework download and a bothersome installation process to run. If they are not sure whether or not they really need your application in the first place, they might just delete it before even giving it a try and turn to a competing product.
Performance (certain situations, such as graphics)
Memory footprint (as Mancuso said)
Use of existing libraries
No need for a runtime
Finer control
To list a few.
However, you may also want to look at the question from the opposite angle to fairly evaluate which language to use.
Additionally, you could use C++/CLI to incorporate both native and .net code.
If your application needs to be able to run without an installation (i.e. if you can't or shouldn't do something like install the .NET framework), you can't count on .NET being on a windows machine (pre-Vista). Lots of utility applications can fall in this category.
I would recommend to write every desktop application in managed code. .NET/C# is a great platform to do so.
My reasons:
Performance penalty is negligible. Google for benchmarks if you don't take my word. What matters more is the code itself. You can write O(n^m) algorithms in C++ or .NET/C#. JIT engines are very mature these days.
Unmanaged C++ has major drawbacks when it comes to unit testing, mocking and refactoring. It's very cumbersome and inflexible. Reflection allows managed code to make such things very convenient.
Deployment is a small issue. However, creating a setup which checks for the necessary .NET preconditions and installs them automatically is a no-brainer.
Compilation is quicker, no linker! It even happens in the background when you edit the code.
.NET library support is way better and cleaner than STL, MFC and boost.
No header files and macros. They are just error prone.
Security! Good bye buffer overflows, bad pointers, uninitialized variables...
Exceptions. Clear exception hierarchy in .NET. C++ exceptions are messed up.
Memory footprint. But unless you're developing for a severely handicapped machine memory-wise, it really shouldn't be an issue for most applications.
If you can afford the dependency on the stack, go for .NET
Modern, elegant, powerful and as a result much quicker to develop for.
But realize that you chain your app to it - to the language and the framework, if you forsee a future where you may want to escape this, then better think twice.
Win32 is old and clunky, but it works on virtually any Windows version without extra dependencies, and your code can be in plain, portable, C/C++.
+1 for not having to require a .NET package/install on the target machine(s). This is still a big issue.
When all machines have mono or NET it won't be such a big deal.
Two things that I can think of.
Protection of intellectual property. It's infinitely harder for someone to reverse engineer an Unmanaged C++ app. Managed .Net or Java apps can be easily de-compiled this is not the case with Unmanaged C++.
Speed. C++ is closer to hardware and has a smaller memory footprint as the other comment mentioned. This is why most video games continue to be written in C++ and inline assembly.
.Net programs also have a support lifetime, where native do not really. Native will run for many years across different OS's without requiring updates.
.Net programs can be hosed by bad .Net configuration, native just keeps on running and is hardly effected by OS updates.
.Net programs startup slow and feel sluggish, native starts quick and runs quick.
.Net has to be coded for lowest common denominator (most distributed framework version), Native compiles all code into application - so use what you want.
Use Delphi for Native, not C++. .Net is partially based on Delphi RAD and Java backend.