Binary portability of C++/CLI code

[Ioannis Vranos]

I compiled the hello world program, as specified in the current C++/CLI
draft (version 1.5), by using Visual C++ 2005 Express Beta 1:


int main()
{
System::Console::WriteLine("Hello World");
}


C:\c>cl /clr:safe temp.cpp
Microsoft (R) C/C++ Optimizing Compiler Version 14.00.40607.16
for Microsoft (R) .NET Framework version 2.00.40607.16
Copyright (C) Microsoft Corporation. All rights reserved.

temp.cpp
Microsoft (R) Incremental Linker Version 8.00.40607.16
Copyright (C) Microsoft Corporation. All rights reserved.

/out:temp.exe
temp.obj


==> The /clr:safe only produces an executable that passes peverify:



C:\c>peverify temp.exe /verbose

Microsoft (R) .NET Framework PE Verifier. Version 2.0.40607.16
Copyright (C) Microsoft Corporation. All rights reserved.

All Classes and Methods in temp.exe Verified.

C:\c>




Then wanting to test the binary portability of the produced executable,
I tried to run the produced executable as it is, in another CLI machine:



root@chrome cdrom]# mono temp.exe

** (temp.exe:1416): WARNING **: Could not find assembly
Microsoft.VisualC, references from /mnt/cdrom/temp.exe (assemblyref_index=1)
Major/Minor: 8,0
Build: 1200,0
Token: b03f5f7f11d50a3a

cannot open assembly temp.exe
[root@chrome cdrom]#




As it seems, MS introduces platform dependencies on the produced
executables, even for pure C++/CLI code.


How can I remove that useless assembly reference to "Microsoft.VisualC"?






Best regards,

Ioannis Vranos

 

[Willy Denoyette [MVP]]

Mono is miles behind what you see in VS2005 which is based on CLR version
2.0.
Your program won't run on .NET v1.0 and 1.1 either, it needs v2.0

Willy.

 

[Brandon Bray [MSFT]]

How can I remove that useless assembly reference to "Microsoft.VisualC"?

This is currently a bug in the Visual C++ compiler. We moved a number of
types from Microsoft.VisualC.dll into the frameworks assemblies (like
mscorlib.dll). Those types will need to be introduced on Mono to work, which
should be trivial.

The simple hello world example shouldn't need any changes to Mono... it's
just a bug in the VC compiler right now.

 

[Willy Denoyette [MVP]]

Brandon,

Are you sure about this, my understanding is that assemblies built with
VS2005 Beta1 (and later) could only run on a CLR v2.0 due to changes in the
metadata.
Is this only true for .NET and does'nt Mono check the CLR version required
when loading a managed assembly?
Am I missing something?

Willy.

 

[Ioannis Vranos]

Brandon,

Are you sure about this, my understanding is that assemblies built with
VS2005 Beta1 (and later) could only run on a CLR v2.0 due to changes in the
metadata.
Is this only true for .NET and does'nt Mono check the CLR version required
when loading a managed assembly?
Am I missing something?

I have successfully ran the C++/CLI hello world program produced by VC++
2005 Express Beta 1 under Mono 1, by including the Microsoft.VisualC.Dll
of .net 2 technical preview along with the exe(!).

However I prefer a more elegant approach.





[root@chrome cdrom]# ls
Microsoft.VisualC.Dll temp.exe temp.obj
[root@chrome cdrom]# mono temp.exe
Hello World
[root@chrome cdrom]#






Best regards,

Ioannis Vranos

 

[Brandon Bray [MSFT]]

Brandon,

Are you sure about this, my understanding is that assemblies built with
VS2005 Beta1 (and later) could only run on a CLR v2.0 due to changes in
the metadata.
Is this only true for .NET and does'nt Mono check the CLR version required
when loading a managed assembly?
Am I missing something?

You are correct that the metadata format was changed. The new format is
being adopted in the next version of the ECMA CLI standard. I would expect
Mono to work with that. While I'm not tracking the development of Mono, I'm
sure they've at least got something working with generics (the main reason
behind revising the metadata format).

All that said, we're expecting /clr:safe to have the same portability as the
Microsoft C# compiler.

 

[Ioannis Vranos]

This is currently a bug in the Visual C++ compiler. We moved a number of
types from Microsoft.VisualC.dll into the frameworks assemblies (like
mscorlib.dll). Those types will need to be introduced on Mono to work, which
should be trivial.

