Thanks for the reply.
Comments inline...
On Wed, 18 Sep 2002 15:29:40 -0700, John Norwood <[EMAIL PROTECTED]>
wrote:
>>The interesting part is that if I just remove /unsafe+ from the command
>line above, the code
>>compiles fine. I just don't see what the relationship is between
>generating unsafe code and
>>the search path for compilation.
>
>The first place I would have thought to look would be yet another
>command interpreter issue but I don't see anything obvious. I'm
>surprised you haven't hit more command interpeter issues since the batch
>files are pretty dependent on Win2K behavior.
Actually I have. I just didn't complain about them :-). Nothing major
though. Mostly "exit /B {0|1}" at the end of batch subprograms.
>
>It looks like you've whittled the response file down quite a bit so it
>probably isn't something simple like a truncated command-line and I
>can't see how that would cause this error.
>
You are right. Everything does point to the compiler.
>The /unsafe+ option does exercise a lot more code in the C# compiler so
>it's possible that some PAL/API call is being made that has different
>results under NT4. You might need to run C# under a debugger during the
>build of this directory to see where the error is originating and what
>it really is.
>
>There doesn't appear to be a reason to have /unsafe switched on for
>isymmanagedwrapper. You could turn it off in the sources file by
>removing the line: CSHARP_ALLOW_UNSAFE=1. It would be a good idea to
>check for the effects of this by running the full test suite.
>
I'll try all that when I get some time. Thanks for the suggestions.
>Your example did help me spot the fact that we seem to be adding
>mscorlib as a reference twice in the response file which is a bug.
>
>John
Well, at least there's *some* benefit out of all this ;-)
>
>
>This posting is provided "AS IS" with no warranties, and confers no
>rights.
Thanks
Cristian
