I'm attempting to use gRPC in my Xamarin.iOS project in order to use the Embedded Assistant API. I have two issues:
1) I can't create a Channel from an access token (https://github.com/grpc/grpc/issues/18178)
2) I need the native ext library to support armv7
I can use the workaround for (1) described in the link for now, and for (2) I can add armv7 to build_native_ext_for_ios.sh and rebuild fine.
The problem is, I'm not sure how to either create the nuget again or otherwise reference the newly updated libraries.
I tried running through some of the python scripts to generate artifacts, but continue to run into errors in task_runner.py (can't use + for concatenating dicts, can't compare NoneType and str, etc).
Related
ALL,
Does anyone succeeds building a client to libmysqlclient on Windows?
Following this instructions I can build the library itself
But then trying to follow mySQL documentaton which reads
To specify header and library file locations, use the facilities provided by your development environment.
With the old mySQL-Connector-C I was able to download just the code for the connector build it and then it had only 1 mysql.h
With the new library (8.0) I have t get the whole package, and there fore it will have multiple copies of mysql.h (yes, I did check by dong search of the file from Windows Explorer and Terminal/Bash).
In terms of library - it is easy as it will be hopefully just one and I can sue -L option for the linker.
But how do I get the proper include folder?
TIA!!
BTW, the tag here needs t be changed - it is not called connector-c anymore
I see that Docker is intended to deploy applications, but what about libraries? For instance I have a library called RAILWAY that is a set of headers, binary code libraries, and command line tools.
I was thinking the output of the railway CI/CD pipeline can be a docker image that is pushed to a registry. Any application that wants to use railway, must be built using docker. And it will just put FROM railway:latest and COPY --from=railway ... in its Dockerfile. The application can copy whatever it need from the library image into its own image.
Is this a normal use-case?
I could use a Debian package for railway, but Azure Artifacts do not support Debian packages (only nuget and npm). And docker is just so damn easy!
Most languages have their own systems for distributing and managing dependencies (like NuGet which you mentioned) which you should use instead.
The problem with your suggestion is that it's not as simple as "applications use libraries", it's rather "applications use libraries which use libraries which use libraries which use...".
E.g. if your app wants to use libraries A and B, but library A also uses library B itself, how do you handle that in your setup? Is there a binary for B in As docker image that gets copied over? Does it overwrite the binary for B that you copied earlier? What if they're different versions with different methods in them?
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 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
I am experimenting with ServiceStack's JSON engine. I grabbed the MonoTouch binary build, v2.20. Works fine from simulator, but from the iOS device (iPad2, iOS5) I get an exception thrown by the type initializer for JsonWriter (and not much other than that). I am using MonoTouch 5, MonoDevelop 2.8.1, and targeting iOS 5. I have disabled library linking because I am getting an error when enabled.
I created a sample and uploaded to https://github.com/t9mike/ServiceStack-JSON1.
I'm trying to determine whether the issue is my compilation options, Service Stack, or MonoTouch. Thanks in advance.
A quick partial answer that might help:
I have disabled library linking because I am getting an error when enabled.
The current (5.0) managed linker can eliminate some unused (from a static analysis point of view) code from your application. This generally occurs when using Link all option, i.e. where user code gets processed by the linker.
One alternative is using the Link SDK assemblies only that won't touch the user code (only the code shipped with MonoTouch itself will be processed by the linker).
Another alternative is adding [Preserve] attributes on your code to ensure the serializer requirements are still met after the linker has processed your code. More information about the linker and [Preserve] attributes can be found here.
The next (5.2) release of MonoTouch will include a bit more sophisticated step in the linker to ensure the basic XML serialization and DataContract requirements are not broken. Not sure if this will solve this specific case (ServiceStack JSON) but I'll have a look into it.
As for the rest of your question I'll try to build this myself and duplicate your issue.
I ended up grabbing the ServiceStack.Text sources from GitHub, version 3.0.3. I created a new MonoTouch library project. I had to tweak ServiceStack.Text/JsConfig.cs slightly to conditionalize away the System.Drawing.Color bits. I'll send a patch and MT csproj to the authors.
After using this new assembly, my sample MT app ran fine on the device. I have updated my sample at https://github.com/t9mike/ServiceStack-JSON1 with the new ServiceStack.Text dll.