Mono Runtime Need To Be Bundled With Mono Winform App For Mac
This page is likely outdated (last edited on 12 Dec 2012). Visit the for updated content. MonoMacPackager With the new release of the add-in for MonoDevelop, you can easily turn your Mono application into a Mac bundle, and you can also get a Mac installer for your application. If you want to create self-contained Mac bundles or publish your software to the Mac AppStore, you should get which is a strict superset of MonoMac.
Table of contents. Getting Started You will need the following components installed:. From Apple:. At least XCode 4.5, this contains the developer tools to build Mac apps. Apple’s Application Tools (login to developer.apple.com/mac). Yes, you need this. No, you can’t ignore this.
You wont be able to publish to the AppStore without it. Yes, we mean it. From Mono:. Mono 2.10.9.
Mono Runtime Need To Be Bundled With Mono Winform App For Mac Mac
MonoDevelop 3.1.0 (released on December 12th) Creating your Mac application Mac bundles are directories with the.app extension that contain all of the components necessary for your application to run. They contain your executable, any images, UI definitions, pdfs, graphics, data files, internationalization resources and any other resource that your application needs at runtime. If you want to learn more about what goes in a bundle, you can read Apple’s. To create native Mac bundles, you should create a new project based on any of the MonoMac profiles: the document-based application, the empty-application, or the window-based application. This will configure your project to be compiled as a Mac bundle. When you compile your application, MonoDevelop will create a Mac bundle that integrated with the operating system. You will want to provide a custom icon, and tune the launch parameters in the Info.plist file that MonoDevelop generates for you.
Bundles and Mono By default, MonoDevelop creates application bundles that require the Mono framework to be installed (it is typically installed in /Library/Frameworks/Mono.framework). This creates small bundles, as only your code and your resources are packaged, the entire Mono stack is shared across all of the Mono applications on the System. But sometimes you want to distribute your application without requiring end users to install Mono on their own, distribute your app on the Mac App Store, or you might want to take a dependency on a particular version of Mono that you have tested and QAed on site. For those scenarios, you should obtain a license to. Creating an Installer package Even if your bundle is completely self-contained into the.app directory, if you are planning on distributing your app in the Mac AppStore, you must create an installer package.
Or you might want to create an installer to give your users an installer, instead of having them drag-and-drop the application into their /Applications folder. You can distribute this.pkg file to your users, and it will guide them through the process of installing your application, this is what the generated installer looks like if you check this option.
Type Name Latest commit message Commit time Failed to load latest commit information. Nov 9, 2018 May 8, 2018 Nov 28, 2018 Oct 15, 2018 Nov 28, 2018 Nov 30, 2018 Apr 13, 2018 Nov 13, 2018 Oct 24, 2018 Oct 15, 2018 Nov 6, 2018 Dec 1, 2018 May 5, 2018 Dec 1, 2018 Nov 29, 2018 Oct 30, 2018 Nov 13, 2018 Nov 13, 2018 Nov 23, 2017 Nov 29, 2018 Nov 30, 2018 Nov 13, 2018 Nov 20, 2018 Feb 23, 2017 Nov 6, 2018 Nov 13, 2018 Mar 31, 2016 Nov 13, 2017 Nov 28, 2018 May 5, 2015 Mar 28, 2016 Aug 30, 2018 Oct 26, 2014 Nov 19, 2018 Oct 19, 2018 May 31, 2016 May 31, 2016 Dec 3, 2015 Apr 19, 2011 Nov 30, 2018 Sep 15, 2008 Feb 1, 2007 Nov 12, 2018. Mono is a software platform designed to allow developers to easily create cross platform applications. It is an open source implementation of Microsoft's.NET Framework based on the ECMA standards for C# and the Common Language Runtime.
The Mono project is part of the. Build Status OS Architecture Status Debian 9 amd64 Debian 9 i386 Debian 9 armel Debian 9 armhf Debian 9 arm64 OS X amd64 OS X i386 Windows amd64 Windows i386 CentOS s390x (cs) Debian 9 ppc64el (cs) AIX ppc64 (cs) (cs) = community supported architecture Compilation and Installation Building the Software Please see our guides for building Mono on,. Note that building from Git assumes that you already have Mono installed, so please download and before trying to build from Git. This is required because the Mono build relies on a working Mono C# compiler to compile itself (also known as ). If you don't have a working Mono installation If you don't have a working Mono installation, you can try a slightly more risky approach: getting the latest version of the 'monolite' distribution, which contains just enough to run the 'mcs' compiler. You do this with: # Run the following line after./autogen.sh make get-monolite-latest This will download and place the files appropriately so that you can then just run: make The build will then use the files downloaded by make get-monolite-latest.
Testing and Installation You can run the mono and mcs test suites with the command: make check. Expect to find a few test suite failures. As a sanity check, you can compare the failures you got with. You can now install mono with: make install You can verify your installation by using the mono-test-install script, it can diagnose some common problems with Mono's install. Failure to follow these steps may result in a broken installation. Using Mono Once you have installed the software, you can run a few programs:. mono program.exe runtime engine.
mcs program.cs C# compiler. monodis program.exe CIL Disassembler See the man pages for mono(1), mcs(1) and monodis(1) for further details. Directory Roadmap. acceptance-tests/ - Optional third party test suites used to validate Mono against a wider range of test cases.
data/ - Configuration files installed as part of the Mono runtime. docs/ - Technical documents about the Mono runtime. external/ - Git submodules for external libraries (Newtonsoft.Json, ikvm, etc). ikvm-native/ - Glue code for ikvm.
libgc/ - The (deprecated) Boehm GC implementation. llvm/ - Utility Makefiles for integrating the Mono LLVM fork. m4/ - General utility Makefiles. man/ - Manual pages for the various Mono commands and programs. mcs/ - The class libraries, compiler and tools. class/ - The class libraries (like System., Microsoft.Build, etc.).
mcs/ - The Mono C# compiler written in C#. tools/ - Tools like gacutil, ikdasm, mdoc, etc. mono/ - The core of the Mono Runtime. arch/ - Architecture specific portions. benchmark/ - A collection of benchmarks. btls/ - Build files for the BTLS library which incorporates BoringSSL.
cil/ - Common Intermediate Representation, XML definition of the CIL bytecodes. dis/ - CIL executable Disassembler. eglib/ - Independent implementation of the glib API. metadata/ - The object system and metadata reader.
mini/ - The Just in Time Compiler. profiler/ - The profiler implementation. sgen/ - The SGen Garbage Collector implementation. tests/ - The main runtime tests. unit-tests/ - Additional runtime unit tests.
utils/ - Utility functions used across the runtime codebase. msvc/ - Logic for the MSVC / Visual Studio based runtime and BCL build system. The latter is experimental at the moment. packaging/ - Packaging logic for the OS X and Windows Mono packages. po/ - Translation files.
runtime/ - A directory that contains the Makefiles that link the mono/ and mcs/ build systems. samples/ - Some simple sample programs on uses of the Mono runtime as an embedded library. scripts/ - Scripts used to invoke Mono and the corresponding program. sdks/ - A new way of embedding Mono into Xamarin.iOS, Xamarin.Android and other products. support/ - Various support libraries.
tools/ - A collection of tools, mostly used during Mono development. Contributing to Mono Before submitting changes to Mono, please review the. Please pay particular attention to the section. Reporting bugs To submit bug reports, please. Please use the search facility to ensure the same bug hasn't already been submitted and follow our on how to make a good bug report.
Configuration Options The following are the configuration options that someone building Mono might want to use:.with-sgen=yes,no - Generational GC support: Used to enable or disable the compilation of a Mono runtime with the SGen garbage collector. On platforms that support it, after building Mono, you will have both a mono-boehm binary and a mono-sgen binary. Mono-boehm uses Boehm, while mono-sgen uses the Simple Generational GC.with-libgc=included, none - Selects the default Boehm garbage collector engine to use. included: ( slightly modified Boehm GC) This is the default value for the Boehm GC, and it's the most feature complete, it will allow Mono to use typed allocations and support the debugger.
none: Disables the inclusion of a Boehm garbage collector. This defaults to included.enable-cooperative-suspend. If you pass this flag the Mono runtime is configured to only use the cooperative mode of the garbage collector. If you do not pass this flag, then you can control at runtime the use of the cooperative GC mode by setting the MONOENABLECOOPSUSPEND flag.with-tls=thread,pthread. Controls how Mono should access thread local storage, pthread forces Mono to use the pthread APIs, while thread uses compiler-optimized access to it. Although thread is faster, it requires support from the compiler, kernel and libc. Old Linux systems do not support with thread.
This value is typically pre-configured and there is no need to set it, unless you are trying to debug a problem.with-sigaltstack=yes,no. Experimental: Use at your own risk, it is known to cause problems with garbage collection and is hard to reproduce those bugs. This controls whether Mono will install a special signal handler to handle stack overflows. If set to yes, it will turn stack overflows into the StackOverflowException. Otherwise when a stack overflow happens, your program will receive a segmentation fault.
The configure script will try to detect if your operating system supports this. Some older Linux systems do not support this feature, or you might want to override the auto-detection.with-staticmono=yes,no. This controls whether mono should link against a static library (libmono.a) or a shared library (libmono.so).
This defaults to yes, and will improve the performance of the mono program. This only affects the `mono' binary, the shared library libmono.so will always be produced for developers that want to embed the runtime in their application.with-xen-opt=yes,no - Optimize code for Xen virtualization. It makes Mono generate code which might be slightly slower on average systems, but the resulting executable will run faster under the Xen virtualization system. This defaults to yes.with-large-heap=yes,no - Enable support for GC heaps larger than 3GB. This defaults to no.enable-small-config=yes,no - Enable some tweaks to reduce memory usage and disk footprint at the expense of some capabilities. Typically this means that the number of threads that can be created is limited (256), that the maximum heap size is also reduced (256 MB) and other such limitations that still make mono useful, but more suitable to embedded devices (like mobile phones). This defaults to no.with-ikvm-native=yes,no - Controls whether the IKVM JNI interface library is built or not.
This is used if you are planning on using the IKVM Java Virtual machine with Mono. This defaults to yes.with-profile4=yes,no - Whether you want to build the 4.x profile libraries and runtime. This defaults to yes.with-libgdiplus=installed,sibling, - Configure where Mono searches for libgdiplus when running System.Drawing tests. It defaults to installed, which means that the library is available to Mono through the regular system setup.
sibling can be used to specify that a libgdiplus that resides as a sibling of this directory (mono) should be used. Or you can specify a path to a libgdiplus.enable-minimal=LIST. Use this feature to specify optional runtime components that you might not want to include. This is only useful for developers embedding Mono that require a subset of Mono functionality. The list is a comma-separated list of components that should be removed, these are:. aot: Disables support for the Ahead of Time compilation. attach: Support for the Mono.Management assembly and the VMAttach API (allowing code to be injected into a target VM).
com: Disables COM support. debug: Drop debugging support. decimal: Disables support for System.Decimal.
fullmessages: By default Mono comes with a full table of messages for error codes. This feature turns off uncommon error messages and reduces the runtime size.
generics: Generics support. Disabling this will not allow Mono to run any 2.0 libraries or code that contains generics. jit: Removes the JIT engine from the build, this reduces the executable size, and requires that all code executed by the virtual machine be compiled with Full AOT before execution. largecode: Disables support for large assemblies. logging: Disables support for debug logging. pinvoke: Support for Platform Invocation services, disabling this will drop support for any libraries using DllImport. portability: Removes support for MONOIOMAP, the environment variables for simplifying porting applications that are case-insensitive and that mix the Unix and Windows path separators.
profiler: Disables support for the default profiler. reflectionemit: Drop System.Reflection.Emit support. reflectionemitsave: Drop support for saving dynamically created assemblies (AssemblyBuilderAccess.Save) in System.Reflection.Emit.
shadowcopy: Disables support for AppDomain's shadow copies (you can disable this if you do not plan on using appdomains). simd: Disables support for the Mono.SIMD intrinsics library. ssa: Disables compilation for the SSA optimization framework, and the various SSA-based optimizations.enable-llvm.enable-loadedllvm. This enables the use of LLVM as a code generation engine for Mono. The LLVM code generator and optimizer will be used instead of Mono's built-in code generator for both Just in Time and Ahead of Time compilations. See for the full details and up-to-date information on this feature. You will need to have an LLVM built that Mono can link against.
The -enable-loadedllvm variant will make the LLVM backend into a runtime-loadable module instead of linking it directly into the main mono binary.enable-big-arrays - Enable use of arrays with indexes larger than Int32.MaxValue. By default Mono has the same limitation as.NET on Win32 and Win64 and limits array indexes to 32-bit values (even on 64-bit systems). In certain scenarios where large arrays are required, you can pass this flag and Mono will be built to support 64-bit arrays. This is not the default as it breaks the C embedding ABI that we have exposed through the Mono development cycle.enable-parallel-mark. Use this option to enable the garbage collector to use multiple CPUs to do its work. This helps performance on multi-CPU machines as the work is divided across CPUS. This option is not currently the default on OSX as it runs into issues there.
We now offer it in three colors: blue, black, and red. Capacity goes up to 4TB, a milestone for unpowered external hard drives! With USB 3.1 speeds and ADATA-backed quality, the HD650 delivers spacious and secure storage. The ADATA DashDrive Durable HD710 (1TB) ($89.99) is a big blue portable hard drive. The UD320 is manufactured through a special chip-on-board (COB) process, resulting in high water and impact resistance. Engineered to be of the utmost quality and reliability, it is further guaranteed by ADATA’s lifetime warranty. Adata dashdrive durable.
This option only applies to the Boehm GC.enable-dtrace. On Solaris and MacOS X builds a version of the Mono runtime that contains DTrace probes and can participate in the system profiling using DTrace.disable-dev-random. Mono uses /dev/random to obtain good random data for any source that requires random numbers.
If your system does not support this, you might want to disable it. There are a number of runtime options to control this also, see the man page.with-csc=roslyn,mcs,default. Use this option to configure which C# compiler to use. By default the configure script will pick Roslyn, except on platforms where Roslyn does not work (Big Endian systems) where it will pick mcs. If you specify 'mcs', then Mono's C# compiler will be used. This also allows for a complete bootstrap of Mono's core compiler and core libraries from source.
If you specify 'roslyn', then Roslyn's C# compiler will be used. This currently uses Roslyn binaries.enable-nacl. This configures the Mono compiler to generate code suitable to be used by Google's Native Client:. Currently this is used with Mono's AOT engine as Native Client does not support JIT engines yet.enable-wasm. Use this option to configure mono to run on WebAssembly. It will set both host and target to the WebAssembly triplet. This overrides the values passed to -host or -target and ignored what config.sub guesses.
This is a workaround to enable usage of old automake versions that don't recognize the wasm triplet. Working With Submodules Mono references several external git submodules, for example a fork of Microsoft's reference source code that has been altered to be suitable for use with the Mono runtime. This section describes how to use it. An initial clone should be done recursively so all submodules will also be cloned in a single pass: $ git clone -recursive git@github.com:mono/mono Once cloned, submodules can be updated to pull down the latest changes. This can also be done after an initial non-recursive clone: $ git submodule update -init -recursive To pull external changes into a submodule: $ cd $ git pull origin $ cd $ git add $ git commit By default, submodules are detached because they point to a specific commit.