I'm developing an AIR application that will be run on both OSX and Windows (it's part of an internal tool chain). Part of the functionality of the application requires shelling out to external processes, so I've created a native installer package to get access to NativeProcess. The app also needs to automatically update when a new version is available, so I've used the NativeApplicationUpdater library.
I'd like to set up automated builds of the app. Unfortunately, it looks like building a native installer for a particular OS requires you to build it on that OS, making automated builds of both OSX and Windows versions impossible (at least on the same build machine).
If I could set up automated builds of a .air file, and then use that to update the native install, that would fit my workflow perfectly. My question is: is that possible? If not, are there any alternatives when it comes to auto-building a native install app?
Yes, you can build a native installer from the .air file:
adt -package
-target EXE or DMG
NATIVE_SIGNING_OPTIONS (windows only and optional)
output
input_package
See http://help.adobe.com/en_US/air/build/WS901d38e593cd1bac1e63e3d128cdca935b-8000.html
Related
I just wanted to know how the worklight folder is compiled and copied inside the wlapp file. I am referring to the worklight folder which consists of the cordova plugins folder, worklight.js, cordova_plugins.js, etc.
These files are used during build-time by the Worklight Build Engine. They are located in the TMPDIR of your OS. Since you're using OS X you can open Terminal and run the command open $TMPDIR/wlBuildResources (> your-WL-version\jslibexpanded).
I am guessing you are asking this because you are thinking of altering these files pre-build time? You must not do that as it may generate a faulty application (it does not go only to the wlapp file but also to the generated native project of any mobile environment you may have added to your application).
These resources are also deleted and re-created on each launch of Eclipse (with Worklight Studio installed).
This will of course also void any support requests.
Since this is probably related to your other question about using the Ionic Keyboard Cordova plug-in, note that in the upcoming MobileFirst Platform Foundation 7.1 there is Cordova application support, enabling you to create either an iOS or Android application with MPF as a plug-in like any other, thus you can also leverage any Cordova plug-in that you would like. More on this, soon, once 7.1 is released.
I have some .NET code that I am looking into porting into being a Windows Store app.
This code does a few different things and one of the things it does has a dependency on being compiled as x86 instead of AnyCPU.
Is this going to be a problem? Can a Metro app be compiled as x86 and still be distributed on the Windows Store? Is being compiled as x86 going to stop it from being able to run in Windows RT? Would I have to come up with a version without this subset of functionality to run in Windows RT? If I can get the code into its own assembly can I just have the Windows RT version not use it? (so, the main executable is AnyCPU and this one assembly is x86).
Can a Metro app be compiled as x86 and still be distributed on the Windows Store?
Yes. However, it would only be installable for x86 installations.
Is being compiled as x86 going to stop it from being able to run in Windows RT?
Since Windows RT is designed to run only on ARM CPUs, compiling for x86 will stop it from being able to run on Windows RT.
Would I have to come up with a version without this subset of functionality to run in Windows RT? If I can get the code into its own assembly can I just have the Windows RT version not use it?
You could use conditional compilation symbols to include/exclude functionality as required in your code. https://stackoverflow.com/a/6587823/61385 shows an example of how to do this.
Just compile whatever libs you need and when you upload to app store just upload the one you want to. Check your apppackages folder and look for the .appxupload files.
I am currently developing a Windows Store App that will eventually be targeted at the ARM devices when they are available. For now, I have been developing and testing from Visual Studio on my desktop computer and everything works fine. However, when I try to create an app package that I can pass along to others within my company for testing purposes, the application will not run properly.
The solution includes two projects. The first is a C++ project that is set to build a dll file. The purpose for this is to expose the Direct2D and DirectWrite libraries that seem to be unaccessible to a C# project. The second project is the C# project that references this dll for drawing functions and includes a XAML interface and most of the program logic. All of this works flawlessly on my development machine from within Visual Studio (and also when installing the package).
When I send the package files to other individuals within the company, the installation appears to work fine by installing with the PowerShell script. The tile appears in the start screen and the program will launch for a few seconds. The C# and XAML interface appears, but the DirectX portion of the application is not visible and the entire application shuts down within a few seconds. This makes me believe that the dll may not be installing or referenced correctly upon installation. I have checked the package file, and the dll file is included in the package after the build process is complete.
I have packaged a few different test programs (MSDN Samples) that have all installed on their machines, but we get the same results that they will not run (again, all samples run fine on my development machine when building them). The only test project that worked properly was a simple C# project that did not use DirectX at all. Any of the DirectX samples that I tried have all failed (including the native C++ samples that do not use C# at all).
To be clear, the process I use for building is going to Project -> Store -> Create App Packages and choosing the No option for uploading to the Windows Store.
Does anyone have any ideas on what might be going wrong with the build or installation process?
Thanks in advance for any help!
Does it work with the Metro Sideloader? I am not sure if it just adds a UI to the Powershell script, but it works for my team and me for testing...
Good luck!
Are you side loading a Debug version of your DirectX app onto a machine that does not have the Windows SDK installed? Visual Studio's default DirectX projects and the samples on MSDN both request the D3D11_CREATE_DEVICE_DEBUG flag when creating the D3D Device. Device creation will fail if the Windows SDK is not installed on the machine running the code.
Here are a few different options that will allow you to unblock yourself. Any one of these should give you the desired result:
Create a Release package and deploy that instead of a Debug package.
or - Go to DirectXBase.cpp and remove the D3D11_CREATE_DEVICE_DEBUG flag from the code.
or - Install the Remote Debugging tools for Visual Studio on the target machines. This will install the necessary SDK components to allow creation of D3D Debug devices. The other cool thing about this option is that once you're set up you won't have to create packages manually and side load them anymore. Just tell Visual Studio the name of your ARM machine and press F5 to deploy it remotely. More information here: http://msdn.microsoft.com/en-us/library/vstudio/bt727f1t.aspx
How are you deploying the native DLL with your project? Are you using project-to-project references? Can you verify that your DLL is ending up in the final package, in the root of the package application directory?
I recommend using Sysinternals Procmon to watch your application load on the target machine. If it crashes or fails, you can look in the log history for which DLL it is trying to load and failing. Typically this will show up as a repeated series of DLL load probes (it will try and load the dll from the application directory, and then proceed to try a number of other paths).
I have a mono application developed with MonoDevelop as IDE. I'm working with windows 7.
I set a custom icon (embedded into the .exe).
When I run my application from inside MonoDevelop, all is fine.
But when I manually run "mono.exe ", my custom icon does not appears in the windows task bar. Instead, it appears a -it seems to me- predefined one.
How can I get my custom icon visible also when running my application from the command line? Starting always from inside MonoDevelop is not an option.
Thanks!
When you run your app from MonoDevelop, it runs using the .NET runtime. So Windows is able to pick up the app icon. When you run it using Mono, the executable app (from Windows' point of view) is Mono.exe. So you get Mono's icon.
I recommend that on Windows you run your app on .NET - even MonoDevelop runs on .NET on Windows. The Mono package for Windows is primarily intended for development (checking your app will run with Mono) and for specialized embedding purposes.
I am trying to find out how (if possible) can I create an MSI for my Desktop project in Titanium! Do you know if Adobe AIR has a similar option and/or is it better implemented? What would you recommend me to use?
You can create MSI and DMG both in Titanium for your desktop project. In recent version they are providing builds from their server. So once you start packaging your desktop app in titanium they will upload all resources to their server and their server will create MSI and/or DMG for you and once packaging process is over they will return you the link to download your packaged application.
Hope this will help you.