none
Side-by-side execution fails on Windows 7 x64 RRS feed

  • Question

  • I have a .NET application that loads ActiveX controls side-by-side and works correctly on Windows XP SP3 x86. 

    The application is compiled as a 32 bit application.  When I run the application on Windows 7 x64, instead of loading the side-by-side ActiveX controls, it is picking up the ActiveX controls from the registered location. 

    The native applications in my distribution do not have this problem; only the .NET applications.

    Any ideas why this happening?

    Thanks,

    Bill

    Friday, November 18, 2011 3:16 PM

Answers

  • One of my developers just came to me with a solution to this problem which requires an entry into the registry of the Windows 7 computer:

     

    Windows Registry Editor Version 5.00

     

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SideBySide]

    "PreferExternalManifest"=dword:00000001

     

    This is the difference in behavior between Windows 7 and Windows XP…in Windows XP the external manifest is the default, in Windows 7 you have to force it by making the above entry in the manifest.

     

    The reason the native applications did not have a problem is because the project properties of native applications in Visual Studio have the ability to embed and edit the internal manifest, but no similar functionality exists in the project properties of .NET applications.  Because of this Visual Studio inconsistency in the handling application properties, all of our native applications have internal manifests and all of our .NET applications have external manifests.

    • Marked as answer by Bill Block Monday, November 28, 2011 5:46 PM
    Monday, November 28, 2011 5:46 PM

All replies

  • Have you double checked in the configuration manager for your "Win32" Solution configuration that each of the platform configurations for the CLR projects is not set to "Any CPU"?

     

    Friday, November 18, 2011 4:05 PM
  • Hi Bill,

     

    As far as I know, the registered position in 64-bit system is different from 32-bit system. Therefore, if you did not change any codes in your 32-bit application it will get some problem.

     

    For more information, you can see this thread:

    problems registering a 32 bit activeX dll and library file on a windows 7 OS (64 bit) using regsvr32.exe

     

    I hope these information can help you to solve this problem.

     

    Best regards,

    Jesse


    Jesse Jiang [MSFT]
    MSDN Community Support | Feedback to us
    Monday, November 21, 2011 3:10 AM
    Moderator
  • I think you should also check manifest of your application. You might need manifest modification. I think registry location is different in case of 64 bit as stated by jese jiang above.

     

    I hope it might help you. I think if you have manifest sharing it is an good idea if problem still there

     

    Regards,

    Fahd Anwar


    Regards, Fahd Anwar
    Monday, November 21, 2011 6:13 AM
  • I appreciate all of the responses.

    I define the manifests the same for .NET and native applications.  The native application run fine on Windows 7 x64; the .NET application do not run.

    Tuesday, November 22, 2011 5:20 PM
  • The whole point of the side-by-side execution is so that you do not need to register the components. 

    We typically do an "xcopy" install onto the target machines without any registration.

    Tuesday, November 22, 2011 5:22 PM
  • The only CLR part is the host application and its target platform is set to x86. 

    All of the components are native ActiveX controls.

    Tuesday, November 22, 2011 5:27 PM
  • Hello,

     

    I think it caused by the manifest setting was incorrect. I would suggest you to follow this blog to analyze this issue:

    Diagnosing SideBySide failures

     

    Best regards,

    Jesse


    Jesse Jiang [MSFT]
    MSDN Community Support | Feedback to us
    Wednesday, November 23, 2011 3:06 AM
    Moderator
  • One of my developers just came to me with a solution to this problem which requires an entry into the registry of the Windows 7 computer:

     

    Windows Registry Editor Version 5.00

     

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SideBySide]

    "PreferExternalManifest"=dword:00000001

     

    This is the difference in behavior between Windows 7 and Windows XP…in Windows XP the external manifest is the default, in Windows 7 you have to force it by making the above entry in the manifest.

     

    The reason the native applications did not have a problem is because the project properties of native applications in Visual Studio have the ability to embed and edit the internal manifest, but no similar functionality exists in the project properties of .NET applications.  Because of this Visual Studio inconsistency in the handling application properties, all of our native applications have internal manifests and all of our .NET applications have external manifests.

    • Marked as answer by Bill Block Monday, November 28, 2011 5:46 PM
    Monday, November 28, 2011 5:46 PM
  • Hi Bill,

     

    Thanks for sharing the solution. I believe someone will get help from your answer.

     

    Best regards,

    Jesse


    Jesse Jiang [MSFT]
    MSDN Community Support | Feedback to us
    Tuesday, November 29, 2011 2:08 AM
    Moderator
  • Thats not a good solution though.

    What if some other application has a different assumption? Altering system wide defaults to support a single application is not a sustainable solution.

    Now the problem is identified - redundant manifests - it would surely be better to inhibit (via the linker settings) the internal manifests entirely so that the external manifests are always used regardless of the system defaults.

     

     

    Tuesday, November 29, 2011 7:13 AM
  • i think if you remove internal manifest or embed your own manifest instead of original like i normally do in post build step like

    mt.exe app manifest;1

    you can check exact argument of mt.exe

     

     

    Regards,

    fahd Anwar


    Regards, Fahd Anwar
    Wednesday, November 30, 2011 5:20 AM