I have Objections-iOS as a 3rd party framework, recognised by XCode, but not by apportable.
In essence, #import <Objection-iOS/Objection.h> does not work so apportable chokes at this point.
I am aware of the header_path(s) property in the configuration, but try as I might, I still could not get apportable to load the headers from $project_root/Frameworks/Objection-iOS.framework
Have any of you had a similar problem?
You would need to build that framework as a sub-project to get it to work the headers from the framework need to be re-organized to be in a directory called Objection-iOS to reference the correct paths. Unfortunately the linker does not support framework inclusions yet so we cannot build real frameworks as of current to add the -framework parameter to the compilation steps. On iOS and MacOSX this basically adds the Objection-iOS.framework/Headers into the include paths but remaps that part to be named Objection-iOS.
tl;dr;
Create a directory called Objection-iOS, add a header_paths entry that points to the container of that directory and it should pick up on the headers
Related
I am trying to add some external DLLs to the Acumatica Customisation project but upon publishing it results in "System.BadImageFormatException: Format of the executable (.exe) or library (.dll) is invalid."
Error Image:
I already have added multiple DLLs to the Customisation. And was using the method specified here: Acumatica unable to publish the Customization Package to skip over the errors, but in this case it does not seem to be working.
The first step should be identifying which DLL is the culprit. I suggest you create an empty project and put the files in there one by one with the ignore rules. Maybe you missed to add ignore rule for one of the files.
This error happens because Acumatica attempts to parse the DLL as a .Net framework assembly. If you add non .Net assembly such as native x86/x64 compiled libraries you need to add the ignore rule so Acumatica doesn't attempt to parse it.
If the error is coming from a DLL you compiled, make sure it was compiled in Any CPU platform. This prevents any incompatibility related to 32 bit/64 bit mismatch.
I'm working on a simple plugin architecture for my app. A plugin is a shared object with a known "get interface" function. I access the .so via dlopen/dlsym etc. Fairly standard.
Some of my plugins have extra .so files that need to be loaded too. These files can be shipped with a plugin fine, but I need the app to know where/how to load them.
So my question is: how to I add a particular plugin's directory to the list of places to look for libraries? I can't set LD_LIBRARY_PATH before starting the app, as the plugin will be loaded some time later. Alternatively, do I need each plugin to explicitly provide the list of dependencies in some kind of manifest file, so that I may load them with dlopen() first? Thanks.
Edit: to clarify, the plugins' directories are not known prior to starting the app, so I cannot set the LD_LIBRARY_PATH at that time.
According to this linux evaluates LD_LIBRARY_PATH before starting the app, so it is unaware of any changes you make at runtime.
In one of my scripts it is required that I reference System.Drawing. However it seems every time I start up the project and enter Mono it's removed the reference and I need to re-add it.
All my other references stay where they should be, any particular reason this may be happening or how I would prevent it?
Unity regenerates the .csproj.sln files automatically whenever the filesystem changes which will overwrite any change you have made to your .csproj.sln.
Unity uses information from the Unity project and the filesystem to do this so you have to use a method Unity understands for your changes to be preserved. For example, preprocessor flags have to be defined through the Unity project and assemblies have to be added via the filesystem.
I believe if you drop your dlls into ./Assets/Dlls then they will be included in the project. However, I suspect System.Drawing will not be supported because its an incompatible drawing library.
What are the correct steps to creating a bindings project for a Framework versus a library? (Yes, they are close to the same thing, but NOT the same, the framework is a directory structure with header files, library and resources). These are what I've come up with, note that none of the Framework specific steps are documented as far as I can tell at the Xamarin web site (please prove me wrong).
Create the bindings project via MonoDevelop wizard.
Generate the ApiDefinition.cs and StructsAndEnums.cs files with btouch or by hand.
Copy the file from the root of the framework directory to lib.a (e.g., ArcGIS to libArcGIS.a) and add it to the project. It is important to note that the file without any file extension in the framework directory is in fact a library file.
?? Include framework resources ??
You'll notice that I get foggy at the third step. How to you add these resources to the bindings project? The large part of the bindings project links and runs fine, but I think it crashes at times because it is missing an expected resource.
You must (a) create a C# contract that describes the Objective-C contracts and how you want your projection into C# to look like, and (b) statically distribute the library with your project.
To kick the automatic population of the linkwith.cs you must rename the framework library (for example MyFramework) to use the library pattern (in this case, "libMyFramework.a")
Resources you have to select and flag as resources, they will be bundled directly into your app, and extracted when the library is consumed.
I use third party static library (provided as a .LIB file without source code) in my project. For linking purposes it is enough to add it via "Properties/Linker/Input->Additional Dependencies"
This library is not used in any other project in the solution.
I wonder if I should add it as an item to project file itself. The advantages that I see: it will be immediately obvious that this project uses it and one wouldn't have to add it to version control system manually (anything that is a part of the project/solution is added automatically if you use something like AnkSVN).
The project in VCS must be buildable. It is impossible without the lib. So you should add it.