1

I am trying to change my Platform target for a C# application from x86 to Any CPU. My application uses a _click method which runs a new thread which opens a viewer window using the following method to show the window:

public void Show(string url, int entityId, string sessionId, int projId, string docId)
{
    base.Show();
    try
    {
        this.DocViewer.InitComm(url, entityId, sessionId, projId, docId);
    }
    catch (Exception ex)
    {
        Logger.Error("Error opening viewer", ex);
        throw;
    }
}

When running on the x86 platform, the application runs without issue. I changed the platform to "Any CPU" and receive a "COMException was unhandled" error: "Class not regisered (Exception from HRESULT: 0X80040154 (REGDB_E_CLASSNOTREG))" highlighting:

base.Show();

I have researched the cause of this error and it seems to be due to registry redirection. Because I am using .NET 3.5, I have been unable to use many of the solutions that I have found including one from this thread on SO. I am unclear on how the information here could be helpful as many of the links to the code are in C++.

If anyone could provide me with insight I would greatly appreciate it.

Community
  • 1
  • 1
DiggityCS
  • 111
  • 7
  • 6
    It's likely that the COM component does not register itself in the x64 registry because it does not work in x64. You need to make sure that the developers of the COM component actually support x64, and you have the 64-bit version of it actually installed. – vcsjones Jun 08 '15 at 20:24
  • 2
    What's `DocViewer`? If that's a native 32-bit component, you won't be able to load it into a 64-bit process, which is what gets created for an AnyCPU executable on a 64-bit platform. – xxbbcc Jun 08 '15 at 20:24
  • 1
    Exactly, it looks that simple - one can't simply use a 32-bit in-proc DLL in a 64-bit exe. Check out this also for example for workarounds: http://stackoverflow.com/questions/8660357/utilizing-a-32-bit-dll-in-a-64-bit-process-via-com – Nikolay Jun 08 '15 at 20:33

1 Answers1

4

This is an entirely normal mishap. Clearly you have a dependency on a COM server and they care a great deal about whether your program runs in 32-bit or 64-bit mode. COM servers are written in native code, usually C++, and a different flavor of native code is required in 64-bit mode.

You can only count on having a 64-bit version of such a COM server if it is part of Windows and not too old. But the vast majority of them are 3rd party products and only available as a 32-bit version. If it is your own then you'll have to build the x64 version of it, if it is a 3rd party then you'll have to use a telephone. We can't help you locate the number. If you need a hint then look through your project's assembly references and look at the Properties of the file, decent odds you'll see the vendor name in the Copyright notice.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • Thank you very much! Because this was a 3rd party product, and only available in 32-bit, it was decided that x86 needed to be used as the platform target. Although this solution isn't ideal, I am provided with an answer as well as a reason why. +1 – DiggityCS Jun 09 '15 at 17:09