Thought I'd close on that /unsafe+ problem... When using /unsafe+, the cs.exe compiler calls EEStartup(DWORD fFlags) in ceemain.cpp. I don't know why the same sequence doesn't happen when /unsafe+ is not used, but it doesn't really matter.
>From EEStartup() the sequence is as follows: EEStartup() -> static HRESULT InitializeIPCManager(void) -> IPCWriterInterface::CreatePrivateBlockOnPid(DWORD pid, BOOL inService, HINSTANCE *phInstIPCBlockOwner) -> PAL_CreateFileMappingW( ... ) -> CreateFileMappingW( ... lpObjectName ); The problem is the value of lpObjectName which is "Global\RotorefjnlhjmdlgchclbchlnabekeinilkebjhbhfpalRotor_Private_IPCBl ock_394" (after hashing). The issue is that CreateFileMappingW(...) on NT does not support backslash in the object name (I think this is new for w2k.) So, there you have it... I didn't have time to check whether there are any other issues with NT, but the build seems to have moved pretty far already. Cristian 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. > >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. > >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. > >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 > > >This posting is provided "AS IS" with no warranties, and confers no >rights.