The simple hello world example shouldn't need any changes to Mono... it's
just a bug in the VC compiler right now.

Thank you for your reply. Could you tell me which types were moved from
Microsoft.VisualC.dll into the frameworks assemblies please?






Best regards,

Ioannis Vranos

 

[Tomas Restrepo \(MVP\)]

Hi Brandon,

This is currently a bug in the Visual C++ compiler. We moved a number of
types from Microsoft.VisualC.dll into the frameworks assemblies (like
mscorlib.dll).

Humm... was this post beta 1? At least on my copy, all the types in
Microsoft.VisualC.dll that were there in v1.1 are there on the beta1 bits...
plus a bunch new ones!

 

[Brandon Bray [MSFT]]

Thank you for your reply. Could you tell me which types were moved from
Microsoft.VisualC.dll into the frameworks assemblies please?

Here's everything I know. Things are subject to change (consider this likely
to happen). Currently, all types were moved to mscorlib.dll, and are in the
System.Runtime.CompilerServices namespace.

The following types were shipped in Everett, and the compiler now uses the
type in the CompilerServices namespace instead.

Everett Whidbey
------- -------
IsConstModifier IsConst
IsCXXPointerModifier IsExplicitlyDereferenced
IsCXXReferenceModifier IsImplicitlyDereferenced
IsLongModifier IsLong
IsVolatileModifier IsVolatile
NoSignSpecifiedModifier IsSignUnspecifiedByte

While the following types can be found in Microsoft.VisualC.dll, they will
be removed before we RTM. Microsoft.VisualC.dll will ship with exactly the
same types it shipped with in Everett. The compiler uses the new types from
the CompilerServices namespace instead.

Everett Whidbey
------- -------
CxxUdtReturnStyleModifier IsUdtReturn
IsBoxedModifier IsBoxed
IsIntrinsicModifier IsJitIntrinsic
IsMarshalWorkaround CompilerMarshalOverride
NativeEnumAttribute ScopelessEnumAttribute

This was not moved to mscorlib, but I believe it needs to be. As it is
rarely emitted, we can live with the compiler emitting a reference to
Microsoft.VisualC.dll for now. As soon as it is moved to mscorlib, the type
will be removed from Microsoft.VisualC.dll.

Everett Whidbey
------- -------
HFAAttribute

This needs to be removed from both mscorlib and Microsoft.VisualC.dll. The
implementation for marshalling doesn't need it.

Everett Whidbey
------- -------
HasCopySemanticsAttribute HasCopySemanticsAttribute

There is no matching type in Microsoft.VisualC.dll for these, and the
compiler is using them.

Everett Whidbey
------- -------
IsByValue
IsPinned

This type was never moved to mscorlib, and the compiler doesn't need it. As
it was put into Microsoft.VisualC.dll after Everett shipped, we will remove
it.

Everett Whidbey
------- -------
IsCopyCtorModifier

These I think are unnecessary. As they were shipped in Everett, the
Microsoft.VisualC.dll assembly will still have them, but the compiler should
stop using them entirely.

Everett Whidbey
------- -------
DebugInfoInPDBAttribute
DecoratedNameAttribute
IsSignedModifier
MiscellaneousBitsAttribute
NeedsCopyConstructorModifier

 

[Brandon Bray [MSFT]]

Humm... was this post beta 1? At least on my copy, all the types in
Microsoft.VisualC.dll that were there in v1.1 are there on the beta1
bits... plus a bunch new ones!

We created new types in mscorlib.dll before Beta 1, but the Beta 1 compiler
does not use them. Post Beta 1 compilers do use them.

There are a bunch of new types in Microsoft.VisualC.dll that we do not need
now that we are using types from mscorlib.dll. These should be removed from
the assembly such that when Whidbey ships, Microsoft.VisualC.dll looks
exactly the same as it did when Everett shipped.

We still need to ship Microsoft.VisualC.dll for a few reasons: (1) existing
programs built with the 7.0 and 7.1 compiler need it so they can move to a
newer version of the Frameworks. And, (2) the old syntax uses the older
modifiers in several cases. So, it is reasonable to expect the old syntax to
create dependencies on the Microsoft.VisualC.dll, but this should never
happen with the new syntax.

I hope that's what you wanted to know!