How do I get mdtool to build an iOS archive that is as small as the Xamarin Studio's menu option (Build > Archive)?
I've got a project build archives from script that are coming out much larger than what Xamarin Studio is producing manually from the menu command.
Steps
For Xamarin Studio, I just set it to AppStore|iPhone and hit the Build > Archive menu item.
For command-line, here's the command line call the RAKE script is making to mdtool:
.../mdtool -v archive \"--configuration:AppStore|iPhone\" -p:SomeProject.iOS SomeSolution.sln
The "AppStore|iPhone" build configuration they both use is set to "Link SDK assemblies only" under the iOS Build project settings.
While the command line archiving runs, it definitely prints LinkMode: SdkOnly in the MTouch Task portion of the console output.
Resulting Archives
On the project giving me trouble, the resulting xcarchive files are 102MB for command line and 66MB for Xamarin Studio (difference: 36MB), with Xcode estimates of 69MB and 35MB in App Store size, respectively.
Inside the xcarchive files, it gets more confusing. There are two files with differences and those two files are different by ~60MB (which doesn't match the above difference):
dSYM file: 17kb vs. 29.2MB (weird)
[within the .app file] app executable: 30.1MB vs. 65.7MB (where I expected the difference)
Note that mdtool is mostly deprecated (still used for classic, not unified, apps) since Xamarin.iOS moved to use msbuild as it's build system.
dSYM file: 17kb vs. 29.2MB (weird)
The former is wrong. Note: a bug was fixed recently, you might need to rebuild, not just build, to get the correct .dSYM.
This is the symbol directory size. This is not something that is shipped (to customers) as part of your application. However it's important to archive since it will be used to symbolicate any crash reports (coming from customers) for your application.
30.1MB vs. 65.7MB
If looks like the first case is a thin (e.g. only ARMv7) binary while the later is a fat (e.g. ARMv7 + ARM64) application. For new applications Apple will only accept fat applications (i.e. both 32 and 64 bits) on the AppStore.
Xcode estimates
The estimates can be quite wrong since there's compression on the files. It's even more complex since Apple's DRM will encrypt the executable part of your application - and encrypted data does not compress well (or it's a very bad encryption ;-).
Related
Using XCode I created 12 identical frameworks, only their names are different (each deriving from its respective XCode project name).
Following this guideline I embedded one of the frameworks into a Xamarin.ios project as a native reference.
Using [DllImport("Framework", EntryPoint = "Functionname")] I am able to access any of the 12 frameworks in both, Debug and Release mode and on both, Simulator and device. So far, so good.
BUT, when adding all of the 12 frameworks to the Xamarin.ios project strange things start to happen during the run on a device (the Simulator is somehow not affected!): only a couple of the frameworks can be accessed (normally 4), the rest throws a Dllnotfound exception. And even more: depending on the sequence of adding a framework to the Xamarin.ios project it may be accessed or throw the exception(!) For example if I start the adding process with one of the 8 "bad" frameworks from a former build process, this one will no longer be bad and can be beautifully accessed - in return one of the accessible frameworks from a former build process will then throw Dllnotfound.
To clarify, the 12 frameworks all have the same inner life, only different names and different entry point names, the rest is completely identical, hence interchangeable.
My first thought was a limit in number or size of embedded frameworks that was established for Xamarin projects?? In my case the app's total size with 12 frameworks is around 110 Mb in Debug mode.
My next thought was a possible symbol collision between the frameworks: But these are not static libraries using "Internal__" with a huge pool of all symbols together, but a strictly separated set of frameworks with different names (container system). Furthermore, a symbol collision would lead to an error during build, not during run...
Another thought was about my free provisioning profile: maybe with a paid developer account there is no limit for the number of frameworks to be embedded?? That would explain, why it's always working on the Sim...
Some more things I have tried and all potential combinations of them as well (though without success so far):
Using different versions of XCode to build the frameworks (version 8 and 11)
Using different versions of Visual Studio for Mac to build the calling program (2017 and 2019)
Using different versions of deployment on a device (iOS 10.3 and 13.2)
Using the option "smart link" for the native reference in Visual Studio
Using the option "force load" for the native reference in Visual Studio
Using additionally the option to specify linker flags in "additional mtouch arguments" for the native reference in Visual Studio
Using the setting "Link all assemblies" in Visual Studio
Am I missing something in my process, in my setup or in my idea?
Any help would be appreciated after so much time of investigation. Thanks:-)
While exploring about the platform setup for OpenCASCADE, I came to know about WOK commands which arent needed for CMake build system to use with OpenCASCADE
However another option of genproj tool (for which I havent yet found any exe but DLLs..) to be used with MSVC+ in built compiler so that we dont need any gcc installation
Whats the difference between the twos and which one is better and easier??
Also suggest me how to download and install and setup genproj on windows
OCCT project provided the following build systems:
CMake. This is the main building system since OCCT 7.0.0.
It allows building OCCT for almost every supported target platform.
WOK. This was an in-house building system used by OCCT before 7.0.0 release.
The tool handled classes defined in CDL (CAS.CADE definition language) files (WOK generated C++ header files from CDL) and supported building in a distributed environment (e.g. local WOK setup builds only modified source files and reused unmodified binary / object files from local network). WOK support has been discontinued since OCCT 7.5.0 and unlikely will be able building up-to-date OCCT sources (although project structure remains compatible with WOK).
genproj. This is a Tcl script allowing to generate project for building OCCT using Visual Studio (2010+), Code::Blocks, XCode and Qt Creator. This script has been initially extracted from WOK package (where it was implemented as command wgenproj in it's shell) and now maintained independently from it.
qmake. Experimental adm/qmake solution can be opened directly from QtCreator without CMake plugin (the project files will be generated recursively by qmake). Although header files generation (filling in inc folder) still should be done using genproj (qmake scripting capabilities were found too limited for this staff).
genproj doesn't require any DLLs or EXE files - it comes with OCCT itself and requires Tcl interpreter. On Windows platform it can be executed with genconf.bat and genproj.bat batch scripts in the root of OCCT source code folder. At first launch it will ask to put a path to tclsh.exe.
While CMake is the main building tool for OCCT project, genproj remains maintained and used by (some) developers - mostly due to personal habits and hatred to CMake. They differences of genproj from CMake that could be considered as advantages in some cases:
Generated project files can be moved to another location / computer without necessity to re-generate them.
Simplified 3rd-party dependency search tool genconf with GUI based on Tcl/Tk.
Batch-script environment/configuration files (env.bat and custom.bat), although CMake script in OCCT emulates similar files.
Generated Visual Studio solution contains Debug+Release and 32bit/64bit configurations.
Running Draw Harness and regression tests can be started directly from Visual Studio (without building any INSTALL target).
No problems with CMakeCache.txt.
Limitations of genproj:
No CMake configuration files. Other CMake-based projects would not be able re-using configuration files to simplify 3rd-party setup.
Regeneration of project files should be called explicitly.
Out-of-source builds are not supported (however, each configuration is put into dedicated sub-folder).
No INSTALL target.
No PCH (pre-compiler header file) generation.
It should be noted, that several attempts have been done to make compiler / linker flags consistent between CMake and genproj, but in reality they may be different.
I created a haxe project using openfl. I can build and run the project on my own desktop using lime test windows.
Now how do I actually ship this project to other users?
I tried simply zipping the binary output created by running the command above. When I then unpack this zip on a different computer and start the executable file it will complain that I'm missing certain .dll files (more specifically the libstdc++-6.dll file).
Although this is not a direct answer to your question, a solution to this issue would be to compile through another software/tool, such as FlashDevelop.
For a few versions already, FlashDevelop includes an App manager feature that allows you to easily install the latest versions of Haxe, Lime & OpenFl (in an all-in-one package), and compile for all the Haxe/Lime/OpenFl targets seamlessly by just switching a value in a drop-down menu.
This allowed me to compile without any problems native C++ or Neko versions of my projects, thus embedding all the necessary files that could be zipped and sent to other computers.
Is it possible to run J2ME apps on Android phones? If so, what is the installation procedure?
Otherwise, is it possible to convert .jad files to .apk? In this case, what is the procedure.
(I have already tested the procedure offered by netmite but it doesn't seem to work.)
Using this site http://www.netmite.com/android/srv/2.0/getapk.php you can convert your J2ME application in to Android Application. You need to just supply your .Jad & .Jar file in it and it will generate Android's executable file .apk for you.
However in it doesn't able to convert all the feature of Java ME to Android, but basics can be easily converted.
You can try phoneME, netmite j2me app runner, jblend, jbed like jeme emulators in android. For now, phoneME is the best. you can get various version of phoneME here http://davy.preuveneers.be/phoneme
You also need OI file manager to select files in phoneME.
A complete guide can be found here http://w3epic.com/run-java-apps-j2me-on-android-devices-guide/ for rest of other emulators (if you want to try).
#dennis
I got it, thanks.
MicroEmu open source project hasn't been mentioned yet, and here it goes: https://code.google.com/p/microemu/
I searched for a good JavaME emulator for Android for a long time, and finally found one. This here is what you need:
http://davy.preuveneers.be/phoneme/
No doubt the best there is for Android.
Added 15th January 2016:
Reply from the author of phoneME, Davy Preuveneers, in regards to the Android 5.0+ issue commented by Álvaro Gutiérrez:
Hi,
I am testing on a Samsung Galaxy S4 running Android 5.0.1, and the
"phoneME Advanced - Foundation Profile + MIDP FullHD Resolution" build
seems to run just fine on this device.
Also, following this thread
Position Independent Executables and Android Lollipop,
I ran:
$ readelf -l libcvm.so | grep -i "file type"
and it reports:
Elf file type is DYN (Shared object file)
So according to the website this is OK.
However, for the CDC and Foundation profiles (console like
applications), there is indeed an issue where you get this error:
"Error: only position independent executables (PIE) are supported"
However, for those 2 profile I call a native executables and redirect
the native stdout/stderr streams to Android, whereas for the MIDP dual
stack I load a library and create a complicated wrapper to get things going.
I can recompile with -fPIE and -pie options but will then end up with
binaries that are no longer backwards compatible with devices running
Android 4.0 and below. That is why I added some additional builds to my
website for Android 5+ devices:
http://davy.preuveneers.be/phoneme/?q=node/10
Best regards,
Davy
I have some projects built with different versions of VS2005 that require different run-time version. i need to display the assemblyIdentity to see which run-time is required to run the program. I need the information to include the specific VC80 runtime MSM in my WiX installer project.
{Edit}
While the binaries have been built with Visual Studio I don't have a VS on the PCs where WiX shall be used. I am reluctant to install an Express version, since I am a guest on that PC.
{/Edit}
How can I conviniently display the embedded manifest? Preferrable with a small tool, command line tool would be OK.
Manifests are stored as resource in executables/DLLs. These are stored under RT_MANIFESTresource type. Open the resources under it and parse it as XML.
One example is pasted below (I opened one of my EXE using VS resource editor):
The PeStudio is a small tool that does the job. Including displaying the manifest in clear text.
Additionally it displays all DLLs that must be present on target system. That helps to author the installer.