Unfortunately there's no trivial way to map this. If you follow that rule, you're broken on 64bit windows systems (if you care about cross platform compatibility). There may be other systems which won't work with that rule, but I don't know.
One approach is to create a wrapper C library which you P/Invoke instead of P/Invoking the actual library you want to use. The wrapper library can expose exactly the same API, but it can change usages of 'long' to either int32_t or int64_t as appropriate so that other languages (not just .NET ones) can easily call those functions. If you don't want to do that, there's really very little - if anything - you can do other than guess and write multiple P/Invokes for each case. For example you could write two p/invoke signatues, one which maps a C long to a .NET int and one which maps it to a .NET long. Then at runtime you can detect what platform you're on and whether it's 64bit or 32bit and then make a guess as to which function will not blow up when you call it. This isn't a great approach unless you're positive you know all the platforms you're going to run on ;) Alan. On Thu, Mar 25, 2010 at 9:17 AM, Mathias Tausig <mathias.tau...@a-cert.at> wrote: > Hello! > > I am writing a wrapper for a c library which uses the c datatype > "unsigned long" a lot. According to > http://www.mono-project.com/Interop_with_Native_Libraries , unsigned > long maps to the .NET type uint on a 32bit architecture and to ulong on > a 64-bit one. > Is there some sort of best practice, for achieving to write a library > which can work on both architectures? > > cheers > Mathias > _______________________________________________ > Mono-list maillist - mono-l...@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-list > _______________________________________________ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list