mono / embeddinator-4000 Goto Github PK

Tools to turn .NET libraries into native libraries that can be consumed on Android, iOS, Mac, Linux and other platforms.

License: MIT License

C# 71.57% Lua 0.84% C 5.86% C++ 2.32% Shell 1.66% Java 5.73% Makefile 0.74% Objective-C 10.54% PowerShell 0.63% F# 0.10% Swift 0.01%

mono cppsharp monodroid monotouch mobile java bindings interop csharp xamarin

embeddinator-4000's Introduction

Embeddinator-4000 is a tool to turn existing .NET libraries into libraries that can be consumed by other languages.

It is a tool that takes a .NET assembly and generates the necessary glue to surface the .NET API as a native API. The goal is to surface .NET libraries to all ecosystems where Mono/Xamarin run, and for each platform we provide an interface that is native to that platform as well as the tools needed to turn a .NET library into something that can be consumed on that platform.

Presently there is support for .NET to C, Objective-C (across the various Apple platforms) and Java (Android and regular Java), across Windows, Linux and macOS platforms.

Getting Started

Check out our documentation to get started.

Community

Feel free to join us at our #managed-interop Gitter discussion channel.

Building

Clone this repository
Initialize/update submodules: git submodule update --recursive --init
Open the solution file Embeddinator-4000.sln with Visual Studio or Visual Studio For Mac
Build

If you prefer to build from the command line Cake or Make can be used to build instead of Visual Studio For Mac.

Cake

The Android/C portions of the project can also be built with Cake using the build.ps1 / build.sh scripts.

On OS X, you can setup your environment for Android by running a shell script:

./build.sh -t Generate-Android -v diagnostic

On Windows, in Powershell:

.\build.ps1 -t Generate-Android -v diagnostic

This will download a master build of Xamarin.Android and extract it into /external/Xamarin.Android.

Embeddinator-4000.exe will be compiled to build/lib/Release. The Cake script will also run Embeddinator against a test assembly, so you can be sure your system is setup properly.

Makefile

The Objective-C portions of the project can be built with make in objcgen.

Nuget Generation

To generate the nuget one can use either (they both invoke the same build process):

make nuget in objcgen
Cake :./build.sh -t Create-Package

Usage

The getting started documentation walks through basic usage of the Embeddinator.

More details on platform specific invocations can be found here.

Development

The contributing guide covers a number of areas to consider when contributing to Embeddinator-4000.

A number of internal documentation files exist describing the project and internal structure of Embeddinator:

embeddinator-4000's People

Contributors

Stargazers

Watchers

Forkers

ctaggart gozhack tijoytom-zz alisterk bt-003 spouliot rolfbjarne arlm tritao dalexsoto vincentdondain chamons plumpmath realvictorprm mandel-macaque clevercompiler 0x53a branux devcfgc pacificit jonathanpeppers smstuebe matthid raoulholzer tonytallman zhaoyingju jsuarezruiz postromantic atsushieno zgramana xamarui mnjstwins delort dason2u sokodev 07101994 mxamarin eddykuo jongalloway daroubing alexanderka1 knocte sagarcia1 aidmsu equinox2k wavebit jddl shalokshalom emysa341 ashipilov qqlizhn jaykrell philippecreytens kleyoit silic0ns0ldier tombly laeeth robinmacharg awesomedotnetcore ruaan daebak1209 hyo1411 monarchsolutions displaynote froxul branchseer vgmello jichulu perozdrero epatstarkey quarky terrajobst yumingtao dogukandemir david-bouyssie augustoproiete-forks devbox10 hobbit19 dasmihir20 optikos gkanthed1984 prasannag felipebaltazar longde123 dpburton isabella232 frankfanslc amoshk cybersys jeff-cn ycf980625 mohachouch 1substaviogi valhalla-proj

embeddinator-4000's Issues

Passing nonexistant path to objcgen gives unexpected error

mono bin/Debug/objcgen.exe NonExistantLib.dll

