Packaging brew'd software in my App - objective-c

I would like to include some open-source software with an OSX app. This software (e.g. Tesseract) lists that the way to install it on OSX is via Homebrew. But I need to distribute it to my users and can't have them install it separately, but would need it to be bundled in the app's bundle.
How do I do that?

Related

Shared resources in packages made by Electron

I need to distribute a webapp in an offline version on an USB. Electron seems like a great way to make the webapp feel native and work well on all platforms. There is (potentially) just one problem: The offline version requires several huge media files and therefore there is not enough space for each package to have its own folder with the media files. This can be solved by letting the packages share a common directory on the USB. Can you tell me if this is possible with Electron. And if so, how?
(Note that each package must be available on the USB.)

build automation windows store apps

I'm want to create automated build environment for windows store apps (phone/tablet) & after creating build provide way(link to download) to deploy it on devices. Right now packages for testing needs to manually installed on device and then hand over for QA or upload on Windows beta store for phone apps.
Would like to know what possible tools can be used to serve this purpose. Please guide.
Thanks

Is Android Device defaultly support mono

Is Android Device defaultly support mono ? or
We need to install any thing on android device for supporting Mono(which the application developed by Xamarin).
Xamarin's mobile/Mac solutions use a different approach compared to Microsoft .NET. The rules are,
You don't need to install a .NET/Mono runtime on Mac or iOS or Android devices before installing an app.
When you build the deployment packages of your app (Mac/iOS/Android), Mono compiler tool chain automatically merges your binaries with Mono binaries so the final packages are self contained (they contain every bits needed without dependencies on external components). This is required by Mac App Store, iOS App Store, and various Android app stores.
Note that because that Mono bits are embedded in each packages built, those packages are slightly larger than the ones created using Objective C or Java.
I don't think it supports mono by default.
http://mono-project.com/Start

Preventing uninstallation of DIFxApp-installed drivers

I’m creating an installer for a software application that interfaces with a hardware device. The hardware device uses an FTDI USB serial interface. I need to install the FTDI USB drivers (if the user doesn’t already have them) along with the software, and I’m using WiX and the DIFxApp extension to accomplish this.
So far, so good. That all works fine. I have separate MSI packages for my software and the 32-bit and 64-bit flavors of the drivers, and I’m using Burn to bundle them all up into a single installer. The driver MSI packages deploy the driver files to a subdirectory of my application installation folder, and then DIFxApp installs the drivers to the appropriate system locations from there. (Which seems silly – they’re only used during install; why keep them hanging around after that? A copy is kept in the system driver store, after all. It would be preferable to extract them to a temporary folder, install the drivers, and then clean them up. But evidently, that’s the way DIFxApp works.)
But the FTDI chipset is used by a lot of different devices, and it is likely that a user will own other devices that also require the FTDI drivers. In testing, I have found that DIFxApp uninstalls the drivers when the software is uninstalled. This is undesirable, because it will break any other FTDI-based devices the user owns, requiring the user to reinstall the drivers to get those devices working again.
I would like DIFxApp to leave the drivers installed on the user’s system when my software is uninstalled so that removal of my software does not affect the user's other devices.
I could do this by setting the Permanent attribute on the MsiPackage or Component that installs the drivers, but that will prevent the driver files that were deployed to a subdirectory of my application installation folder from being cleaned up. I want those removed along with my application; I just don’t want the driver removed from the system driver store, etc.
It also looks like I could accomplish what I want by installing the drivers with a DPInst custom action. And it looks like the DPInst approach would support installing the drivers from a temporary folder and not require the driver files to hang around in my application folder for eternity. This would seem to be the pragmatic solution, but evidently DPInst is discouraged in favor of DIFxApp in MSI-based installers.
What is the “right” way to handle this?
I have dealt a little different with the same issue.
I consider the drivers and the application as separate pieces of software so they should not share any directories or files.
I install the drivers with difxapp and also copy them to program files/common files as they could be shared/common.
The application is installed to it's own directory in program files.
Then you can mark the driver msi as permanent in the bundle and keep the drivers when the application is uninstalled.

adobe air: how to embed air runtime or simply distribute air applications?

My question is quite simple: I want to create an adobe AIR application for desktop (windows).
What if an user does not have AIR runtime installed ? Does newest version of AIR come now with EMBEDDED AIR runtime, so it works even for people that do not have AIR runtime installed ?
if not, what would be the simplest way to distribut my AIR application and make sure people that do not have air runtime will be able to run it ?
regards
With the Release of the AIR 3.0 SDK you are now able to distribute Air with your application using the Captive Run Time
This will allow a user to install and run your Air application without having the runtime already installed.
There are some downsides however. For mobile applications (and desktop alike) including the captive runtime can increase the package size by around 10MB. Also, for desktop applications, you will have to package the application natively (ie .exe or .dmg) but if the user doesn't have the runtime installed in the first place they can't run the .air file anyway.
I've had to do this just recently and wanted to know exactly what you just asked.
http://www.adobe.com/devnet/air/articles/badge_for_air.html
That is what you need to know and will answer your question.
All you need to do then is deploy your .air file onto a server somewhere and point the javascript code to it.
HTH
Anthoni