[Mono-list] Running vs2005 beta 2 compiled code on mono...

Kornél Pál kornelpal at hotmail.com
Fri Jul 1 19:12:24 EDT 2005

> From: Alex Mohr
> No -- that's what I get if I try to run C++ code compiled with VS2003 on
> the mac, and that's what I expect since there's no /clr:pure flag in
> 2003.
> ...

I have tried /clr:pure. If seems to be promising but I don't recommend using
it. Just look at the resulting exe file using ildasm. It's full of imported
functions from CRT. /clr:pure only means that you cannot declare unmanaged
code but you can use it inline without P/Invoke.

So the resulting code is still not entirely managed.

Use /clr:safe instead. You have to be able to run it on Mono. It does not
allow unmanaged code to be referenced and the assembly will be pure
verifiable IL.

And I advice you to install Mono on the same Windows box you develop
applications because behaviour of Mono is very similar on Windows and other
operating systems so you can test it after each build. Of course if you want
to ensure Mac compatibility you have to test it on Mac as well.

> From: A Rafael D Teixeira
> A /clr:pure program uses only managed code, and that is good but it:
> 1) Expects a very different mscorlib 2.0. So at least you need to run
> the mono 2.0-compatible preview version, and I'm not sure all the needed
> implementations are in place.
> 2) It still has some dependency on a specific runtime library
> Microsoft.VisualC.dll. That I'm quite sure we doesn't have much of it
> implemented as needed for both profiles (1.X, 2.0).

None of them is correct.

/clr:pure assumes a different runtime (in fact a runtime with more features)
because the resulting assembly may contain (and actually contains a lot of
CRT references) inline references to unmanaged code and unverifiable
(unsafe) code. It uses mscorlib just as you use it in your own code so it
does not assume any special mscorlib features.

Microsoft.VisualC.dll contains no code at all. It contains some dummy
attributes to make C++ compiler for example able to distinguish between long
and int. Both long and int are Int32 in managed code and an attribute
specifies the C++ data type. This may be useful in overload matching. This
assembly is completly implemented by Mono.

But all of these attributes (the assembly contains nothing else) are marked
as obsolete because MS realized that these attributes are dummy and I think
the assembly will be removed in 2.0 RTM.

> Sure it looks like our runtime is having trouble to load a class
> definition. It probably is a bug or some assumption that doesn't hold
> for 2.0, please file a bug at http://bugzilla.ximian.com/enter_bug.cgi?
> product=Mono%3A%20Runtime starting the description with "[2.0] ..."

I'm not sure whether we want to support assemblies generated by C++ compiler
using /clr:pure as they are platform and processor dependent but feel free
to submit a bug report if you want.


More information about the Mono-list mailing list