Parsing assemblies...
EM0000: Unexpected error - Please fill a bug report at https://github.com/mono/Embeddinator-4000/issues
System.IO.FileNotFoundException: Could not find file "/Users/donblas/Programming/Embeddinator-4000/objcgen/NonExistantLib.dll". ---> System.IO.FileNotFoundException: Could not find file "/Users/donblas/Programming/Embeddinator-4000/objcgen/NonExistantLib.dll".
File name: '/Users/donblas/Programming/Embeddinator-4000/objcgen/NonExistantLib.dll'
  at System.IO.FileStream..ctor (System.String path, System.IO.FileMode mode, System.IO.FileAccess access, System.IO.FileShare share, System.Int32 bufferSize, System.Boolean anonymous, System.IO.FileOptions options) [0x0019c] in <164469fa6d844a078126fd8006807335>:0 
  at System.IO.FileStream..ctor (System.String path, System.IO.FileMode mode, System.IO.FileAccess access, System.IO.FileShare share) [0x00000] in <164469fa6d844a078126fd8006807335>:0 
  at (wrapper remoting-invoke-with-check) System.IO.FileStream:.ctor (string,System.IO.FileMode,System.IO.FileAccess,System.IO.FileShare)
  at IKVM.Reflection.Universe.OpenRawModule (System.String path) [0x0000c] in <7ee1204f3a80406b806f1062457cff67>:0 
  at IKVM.Reflection.Universe.LoadFile (System.String path) [0x00002] in <7ee1204f3a80406b806f1062457cff67>:0 
  at IKVM.Reflection.Universe.LoadFile (System.String path) [0x0002e] in <7ee1204f3a80406b806f1062457cff67>:0 
  at Embeddinator.Embedder.Generate (System.Collections.Generic.List`1[T] args) [0x0002f] in <7ee1204f3a80406b806f1062457cff67>:0 
  at Embeddinator.Driver.Main2 (System.String[] args) [0x002b7] in <7ee1204f3a80406b806f1062457cff67>:0 
  at Embeddinator.Driver.Main (System.String[] args) [0x00002] in <7ee1204f3a80406b806f1062457cff67>:0

[C] Path arguments for compilation are passed unsafe

Currently the arguments are passed in such way cl.exe YourSuperPath With Spaces/Sourcefile.c
which is unsafe because the example already shows that spaces aren't taken into account.
It's needed to at additional " to fix this.

[objc] Add support for `params` on methods

using va_list and friends on the ObjC side

[license] Adding information for the license of the generated code.

Just see the gitter chat.
☝️ 21. März 2017 18:21

Already discussed, only needs to be added.

[objc] Map `GetHashCode` and `Equals` to `NSObject` protocol `hash` and `isEqual:`

The semantics are identical.

@property(readonly) NSUInteger hash;

hash returns an NSUInteger so it differs in 32/64 bits, while .NET always return a 32bits integer;

https://developer.apple.com/reference/objectivec/1418956-nsobject/1418859-hash?language=objc

- (BOOL)isEqual:(id)object;

a non-bound NSObject (i.e. does not have a managed peer) must not be sent to the mono runtime.

https://developer.apple.com/reference/objectivec/1418956-nsobject/1418795-isequal?language=objc

[dependencies] Update CppSharp

An update to the latest CppSharp is highly recommend by me, because it's needed to fix compatibility issue with VS 2017 and critical bugs for correctly supporting windows 10 sdks.

As already figured out some fixes to the auto compilation have to be made for windows, where solving this issue is required for solving issue #165.

[objc] Optionally generate an Xcode project that can consume the library

It should also be able to build the library itself (like PR #42 has) since it's easier (for most people) to control build options from Xcode.

[objc] Regenerate documentation (from assembly.xml) in headers

It should be possible to convert a csc-output'ed .xml documentation file and, given to as an input to the generator, create the somewhat related documentation to the ObjC API.

[objc][ios] One framework with both simulator and device support, or one framework for simulator and one for device?

One framework with both simulator and device is:

Much easier to consume. Xcode does not make it easy to build with different frameworks (at least I haven't found a way).
Bigger. We can't strip IL. We might have to disable other linker optimizations that make assemblies non-architecture-agnostic.

We can also build both, and let the user decide.

[objc][perf] Use metadata tokens in some cases

Right now the type and method lookups are done using strings.

	const char __method_name [] = "First.Second.Third.ClassWithNestedNamespace:ToString()";
	static MonoMethod* __method = nil;
	if (!__method) {
		__lookup_class_First_Second_Third_ClassWithNestedNamespace ();
		__method = mono_embeddinator_lookup_method (__method_name, First_Second_Third_ClassWithNestedNamespace_class);
	}

That has a nice advantage (that we want to exploit) as it allow swapping a .dll (if the API is identical) on some platforms (e.g. won't work with iOS/AOT). This can be very useful in debug mode.

However we could use the metadata tokens when building release code. That should (benchmarking needed) provide a performance boost (on first call) and reduce the generated (and final) code side (since many strings can go away).

[objc] camelCase instead of PascalCase for methods

Currently when generating Objective-C methods, e4k creates them using PascalCase (convention in C#) instead of camelCase (convention in ObjC).

Cocoa coding guidelines

public static void PrintSomething ()
{
	Console.WriteLine ("Hello!!!");
}

public void PrintSomethingNonStatic ()
{
	Console.WriteLine ("Hello (not static)!!!");
}

Objective C

+ (void) PrintSomething;
- (void) PrintSomethingNonStatic;

Those methods names should be using camel case (start with a lowercase).

error in glib.h g_memdup with VS2013 installed

When I try to --compile --dll, it gives a bunch of errors about line 135 in glib.h which ends ups being:

static inline gchar   *g_strdup (const gchar *str) { if (str) { return (gchar*) g_memdup (str, (guint)strlen (str) + 1); } return NULL; }

It is picking up VS 2013 as the default dependency instead of VS 2015. My hunch is that stuff works with only VS 2015. I'll investigate a bit further.

PS C:\Users\cameron\fs\embeddinator-4000\tests\Basic> MonoEmbeddinator4000 --compile --dll bin\Release\ClassLibrary1.dll
Parsing assemblies...
    Parsed 'ClassLibrary1.dll'
Processing assemblies...
Generating binding code...
    Generated: ClassLibrary1.h
    Generated: ClassLibrary1.c
    Generated: glib.c
    Generated: glib.h
    Generated: main.c
    Generated: mono_embeddinator.c
    Generated: mono_embeddinator.h
Compiling binding code...
cl : Command line warning D9024 : unrecognized source file type 'C:\Users\cameron\fs\embeddinator-4000\tests\Basic\ClassLibrary1', object file assumed
        ClassLibrary1.c
        c:\users\cameron\fs\embeddinator-4000\tests\basic\glib.h(135) : error C2054: expected '(' to follow 'inline'
        c:\users\cameron\fs\embeddinator-4000\tests\basic\glib.h(135) : error C2085: 'g_strdup' : not in formal parameter list
        c:\users\cameron\fs\embeddinator-4000\tests\basic\glib.h(135) : error C2143: syntax error : missing ';' before '{'
        glib.c
        c:\users\cameron\fs\embeddinator-4000\tests\basic\glib.h(135) : error C2054: expected '(' to follow 'inline'
        c:\users\cameron\fs\embeddinator-4000\tests\basic\glib.h(135) : error C2085: 'g_strdup' : not in formal parameter list
        c:\users\cameron\fs\embeddinator-4000\tests\basic\glib.h(135) : error C2143: syntax error : missing ';' before '{'
        main.c
        C:\Users\cameron\fs\embeddinator-4000\tests\Basic\main.c(33) : error C2059: syntax error : '}'
        mono_embeddinator.c
        c:\users\cameron\fs\embeddinator-4000\tests\basic\glib.h(135) : error C2054: expected '(' to follow 'inline'
        c:\users\cameron\fs\embeddinator-4000\tests\basic\glib.h(135) : error C2085: 'g_strdup' : not in formal parameter list
        c:\users\cameron\fs\embeddinator-4000\tests\basic\glib.h(135) : error C2143: syntax error : missing ';' before '{'
        Generating Code...

Allow specifying explicit types to bind

As suggested by @jonpryor, allow specifying explicit types to bind with the CLI interface.

Maybe this could be done with either a whitelist or blacklist filter command line option, with wildcard support.

[perf] mono_method_desc calls are costly and executed on every call

Running this

#import <Foundation/Foundation.h>
#include "mono_embeddinator.h"
#include "properties.h"

int main (int argc, const char * argv[])
{
	@autoreleasepool {
		int counter = argc == 1 ? 1000000 : atoi (argv [0]);

		for (int i = 0; i < counter; i++) {
			assert (![Platform isWindows]);
		}
	}
	return 0;
}

is very slow:

clang perf-test.m -lproperties -L. -framework Foundation
time ./a.out
        0.93 real         0.87 user         0.04 sys

due to the fact that the MonoMethod is not cached, see generated code:

+ (bool)isWindows
{
    __lookup_class_Platform();
    const char __method_name[] = "Platform:get_IsWindows()";
    MonoMethodDesc* __desc = mono_method_desc_new(__method_name, /*include_namespace=*/true);
    MonoMethod* __method = mono_method_desc_search_in_class(__desc, Platform_class);
    mono_method_desc_free(__desc);
    if (__method == 0)
    {
        mono_m2n_error_t __error;
        __error.type = MONO_M2N_METHOD_LOOKUP_FAILED;
        __error.string = __method_name;
        mono_m2n_error(__error);
    }
    MonoObject* __exception = 0;
    MonoObject* __result;
    __result = mono_runtime_invoke(__method, 0, 0, &__exception);
    if (__exception != 0)
    {
        mono_m2n_error_t __error;
        __error.type = MONO_M2N_EXCEPTION_THROWN;
        __error.exception = (MonoException*) __exception;
        mono_m2n_error(__error);
    }
    void* __unbox = mono_object_unbox(__result);
    return *((bool*)__unbox);
}

@end

Moving (sharing) the initialization code (less code) and caching the MonoMethod like this:

+ (bool)isWindows
{
    const char __method_name[] = "Platform:get_IsWindows()";
    static MonoMethod* __method = nil;

    if (!__method)
    {
        __lookup_class_Platform();
        __method = __method_lookup (__method_name, Platform_class);

    }
    MonoObject* __exception = 0;
    MonoObject* __result;
    __result = mono_runtime_invoke (__method, 0, 0, &__exception);
    if (__exception)
        __method_exception_thrown (__exception);
    void* __unbox = mono_object_unbox(__result);
    return *((bool*)__unbox);
}

is a lot faster.

clang perf-test.m -lproperties -L. -framework Foundation
time ./a.out
        0.23 real         0.19 user         0.02 sys

[objc] Add error/warning tests for things we can't execute

From @spouliot #103 (comment)

We will need to do some error/warning tests (like touch tests) to ensure we don't regress things we can't execute. OTOH that can be done in a separate PR.

[objc] Generate good names without duplicates

We need to come up with good names while avoiding duplicate signatures.

Parameter names are better (than types), e.g. initWithFirstName:lastName:, but we can end up with duplicates.

Using types won't create duplicates, e.g. initWithString:string:, since C# requires unique signatures. However the names are less than ideal.

The best approach would be to try parameters first and, in case of duplication, fallback to types.

This must be done for all duplicates or at least in a way we're can be sure the generated code will always remain constant (i.e. the API must not change name between rebuilds because of the order of the methods being processed).

Gitter Chat for easier following workflow and discussions

Hello Joao,

I would like to see a gitter chat for this.
Simply because I'm having questions, want to talk about it etc. but with having the community involved too. Would be nice if you add it ;)

PS:
Of course, something different would be fine too. It's just about talking with devs easier about this library with informing the community too.

GetVisualStudioVersion failing with VS2010 installed

I'm trying this out and this is the first issue I've run into. It doesn't seem to detect my Visual Studio install.

PS C:\Users\cameron\fs\embeddinator-4000\tests\Basic> MonoEmbeddinator4000 --compile --dll bin\Release\ClassLibrary1.dll
Parsing assemblies...
    Parsed 'ClassLibrary1.dll'
Processing assemblies...
Generating binding code...
    Generated: ClassLibrary1.h
    Generated: ClassLibrary1.c
    Generated: glib.c
    Generated: glib.h
    Generated: main.c
    Generated: mono_embeddinator.c
    Generated: mono_embeddinator.h
Compiling binding code...

Unhandled Exception: System.Exception: Unknown Visual Studio version
   at CppSharp.MSVCToolchain.GetVisualStudioVersion(VisualStudioVersion version) in C:\Users\cameron\fs\embeddinator-4000\CppSharp\src\Core\Toolchains\MSVCToolchain.cs:line 115
   at CppSharp.MSVCToolchain.<>c__DisplayClass5_0.<GetVSToolchain>b__0(ToolchainVersion version) in C:\Users\cameron\fs\embeddinator-4000\CppSharp\src\Core\Toolchains\MSVCToolchain.cs:line 130
   at System.Collections.Generic.List`1.Find(Predicate`1 match)
   at CppSharp.MSVCToolchain.GetVSToolchain(VisualStudioVersion vsVersion) in C:\Users\cameron\fs\embeddinator-4000\CppSharp\src\Core\Toolchains\MSVCToolchain.cs:line 127
   at CppSharp.MSVCToolchain.GetSystemIncludes(VisualStudioVersion vsVersion) in C:\Users\cameron\fs\embeddinator-4000\CppSharp\src\Core\Toolchains\MSVCToolchain.cs:line 178
   at MonoManagedToNative.Driver.CompileCode() in C:\Users\cameron\fs\embeddinator-4000\binder\Driver.cs:line 244
   at MonoManagedToNative.Driver.Run() in C:\Users\cameron\fs\embeddinator-4000\binder\Driver.cs:line 324
   at MonoManagedToNative.Binder.Main(String[] args) in C:\Users\cameron\fs\embeddinator-4000\binder\Binder.cs:line 102

Looks to be blowing up here:
https://github.com/mono/CppSharp/blob/master/src/Core/Toolchains/MSVCToolchain.cs#L115

Vanilla update 3:

[driver] Add option to add custom .m files to the library

This will allow include native helper code into the final .dylib / framework.

[objc] Implement property indexers with subscripting

http://nshipster.com/object-subscripting/

[C] Auto compilation on windows is broken

The compilation on windows is broken due to several bugs.
E.g. issue #163 and #162 are breaking and that the library file for embedding mono isn't dynamically specified (either monosgen-2.0.lib or mono-2.0-sgen.lib). I already prepared fixes for this however, there are still bugs left like missing library paths.

Update to latest CppSharp version
Update compilation code for linking to system libaries
Specifying correct mono libraries
Fix Travis build
PR merged

[objc] Use #pragma mark to organize our generated headers for easy code navigation in xcode

http://nshipster.com/pragma/

Optimize cost of name generation of properties/methods/etc

Once we have this

chamons@9db59d9#commitcomment-21854521

let's add lazy generation / caching to the ProcessedMethod and such.

[objc][driver] Add option to generate 32 bits (i386) or fat (i386 and x86_64) dylibs for macOS target

Maybe like mtouch --abi option ?

$ file libmanaged.dylib
libmanaged.dylib: Mach-O 64-bit dynamically linked shared library x86_64

Standalone libraries

Does end user libraries require .net installed or are they standalone (single file, no references)?
I'd certainly prefer an option to have the later but I think currently they are the former (required .net to be installed).

[driver] Add an option to give an app.config file

In PR #127 we now use mono_domain_set_config and give some defaults, we can provide an option to pass a specific app.config file

[objc] Add support the default values in methods/ctors

E.g. for

	public class DefaultValues {

		public void Method (int i = 1)
		{
			Integer = i;
		}

		// to help test the method call was successful
		// only getter will be generated
		public int Integer { get; private set; }
	}

we can generate method() like:

- (void) method {
    method (1);
}

which requires less (generated) code (than calling mono_ API) and provide the same API.

[C] Support file embeddinator.c incompatible with windows

I ran into some issues with the support file embeddinator.c on windows.

The file unistd.h is not available under windows
The define PATH_MAX is not available under windows too

A couple of lines only needed to be changed for compiling it, however I'm not sure whether they're fine.

I changed the location of the include checking whether we're on windows or not
Seems like the equivalent of PATH_MAX is MAX_PATH under windows. I defined PATH_MAX as MAX_PATH

Won't build

Freshly git cloned project wont build because:
a) CppSharp.Generator is missing Mono.Cecil assembly
b) catch.hpp file is missing by Basic.Tests.

The workaround to a) is to install Mono.Cecil from NuGet (should I create a pull request?) as for the second I don't know (tests can be omitted for the moment I guess).

mono_embeddinator_error should be exception safe

mono_embeddinator_error takes a stack-allocated mono_embeddinator_error instance, which has const char * field.

That const char * field contains a malloc'ed memory, freed after mono_embeddinator_error returns.

That malloc will never be executed if mono_embeddinator_error throws an exception instead of just returning.

[objc] instance methods requires the instance to be used as argument (at build time and crash at runtime)

c# code

public class ClassWithoutNamespace {

	public override string ToString ()
	{
		return base.ToString ();
	}
}

generated code

@interface ClassWithoutNamespace : NSObject {
    @public MonoEmbedObject* _object;
}

- (ClassWithoutNamespace*)new;
- (char*)ToString:(ClassWithoutNamespace*)object;
@end

This force the caller to do something like:

	NSLog (@"%s", [nonamespace ToString:nonamespace]);

This should be:

- (char*)ToString;

Ideally it would be

NSString *toString;

but that's other 2 other issues (to be filled).

[general] Improve docs, showcase and contributing section

Currently the github page of Embeddinator is lacking detailed information about how it works, where it's useful, how to contribute etc. I consider this as very important.

My suggestions is following:
Start with adding a wiki which describes in more detail how to use it, add some examples both to the repository and the wiki and at least at a contributing.md .

[api] we must be able to override from where assemblies are loaded

The current code assume they will be with the executable. That's not gonna work for all scenarios, e.g. plugins. PR#42 ran into this issue while adding Xcode-based unit tests. There's a band-aid API to move things forward but it should be revisited to cover more scenarios*

creating a .framework will also require a different location, c.c. @rolfbjarne

reference: #42

[objc] Dont rebuild native library if surface did not change

At least in debug (where we don't use metadata tokens) we can detect if the assembly surface changed and just copy the .dll(s) into the library.

E.g.

tool is re-executed on the same binary -> skip generation and build;
tool generates the same header -> skip build

This would allow a developer to make a small change (code, not API) in his managed code and quickly be able to build/debug his native application.

warning: not to be used when developing e4k itself :)

[general] Support for VS 2017

Currently embeddinator does not support the usage of VS 2017 which is included in the newest CppSharp version. There are some bugs I'll list here which have to be fixed.

fix compilation option for VS 2017
fix build script for generating VS 2017 solutions (I'll make a PR as soon as possible)
Further bugs can appear. Stand by.

The compilation for VS2017 fails due to that the path of cl.exe is wrong.
For getting the correct one a additional dependency (which is already included in the newest CppSharp version) is needed. Whether we should use it must be discussed. What do you think @tritao ?

[objc] .NET .ctor are not inherited but `init*` methods are

See FIXME in Xcode's testConstructors for a test case

Potential solution: Use NS_UNAVAILABLE to redefine the non-existing init*.

Embeddinator shuts down without detailed error message

Hello fellows,

Embeddinator fails with a not detailed error message. That's not right, simply adding a description to the exception would help a lot.

E.g. the error code:

Unbehandelte Ausnahme: System.NotImplementedException: Die Methode oder der Vorgang ist nicht implementiert.
   bei MonoEmbeddinator4000.Driver.CreateGenerator() in D:\Users\Victor\Documents\Embeddinator-4000\binder\Driver.cs:Zeile 156.
   bei MonoEmbeddinator4000.Driver.Process() in D:\Users\Victor\Documents\Embeddinator-4000\binder\Driver.cs:Zeile 52.
   bei MonoEmbeddinator4000.Driver.Run() in D:\Users\Victor\Documents\Embeddinator-4000\binder\Driver.cs:Zeile 220.
   bei MonoEmbeddinator4000.CLI.Main(String[] args) in D:\Users\Victor\Documents\Embeddinator-4000\binder\CLI.cs:Zeile 182

System.OverflowException: Value was either too large or too small for a UInt64

I have tried to convert the Azure IoT Hub C# SDK to run natively on iOS.
https://www.nuget.org/packages/Microsoft.Azure.Devices.Client.PCL/

When I tried to compile(?) it , I got the following error. Am I doing something wrong ?

PS C:\Users\YuriK\Documents\Visual Studio 2015\Projects\XamarinSource\XamarinSource\bin\Debug> C:\Users\YuriK\dev\work\Embeddinator-4000\build\lib\Debug\MonoEmbeddinator4000.exe --gen=obj-c
 -p=ios -o =C:\Users\YuriK\dev\work\conv2 -d --shared --vs=2015 -v .\Microsoft.Azure.Devices.Client.PCL.dll
Parsing assemblies...
    Parsed 'Microsoft.Azure.Devices.Client.PCL.dll'
Processing assemblies...

Unhandled Exception: System.OverflowException: Value was either too large or too small for a UInt64.
   at System.Convert.ToUInt64(Int32 value)
   at System.Int32.System.IConvertible.ToUInt64(IFormatProvider provider)
   at System.Convert.ToUInt64(Object value)
   at MonoEmbeddinator4000.Generators.ASTGenerator.VisitEnum(TypeInfo type) in C:\Users\YuriK\dev\work\Embeddinator-4000\binder\Generators\AstGenerator.cs:line 144
   at MonoEmbeddinator4000.Generators.ASTGenerator.Visit(TypeInfo typeInfo) in C:\Users\YuriK\dev\work\Embeddinator-4000\binder\Generators\AstGenerator.cs:line 91
   at MonoEmbeddinator4000.Generators.ASTGenerator.Visit(Assembly assembly) in C:\Users\YuriK\dev\work\Embeddinator-4000\binder\Generators\AstGenerator.cs:line 56
   at MonoEmbeddinator4000.Driver.Process() in C:\Users\YuriK\dev\work\Embeddinator-4000\binder\Driver.cs:line 76
   at MonoEmbeddinator4000.Driver.Run() in C:\Users\YuriK\dev\work\Embeddinator-4000\binder\Driver.cs:line 231
   at MonoEmbeddinator4000.CLI.Main(String[] args) in C:\Users\YuriK\dev\work\Embeddinator-4000\binder\CLI.cs:line 182

[objc] `IComparable` (and it's generic version) should map to `compare:`

E.g. IComparable<DateTime> should provide

- (NSComparisonResult)compare:(NSDate *)other;

Again it's important that a non-bound NSObject does not reach the mono runtime.

references:

This will remove warnings like:

warning EM1031: Method Int32 CompareTo(System.Object) is not generated because of parameter type System.Object is not supported.

compile dll complaining about main.c syntax error

PS C:\Users\cameron\fs\embeddinator-4000\tests\Basic> MonoEmbeddinator4000 --compile --dll bin\Release\ClassLibrary1.dll
Parsing assemblies...
    Parsed 'ClassLibrary1.dll'
Processing assemblies...
Generating binding code...
    Generated: ClassLibrary1.h
    Generated: ClassLibrary1.c
    Generated: glib.c
    Generated: glib.h
    Generated: main.c
    Generated: mono_embeddinator.c
    Generated: mono_embeddinator.h
Compiling binding code...
cl : Command line warning D9024 : unrecognized source file type 'C:\Users\cameron\fs\embeddinator-4000\tests\Basic\ClassLibrary1', object file assumed
        ClassLibrary1.c
        glib.c
        main.c
        C:\Users\cameron\fs\embeddinator-4000\tests\Basic\main.c(33): error C2059: syntax error: '}'
        mono_embeddinator.c
        Generating Code...

It is complaining about mono_m2n_context_t ctx = {}; in main.c below. I'm a little confused why main.c is even included. I'll look later. Time for dinner.

#include "mono_embeddinator.h"

int main()
{
  mono_m2n_context_t ctx = {};
  mono_m2n_init(&ctx, "mono_embeddinnator");

  /* YOUR CODE HERE */
  
  mono_m2n_destroy(&ctx);
}

Linux support?

I don't see explicit Linux support, the closest is Android.
So,what's the state of Linux platform?

[objc] Map managed extensions methods to categories

Surface to Go

When we are done with ObjC and Java, we should explore surfacing to Go.

Multiple indexed properties broken code

public class Collection
{
	Dictionary<string, double> c = new Dictionary<string, double> ();

	public void Add (string s, double item)
	{
		c.Add (s, item);
	}

	public void Remove (string s, double item)
	{
		c.Remove (s);
	}

	public int Count => c.Count;

	public double this[string key] {
		get { return c[key]; }
		set { c[key] = value; }
	}

	public double this[int i] {
		get { return c[i.ToString ()]; }
		set { c[i.ToString ()] = value; }
	}
}

In file included from ./bindings.m:1:
./bindings.h:25:1: error: duplicate declaration of method 'getItem:'

(double)getItem:(int) i;
^
./bindings.h:24:1: note: previous declaration is here

(double)getItem:(NSString *) key;
^
./bindings.h:28:1: error: duplicate declaration of method 'setItem:value:'

(void)setItem:(int) i value:(double) value;
^
./bindings.h:27:1: note: previous declaration is here

(void)setItem:(NSString *) key value:(double) value;
^
./bindings.m:146:1: error: duplicate declaration of method 'getItem:'

(double) getItem:(int) i
^
./bindings.m:124:1: note: previous declaration is here

(double) getItem:(NSString *) key
^
./bindings.m:210:1: error: duplicate declaration of method 'setItem:value:'

(void) setItem:(int) i value:(double) value
^
./bindings.m:189:1: note: previous declaration is here

(void) setItem:(NSString *) key value:(double) value
^
4 errors generated.

[objc] Make the headers comments compatible with appledoc

tool: https://github.com/tomaz/appledoc
guidance: http://nshipster.com/documentation/

That's for the generator's own output, e.g. why is a init marked with NS_UNAVAILABLE.

There's a separate, open issue #102 to copy/convert existing .NET (xml) documentation into the headers (and it should follow the same format/rules).

	id nonamespace = [ClassWithoutNamespace new];
	NSLog (@"%@", [nonamespace description]);

2017-03-25 14:26:14.864 a.out[65465:127801400] <ClassWithoutNamespace: 0x7fa7d5f004b0>

E.g. this crash

	id nestednamespaces = [[ClassWithoutNamespace init] alloc];
	NSLog (@"%@", [nonamespace description]);


2017-03-25 14:27:52.722 a.out[65606:127807396] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '*** +[ClassWithoutNamespace<0x10e516580> init]: cannot init a class object.'
*** First throw call stack:
(
	0   CoreFoundation                      0x00007fffd1e10e7b __exceptionPreprocess + 171
	1   libobjc.A.dylib                     0x00007fffe6a0bcad objc_exception_throw + 48
	2   CoreFoundation                      0x00007fffd1e92f2f +[NSObject(NSObject) init] + 127
	3   a.out                               0x000000010e50ee72 main + 130
	4   libdyld.dylib                       0x000000010e966255 start + 1
)
libc++abi.dylib: terminating with uncaught exception of type NSException
Stacktrace:


Native stacktrace:

	0   libmonosgen-2.0.1.dylib             0x000000010e5dfab6 mono_handle_native_crash + 278
	1   libsystem_platform.dylib            0x00007fffe74fcbba _sigtramp + 26
	2   ???                                 0x00000003f011f240 0x0 + 16912609856
	3   libsystem_c.dylib                   0x00007fffe7383420 abort + 129
	4   libc++abi.dylib                     0x00007fffe5ede85a __cxa_bad_cast + 0
	5   libc++abi.dylib                     0x00007fffe5f03c4f _ZL26default_unexpected_handlerv + 0
	6   libobjc.A.dylib                     0x00007fffe6a0df1e _ZL15_objc_terminatev + 103
	7   libc++abi.dylib                     0x00007fffe5f00d69 _ZSt11__terminatePFvvE + 8
	8   libc++abi.dylib                     0x00007fffe5f007de _ZN10__cxxabiv1L22exception_cleanup_funcE19_Unwind_Reason_CodeP17_Unwind_Exception + 0
	9   libobjc.A.dylib                     0x00007fffe6a0bdd6 objc_exception_throw + 345
	10  CoreFoundation                      0x00007fffd1e92f2f +[NSObject(NSObject) init] + 127
	11  a.out                               0x000000010e50ee72 main + 130
	12  libdyld.dylib                       0x000000010e966255 start + 1

Fixing this will require refactoring new logic into init.

Explore including LLVM optimized output

This might require some runtime changes.

Command line option for Visual Studio version

As the title says, add a --vs CLI option to set the wanted VS version for compilation.