The first suggestion is out-of-question, for a library distributed with Mono.
The second one is unadvisable, but sometimes we already did that to be
able to make your compilers work (indeed they have some problems when
running them on MS.NET).
:)
On 7/2/05, Robert Jordan [EMAIL PROTECTED] wrote:
Alexandre,
My question is simple, can we do something on a MS controlled namespace
that is not part of the default implementation? Of course raising a mcs
warning telling something like This method will make your app not to
run on MS.NET.
This comes from a desire to introduce something in CodeDom, for instance
for a Method I wish it to be able to contain more info than the default
like SourceCodeLocation (line/column).
What do you advice, to create a fork and keep patching it to stay sync
with mono tree or use what I proposed?
If you just want to warn the consumer of the changed library about
the incompatibility: misuse the ObsoleteAttribute:
[Obsolete(THIS METHOD DOESN'T WORK ON MSFT'S RUNTIME!)
public void FooMethod()
If you want to build code that will run on both runtimes,
then never change the public interface. Introduce new members
only as internal. Those menbers can be accessed using reflection.
Rob
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
--
Rafael Monoman Teixeira
---
I'm trying to become a Rosh Gadol before my own eyes.
See http://www.joelonsoftware.com/items/2004/12/06.html for enlightment.
It hurts!
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
