But compiling an assembly using mcs.exe does not guarantee that it runs on the Mono runtime, because mcs.exe will link the .NET Framework assemblies. This can cause a compiled assembly to work on the .NET Framework runtime, but not on the Mono runtime. You're actually saying that you should not compile assemblies that target Mono when Nant is running in the .NET Framework 1.0 ?
I'm not saying that at all. I'm saying that mcs.exe *should* behave in exactly the same manner when it is run against the .Net runtime as when its run against the mono runtime. I was a little surprised to see that it uses the runtime its running against to resolve assembly references at compile time. You can get around this be explicitly referencing the assemblies from the mono\lib directory and you will get the same result whether you use 'mcs.exe' or 'mono mcs.exe'. However given the way mcs resolves references, running it via mono mcs.exe is the better way to go.
I do understand, and it is possible with mcs if you fully qualify all assembly references.I hope you understand that there's a need to use Nant to build assemblies for multiple runtimes in one go, as I am doing now. So it's perfectly possible, but just not with Mono right now.
I wasn't even remotely suggesting that you should. What I was talking about are multiple commandline tools that are managed exes. So for example mcs.exe and monoresgen.exe are both implemented as managed exes. So when you come to run the <csc> and <resgen> tasks that they map to you need to ensure that they are both launched using the mono ....exe syntax. With our current framework external tools are just launched based on the executable name. To handle launching managed apps against the mono runtime we would need to first determine whether an .exe was managed or not in order to decide if the launch command should be 'foo.exe' or 'mono foo.exe' - since mono foo.exe will obviously fail if foo.exe is umnanaged.No definitely not, what I want is to have one buildfile that builds our assembly for the following runtimes :
- .NET 1.0 - .NET 1.1 - .NET Compact Framework 1.0 - Mono
So I definitely do not want to use the Mono mcs compiler to compile our assembly for the .NET Framework 1.1 !
With any luck this may soon be a moot point. The reason mcs.exe is loaded by the ms runtime is beacuse it has a small unmanaged stub that binds to mscoree.dll and runs _corExeMain() which will boostrap a runtime. It will go with the first mscoree.dll that it finds in the path and right now the only one is microsofts. There is talk on the mono list of implementing their own version of mscoree.dll so that running as mcs.exe just works as it should - ie loads mono or another runtime specified in a config file. See http://archive.neotonic.com/archive/mono-list/messages/10537?noheader=1 and related posts.
I don't know how far along they are with this though. I'd like to see where its at before we add support for the 'mono mcs.exe' commandline format.
Ian
------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
