4

I'm building an Outlook add-in that runs on a 64-bit OS with a 64-bit Outlook.

However, I'm unable to get the right pointer size in order to trigger the RedemptionLoader code to load the 64-bit DLL file... It always gave me a pointer size of 4.

I've read the following and also followed their suggestions, but no go...

Why is 'IntPtr.size' 4 on Windows 64 bit?

IntPtr on a 32-bit OS and UInt64 on a 64-bit OS

So in my project, a C# project in Visual Studio 2015, I've set it to Any CPU, and then in my 64 bit WiX Setup project, I've made sure that it has the x64 as the $(Platform). Like so,

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|x64' ">

When I try to load my add-in and dump out the pointer size "Pointer size? " + IntPtr.Size, it just prints 4 instead of the 8 that I'm expecting...

What else am I missing...?

Windows 10 64 bit

Office 365, Outlook 64 bit

Both OS and Outlook are 64 bit:

Enter image description here

Even during the installation of the add-in, Add-in Express detected and installed as the 64-bit version without throwing out any error...

Add-in Express Registrator Log File: 01/11/2017 15:36:47

Installation directory: C:\WINDOWS\Installer\
Registrator version: 8.4.4395.0
Operating System: Microsoft Windows 10 Professional (build 14393), 64-bit
Process Owner: System
Command Line: "C:\WINDOWS\Installer\MSI5FB0.tmp" /install="C:\Program Files\Blah\Blah.dll" /log=%RoamingAppDataFolder%/Blah
Run 'As Administrator': Yes
Process Elevated: Yes
Integrity Level: System
UAC (User Account Control): On
--------------------------------------------------------------
15:36:47 0448 Starting the add-in registration process.
15:36:47 0448 Loading mscoree.dll
15:36:47 0448 Success.
15:36:47 0448 .NET Framework installation directory:
15:36:47 0448 The latest version of .NET Framework: 'v4.0.30319'
15:36:47 0448 Loading CLR: v4.0.30319.
15:36:47 0448 Calling CLRCreateInstance method.
15:36:47 0448 Success.
15:36:47 0448 Calling GetRuntime method.
15:36:47 0448 Success.
15:36:47 0448 Checking if the hosting API of .NET Framework v4.0 beta is installed.
15:36:47 0448 The hosting API is up to date.
15:36:47 0448 Calling GetInterface method for the CorRuntimeHost interface.
15:36:47 0448 Success.
15:36:47 0448 Starting CLR...
15:36:47 0448 Success.
15:36:47 0448 Getting the CLR version.
15:36:47 0448 The CLR v4.0.30319 has been initialized successfully.
15:36:47 0448 Creating a new domain setup.
15:36:47 0448 Success.
15:36:47 0448 The 'shadow copy' is disabled.
15:36:47 0448 Creating a new application domain.
15:36:47 0448 Success.
15:36:47 0448 Getting the base directory for the domain.
15:36:47 0448 Success. The directory is 'C:\Program Files\Blah\'.
15:36:47 0448 Searching for the Add-in Express core library.
15:36:47 0448 Success. The 'AddinExpress.MSO.2005.dll' file is found.
15:36:47 0448 Creating an instance of the 'AddinExpress.Deployment.ADXRegistrator' class.
15:36:47 0448 Assembly identity is 'AddinExpress.MSO.2005'.
15:36:47 0448 Success.
15:36:47 0448 Unwrapping the instance of the 'AddinExpress.Deployment.ADXRegistrator' class.
15:36:47 0448 Success.
15:36:47 0448 Calling the managed registration procedure (DISPID = 1610743823).
15:36:48 0448 Registration success.
15:36:48 0448 The add-in registration process is completed with HRESULT = 0.
Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
codenamezero
  • 2,724
  • 29
  • 64

1 Answers1

0

If it is 4, you can be sure the process is 32 bit. Compiling as "Any CPU" will match the bitness of the host app (Outlook), not the host OS.

Does Outlook actually say it is 64 bit?

Dmitry Streblechenko
  • 62,942
  • 4
  • 53
  • 78
  • Yes... It says 64bit, I really run out of idea on why it prints 4. The machine where I build the add-in has 32 bit Outlook install, but I don't think that would matter on the destination machine? – codenamezero Jan 11 '17 at 20:26
  • Are you using VSTO hosting process when debugging? – Dmitry Streblechenko Jan 11 '17 at 20:27
  • I do see that option in the property, Debug > Enable Debuggers > "Enable the Visual Studio hosting process" and that box is checked. Is that the one you are talking about? I've unchecked that box and rebuilt the solution, still the same... – codenamezero Jan 11 '17 at 20:42
  • What happens if you explicitly target x64? – Dmitry Streblechenko Jan 11 '17 at 21:08
  • I've completely create a brand new Installer Project, and rebuild and repackaged the whole thing, installed it, everything ran fine, your Redemption even loads its proper 64bit dll, it is only during uninstall process that it tries to load the 32 bit one (due to pointer size being 4) this is completely mind=blown... – codenamezero Jan 11 '17 at 23:13
  • Ah! So it is only for the installer? Why are you trying to do anything Redemption or Outlook related during the uninstall? What loads your dll? msi.exe? – Dmitry Streblechenko Jan 11 '17 at 23:52
  • It is a `msi.exe`, I start a RDOSession inside the AddinModules' `UninstallControls()`. Regardless of what I need to do in the uninstall, the behaviour of 32 or 64 bit should remain the same, don't you agree? – codenamezero Jan 12 '17 at 14:41
  • No, not at all - msi.exe most likely runs as a 32 bit app. It is a really bad idea to do anything MAPI specific in an installer. Do not do that. – Dmitry Streblechenko Jan 13 '17 at 13:37
  • I did no do anything specific inside the MSI installer, but rather I was simply calling Redemption from `UninstallControls` from Add-In Express. I think this is a bug in Redemption, the fact that during uninstall, all the Add-In Express stuff loaded its 64bit dll correctly, but Redemption did not. – codenamezero Jan 13 '17 at 15:21
  • 1
    Redemption cannot possibly change the bitness of its parent process - if the parent process is 32 bit, Redemption will behave like a 32 bit dll. A 32 bit process cannot possibly load a 64 bit dll (redemption64.dll). There is nothing you can do about that. But the question still stands - why do you need to load Redemption in your installer? – Dmitry Streblechenko Jan 13 '17 at 17:20