[Mono-devel-list] csc build and SecurityPermissionAttributeproblem on cygwin

Ben Maurer 05mauben at hawken.edu
Tue Feb 24 08:04:05 EST 2004

I don't quite understand why we cant just work around the *problem*, not just hide it by using mcs. If we cant build corlib with csc, we are loosing a major source of testing for MCS.

Remember, Microsoft builds their corlib with csc. So there is no reason we cant build our with their csc.

Not having csc able to compile corlib could lead to problems in another area. For example, when Martin adds generics, we will use some if that stuff in the Generics corlib. If there is a design problem or major breakage that requires that we compile on the v2 csc, we need to be able to do that.

Also, remember alot of mcs bugs are caught because people patching the classlibs on Linux do something illegal that MCS does not catch.

-- Ben

>>> Miguel de Icaza <miguel at ximian.com> 02/23/04 21:24 PM >>>

> Is there any problem around using mcs to build mcs on cygwin, like
> we have been doing on Linux? Currently the cygwin build uses csc by
> default, but it introduces a problem that we can never use
> SecurityPermissionAttribute. So I would suggest that we had better
> use mcs instead of csc.

MCS has problems on Windows when using the Windows runtime, since their
Reflection.Emit crashes in a few places and has a few limitations that
we have worked around on Mono's runtime.

So if we are to use MCS on Windows, we must use it with the Mono

I am ok with doing the switch, but I would like to keep a csc-based
compilation profile active, to be able to sanity check our code and to
make sure we do not introduce a dependency in the source code on an mcs
bug inadvertently.

Mono-devel-list mailing list
Mono-devel-list at lists.ximian.com

More information about the Mono-devel-list mailing list