Does anybody know how to build an AIR application made with an earlier version of the SDK (say 3.8, or 3.9) with a newer version of the AIR SDK (4.0, for instance) without altering the namespace version in the application descriptor xml file?
Adobe claims in the release notes for AIR SDK 4.0 (beta) (pdf):
If your application
does not require the new AIR 4.0 API's and behavior, you are not required to update the namespace. However, we recommend all users start
using the AIR 4.0 namespace even if you are not yet taking advantage of the new
capabilities.
and I've seen that in earlier release notes too but I've always had to update the namespace anyway, to prevent compiler error messages like this one:
Namespace 3.9 in the application descriptor file should be equal or higher than the minimum version 4.0 required by AIR SDK .
Can it be fixed by a compiler argument, or something else?
Related
I built an AIR native extension with following setup:
Visual studio 2005 for building my dll
Flash CS6 IDE with AIR SDK 3.2 to create SWC from my AS3 source
The namespace version of my ANE is 33.1
ADT (AIR SDK 33.1)
I tested the ANE with FlashDevelop 5.3.3.1 and the ANE works as expected on a machine that I use for development. However, when I test the same ANE in FlashDevelop on a different machine, the AIR can't find a necessary method in the native side implementation (Error code #3500). I am using the same version of FlashDevelop with same AIR SDK (33.1) in both machines.
It seems that for some reason AIR could not load the dll in second machine (but does so in my development machine), and I am not sure why. Any help would be highly appreciated.
Thank you.
You are probably missing some of the dependency dlls, most likely part of the vc++ redistributable package or potentially .net if you are using any of that functionality.
Try to install the VC++ redist on your test machine:
https://support.microsoft.com/en-us/topic/the-latest-supported-visual-c-downloads-2647da03-1eea-4433-9aff-95f26a218cc0
I've been tasked with porting a MacOS project to Windows 10.
It consists of modified Cocos2dx library which is built as a part of the the project. The library contains several objective-c++ files, so I'm forced to use LLVM.
However, LLVM doesn't come with standard c++ library which Cocos2dx uses. I've tried pointing to MinGW include directory, I've tried installing Visual Studio and pointing to it's STL include folder, but there was always something missing.
How do I properly include STL in my project? Where do I get it?
I ended up installing Visual Studio with Win10 SDK. I then used win32-clang-msvc mkspec. The STL was included with Win10 SDK.
I am making a Windows Phone 8 application, however because I would like at some point to also publish this application for Windows 8.1 store I made the effort to factor out the application logic into a portable class library. All good so far.
Now being a good boy I want to use an IoC container, unity by preference (since I am familiar with it in desktop and Win Phone 8 only apps)
So here's my problem; the NuGet Unity package will not install into my portable application with this result:
Installing 'Unity 3.0.1304.1'.
Successfully installed 'Unity 3.0.1304.1'.
Adding 'Unity 3.0.1304.1' to Logic.
Uninstalling 'Unity 3.0.1304.1'.
Successfully uninstalled 'Unity 3.0.1304.1'.
Install failed. Rolling back...
Could not install package 'Unity 3.0.1304.1'. You are trying to install this package into a
project that targets 'portable-net45+wp80+win', but the package does not contain any assembly
references or content files that are compatible with that framework. For more information,
contact the package author.
So is there a unity that works with a PCL? or is this just a shortcoming of the NuGet package?
I failed to find any useful documentation on the P&P website to indicate what platforms it is compatible with, but I know it does support WP8 at the least since the NuGet package is quite happy with libraries targeting just that.
Any guidance from the community would be very welcome here I don't want to abandon using a PCL for my app logic if I can avoid it, but if it comes down to a toss up between that and NuGet for package management I will in order to keep the NuGet goodness.
Could this be related to NuGet and Portable Class Libraries - Package doesn't target any framework? that seems more related to making your own NuGet packages for use in your own PCLs.
Unity 3.0.1304.1 does not contain any PCL assemblies so you will not be able to install it into a PCL project using NuGet.
The Unity NuGet package contains assemblies that target the following frameworks:
.NETFramework 4.5
.NETCore 4.5 (Windows Store/WinRT)
Windows Phone 8
You can see these target frameworks if you open the NuGet package into NuGet Package Explorer or download the NuGet package and open it using a program that supports zip files such as 7zip or Windows built-in zip file support.
So your possible options are:
Just use Unity in your main Windows Phone 8 application.
Write your own IOC container.
Use an IOC container that supports PCL projects such as Portable.CommonServiceLocator.
Compile your own PCL version of Unity.
Use a later version of Unity 3.5 since this includes a PCL assembly targeting portable-net45+wp80+win8+MonoAndroid10+MonoTouch10
Updated: 2014-05-11
Unity 3.5 now includes a PCL assembly that targets portable-net45+wp80+win8+MonoAndroid10+MonoTouch10 which will install into a project that targets portable-net45+wp80+win.
There is no Unity for PCL, but you can use Ninject for example.
I create a simple Java Map Scene in JavaFX. I put jfxrt.jar into my lib folder in project, but I also need native libraries to use some components: for example glass.dll on Windows and libglass.dylib on MacOsX. I have got few queston:
Where I should add these libliaries? To /rt/?
It is Swing application, and client start it by using Java WebStart. How can I add dependencies to these native libs?
What about x32 / x64 Windows versions? The jfxrt.jar is different for 32bit and 64bit system.
Where I should add these libliaries? To /rt/?
You could place the libraries in ../bin relative to where you have placed jfxrt.jar. Haven't tried it, but I think it will work as that is the directory structure used by the JavaFX distributions.
Embedding the native libs in a Swing app delivered via a webstart package is not a documented deployment option. Instead of doing that, I'd advise checking for JavaFX presence in your Swing app and, if JavaFX is not there launching a browser pointing to the JavaFX runtime download and installation page - the instructions for which are here. For example:
try {
new javafx.util.Pair("a","b"));
} catch (ClassNotFoundException e) {
java.awt.Desktop.getDesktop().browse(new URI("http://www.java.com/en/javafx/"));
}
It is Swing application, and client start it by using Java WebStart. How can I add dependencies to these native libs?
If you app is still in development, and can be targeted for the JavaFX 2.2 release in a couple of months, then you could set the minimum version required for the app to JDK7u6 - which will include JavaFX 2.2 runtime libs - then you wouldn't have to worry about their distribution and the deployment scenarios are much, much simpler.
Not sure if JavaFX 2.1 embedded in Swing deployed via WebStart is supported (or would even work) outside of Windows. You may want to wait for 2.2 for Mac and Linux webstart support for JavaFX applications.
What about x32 / x64 Windows versions? The jfxrt.jar is different for 32bit and 64bit system.
If you app is launched from a browser, then whatever bits the browser has is the bits that are required for JavaFX and Java. Most browsers today (at least under windows) are 32 bits, even if the user has a 64bit OS - so that is something to watch out for. As you are using WebStart, it may not have the browser bit match dependence (in which case you should at least match the bit versions of JavaFX and Java).
I have overlaid Air 3.0 over the flex sdk. I have targeted swf version 13 and included 3.0 in the header of my xml file, is there anything else i need to do to get my app published with air 3.0.
Also is there a way to check what version of air the app has been published with once it has been published?
I am using flash builder 4.5 and osx.
You can get the AIR version at runtime using NativeApplication.nativeApplication.runtimeVersion
Edit:
Also remember that there are different SDKs for Windows and for OSX. The Windows SDK does not work on OSX and vice-versa. Attempting to do so results in a runtime error.
OS X doesn't really matter.
Your application descriptor has changed in format since AIR2.0 The easiest way to check this is create a new AIR 3 project and check the app descriptor xml for that application, and compare it to yours. You will easily find out the differences.
The AIR runtime version (as lukevanin said) can be read from
NativeApplication.nativeApplication.runtimeVersion
Then you can publish in the same way as before (export release build -> select certificates, etc)