Compiler / VS2005 vs. VS2008 (C# 2.0 vs. C# 3.5) / interop RRS feed

  • Question

  •  Hi there

     We found some issue we cannot explain and further more cannot fix.

     We build a C# library talking to a 3rd party server application which
     is offering an unmanaged API. We make massive use of COM Interop and
     for a long time everything worked fine. Since this application is
     32bit, the library and the application calling the lib is compiled
     with the x86 and not the AnyCPU Plattform flag

    After switching from Visual Studio 2005 to 2008 (and the newer
    compiler) the application refuses to work on Vista64. It works on some
    Vista32 machines, on others it doesn't. Using the compiler (csc.exe)
    directly without Visual Studio leads to the same result.


     I will collect a list of scenarios and the results:

     Compiling the lib using csc.exe 2.0 / running on XP or Vista - Working

     Compiling the lib using csc.exe 3.5 / running on XP - Working

     Compiling the lib using csc.exe 3.5 / running on Vista 32 - Working
     on some machines

     Compiling the lib using csc.exe 3.5 / running on Vista 64 - NOT Working



     Running Visual Studio 2008 on Vista 64 and debugging the lib inside
     VS 2008 - Working.

     The same but disabling the VS host process - NOT Working

     Using the same assembly but starting the exe - NOT Working on Vista
     64 (on the same machine)


     There must be some difference within the compilers. We tried to
     compile on different OS without any difference.

     On Vista we checked again with Administrator rights an UAC turned
     off. This posting seems to be something similar but turning DEP off
     on our test system doesn’t make any difference

     Can someone provide us with information about the difference of the
     C# compilers? Is there some hidden option and what’s going on on Vista?

    Saturday, January 10, 2009 1:01 PM

All replies

  • To clarify: under VS2005, was it working on Vista 64?

    If so, it sounds like the project upgrade may have not quite worked perfectly. I haven't done many project upgrades, so I can't speak authoritively, but I know others have had some problems.

    What exactly is the error you're getting?


    Saturday, January 10, 2009 1:08 PM
  • It is not a project upgrade problem.

    We can reproduce the problem with only using .cs files and the csc.exe (C# command line compiler). Our problem is not Visual Studio related since is the same when only using the compiler of the .net framework.

    there must be some difference between the two compilers!

    Benjamin (working with wolfram on this issue)
    Saturday, January 10, 2009 2:01 PM
  •  What exactly is the error you're getting?

    Saturday, January 10, 2009 5:24 PM
  •  There has been a thread recently on the same topic. An app refused to work on 64 bit. I am telling you this for a psychological confort only for you not to feel alone in Vista 64 bit universe. As far as I remember the issue in that thread was not resolved and was just dropped but I am not sure. If I am not mistaken JohnWein opined on the matter. He also commented on another somewhat related issue when I posted on the subject. I am moving to Vista Ultimate 64 bit in about one or two weeks. I feel rather nervous about it. You may try to query MSDN on the threads in question. I don't want to do it.

    From what I feel I've learned, which is not a lot, you will probably have to sort of redevelop your app. Look into all your COM's carefully. Perhaps you should write a test code to verify that you can access them individually, that all verbs are working, etc. You can also examine the objects in OleViewer.exe and in VS2008 Object Explorer. If you can simply open them, see the class, CLSID it will be a good sign, but you never know. My hunch is that one of them has a snafu that makes it not compatible with 64 bits in some configuration. I doubt there is a difference between the compilers. What is the reason for this difference to exist? They probably changed some overloads to make methods working in 64 bits on the level of basic types and their manipulation.

    Sunday, January 11, 2009 2:29 AM
  • There must be a difference between the compilers! Our problem is not only Vista 64 related but compiler related: Our smallest example to reproduce this problem works fine when compiled with the 2.0 compiler: It works fine on every Windows version we tested (XP, Vista, Vista64) but when changing only the compiler to v3.5 it stops working on Vista 64. It still works on all other versions of Windows.
    Our testcase does not involve Visual Studio in any version, we are using the compiler (csc.exe) directly. The os version used to compile our program does not make a difference: the resulting exe is not working on Vista 64.

    We would like to publish our problem code, but the problem occures when doing an interopt call to a 3rd party product. Without this 3rd party product you can not reproduce our example.

    We hope to find any (documented or undocumented) cange from version 2.0 to 3.5 of the compiler...
    Sunday, January 11, 2009 5:18 AM
  • Some more information:

    It works on some Vista32 systems.

    > What exactly is the error you're getting?

    That's a main part of our problem: We call a third-party native .dll (an api for some kind of database). It's ok documented, but something goes wrong deep inside that database when called from the 3.5-compiled tool.

    The vendor of that api tells "We do not support .NET, please send us your problem in C." Haha. But he is kind of right, because doing the same calls from C works fine...

    Since the .NET-Version compiled with 2.0 works fine as well, we think we did all the marshalling right. But still something makes the 3.5-complied version fail.

    We also read another thread on a similar problem, which was basically about DEP, editbin and as special flag. Of course we tried changing the flag but it's obviously not the cause of our problem.

    Sunday, January 11, 2009 8:17 AM
  • Hi!

    We finally found it!

    To cut it short: It had something to do wtih UAC and the /win32manifest - switch.
    On Vista a UAC-compatible process asks a virtualized process to fill and return pointers.
    UAC prevents this, which is right. (But unfortunatley Vista didn't tell uns anything about it interference)

    The long story can be found here: http://www.ticklishtechs.net/2009/02/03/mind-win32manifest-when-interop-ing/

    Thanks for trying to help us!

    Tuesday, February 3, 2009 8:22 PM