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.
Related
I need to read\write tga files from vb,
I found TargaImage.dll, nice lib but it allows only read tga.
I found FreeImage, tryed to import it in vb, but it says:
FreeImage.dll could not be added. Please make sure that the file is accessible, and that it is a valid assembly or COM component.
I think I have to use , but absolutly dont know anything.
help plz:)
From looking at the way the distribution works, you have two options:
First, you could call the functions in the DLL directly using <DllImport> attributes. This is going to require a lot of learning of how to make calls to unmanaged DLLs, passing the right values, etc. Which is why I suggest the second option.
The second option is, you can use the .NET Wrapper project that is included in the distribution. If you're using a version of Visual Studio that supports multiple programming languages, just add the wrapper project to your solution and reference the wrapper project from the project that needs to use it.
If you're using Visual Studio Express, you won't be able to add a C# project to a VB solution. I'd suggest downloading C# Express, compiling the wrapper project, and then adding the compiled DLL to your VB.Net project.
What's the best way to use ImageMagick in MonoTouch?
Adding the ImageMagickNET lib seems to produce errors during runtime, such as:
Method
'Module:CrtImplementationDetails.DoDllLanguageSupportValidation
()' in assembly
'/ImageMagickNET/bin/ReleaseQ8/ImageMagickNET.dll'
contains native code that cannot be
executed by Mono on this platform. The
assembly was probably created using
C++/CLI.
There are iPhone-specific binaries available, I suppose I have to link the whole library as described here:
http://monotouch.net/Documentation/Binding_New_Objective-C_Types
?
Thank you for your help :)
First, why this does not work.
Second, what you can do about it.
Why it does not work: The library that you are using is compiled with C++/CLI compiler against the Microsoft libraries.
All managed code that you use in MonoTouch must be compiled using MonoTouch's assemblies and tools, so the above wont work for two reasons: (a) Mono lacks a C++/CLI compiler and (b) even if that existed, you would have to reference the Mono asseblies
What can you do about it: You can build ImageMagic with Apple's C compiler, and then link the resulting code into your application:
http://monotouch.net/Documentation/Linking_Native_Libraries
Then for each ImageMagick method that you want to access, you need to wrap it using P/Invoke, a guide is available here:
http://www.mono-project.com/Interop_with_Native_Libraries
that error answers your question for you :
in assembly '/ImageMagickNET/bin/ReleaseQ8/ImageMagickNET.dll' contains native code that
cannot be executed by Mono on this
platform.
A quick google tells me on the imagemagick codeplex page
that you're probably using what is called a 'wrapper'.
this means that the imagemagick code itself is still non-.NET imagemagick, which will never run on your iPhone.
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.
I've been working non-stop for the last three days on a completely managed interface to Erlang. At this point, I've decided that there simply must be an easier way. I've got a little over 3000 lines and it's not even in a compilable state yet. To be honest, I'm getting lost in my own code.
So, I then remembered that Erlang has a C library called erl_interface. Unfortunately, it only comes as a .LIB file, which isn't usable via P/Invoke. I'm now investigating ways to expose the static library through a DLL.
I'd like to stay away from Visual C++, mostly because I'm not a C/C++ programmer by nature and I find it really difficult to configure. TinyC is my compiler of choice when working with anything in C.
How can I go about this?
I know I can link erl_interface to a DLL, but how can I expose the functions? Do I have to essentially wrap each and every one of them in my own exports? That probably won't be a problem, since I could write a script to generate the code from the header file. But is there an easier way that I just don't know about?
Also, please don't recommend OTP.NET. It's a nice library, but I'm looking to use this is a large project, so I'd like to keep it in-house.
So, your problem is one of turning a static lib into a dynamic one.
The least-effort solution would be to write a thin shim file in 'C', that just delegates to the files in the .lib e.g.
ReturnType my_method1(args...) {
return real_method1(args...);
}
...
and build a DLL from that and the static lib.
Afterthought -- There is another approach you could take -- which is build the .lib into a C++/CLI assembly and do the transition/wrapping in that. It's what C++/CLi is there for, after all.
If you want some help with interfacing to Erlang with C, have a look at "EPAPI" (Erlang Port API) link text. You can of course browse the source code since it is hosted on Google Code. A DEBIAN repository is also available.
I have some C# source code that I got off the Internet and I want it in VB.NET. How would you convert it because I don't know C#.
I found multiple translators after performing a simple search, but this one looks kind of cool. No installation necessary!... though I have never used it.
Another way is compiling it to, dragging the assembly to Reflector and then decompiling it to VB.NET
If I recall correctly, you can have multiple source languages in the same project. They just have to be in different files. You should be able to call the c# class from a vb.net class without any major problems. This may not be the prettiest option, but it might work for your situation.
You can have a VB project in the same solution as a C# project, and use classes from either from the other, but you can't have both VB and C# source files compiled in the same project.