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.
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'm sorry in advance if this question is not well expressed, I am trying to achieve something quite new to me and I am a little lost.
I am trying to include a Canon SDK inside an Objective-C wrapper, I understand from this paragraph that I needed to download the 64bit SDK:
There are a few steps that need to be taken in order to use EOSFramework in a project. First, ensure that you have downloaded the latest Canon EDSDK 64bit. EOSFramework currently relies on ARC which is only supported in 64bit. Therefore you must use the 64bit version of EDSDK. Also ensure that you have compiled or downloaded the latest version of EOSFramework as a .framework file.
Incidentally, after following instructions, the errors that I'm getting while building the frameworks are related to 64bit. Please see picture attached:
Can someone point out a way for me to figure this out?
I'm not sure if this won't bring a problem in the long run, but I found an answer in this post: _int64 does not name a type
Following this:
It looks like you you are trying to use MSVC specific __int64 type with GCC. That does not work, use long long instead.
Can someone point out a way for me to figure this out?
You need to track down the declaration of EdsUInt64 in the SDK you have downloaded and figure out why it is not being seen by the compiler when compiling the source you've shown.
Try right-clicking on EdsUInt32 (which the compiler was happy with) and jumping to its definition. Now look around, are the 64-bit types defined in the same place? Are they inside #if constructs? If so why are the conditions not true? Etc. Do some detective work.
You can also use TextWrangler/BBEdit, or other good editor, to do quick multi-file searches over all the SDK source to find the definitions.
If you don't find the definitions then you've got the wrong version of one of the SDKs, go back to Canon and get the right one.
The solution is very unlikely to be you needing to define the type yourself. The ARC comments in particular indicate you do have Mac specific source code, Canon compile it on a Mac, so it's unlikely to be a MS or Gnu specific issue failing on a Mac etc.
Good Hunting!
HTH
Hi this may sound like a dumb question, but I am trying to use the NReco PDF library in my VB.NET Win Form application, and I am getting this error when I try to compile my code:
NReco.PdfGenerator.HtmlToPdfConverter' is not defined
I added the reference to the DLL and when I first wrote this code:
Dim converter As New NReco.PdfGenerator.HtmlToPdfConverter
It recognized the NReco namespace and everything seemed fine, but whenever I try to compile it acts like the DLL is missing. I know this library is written in C# but the site just said it was a .NET library, and I have used other libraries written in C# with no problem.
Any ideas on why this isn't working?
I never could figure out why NReco wasn't working, but I did find a pretty awesome alternative that works very well.
Nuget Package: https://www.nuget.org/packages/Pechkin/
Source Code: https://github.com/gmanny/Pechkin
This library uses WebKit Engine to convert HTML to PDF and it does a very nice job of rendering things correctly thanks to WebKit.
It is relatively easy to use and it is free to use under the creative commons license. I highly recommend this library for anybody wanting this functionality for free.
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.
How do you reference DLLs from Objective-C? I use GNUStep Make files on Windows.
RIch
Ooh... this takes me back. A bit of a guess from the most common problem I ever ran into.
If GNUStep's DLLs on Windows work like they did a decade ago, then you:
Link to the DLL like you would any other DLL. I don't remember the explicit syntax, but there should be about a zillion examples available
Make sure you have a static reference to a symbol in each DLL from the main program (or from some other DLL).
In particular, when compiling something that is pure Objective-C, it is quite easy to end up in a situation where the Windows link loader doesn't load a DLL because it doesn't see a hard reference to any symbol in that DLL. When I ran into this with WebObjects applications, I would typically export something like:
int businessLogicDLLVersion;
And then refer to that symbol quite specifically in my main program. That static reference was enough to cause the link loader to load the DLL and the runtime to hook up all the classes.