5

I'm not a skilled Windows programmer, but I created and have been maintaining an XLL add-in for 32-bit Windows XP / Excel for many years. I'd now like to create a Windows 7/64 bit version and am having trouble - I can't even get the Generic.xll example to work.

Here's the simpliest version of what I've done - sorry this is long and pedantic.

On my Windows XP/32 machine, where I have Visual Studio 2010 Professional installed:

  • Downloaded & installed the Microsoft Excel 2013 SDK.

  • Start Menu - "Open Visual Studio x64 Cross Tools Command Prompt (2010)"

  • SET TYPE=RELEASE

  • SET PLATFORM=x64 // I think this was preset anyway

  • cd C:\2013 Office System Developer Resources\Excel2013XLLSDK\SAMPLES\FRAMEWRK

  • nmake // no errors

  • cd C:\2013 Office System Developer Resources\Excel2013XLLSDK\SAMPLES\GENERIC

  • nmake // no errors

  • copy the resulting C:\2013 Office System Developer Resources\Excel2013XLLSDK\SAMPLES\GENERIC\x64\RELEASE\GENERIC.xll to a network folder accessible by the Windows 7/64 computer

On Windows 7/64 computer:

  • Start Excel 2013

  • File - Options - Add-ins - Manage Excel Add-ins - Browse, go to the network folder containing Generic.xll, click it.

  • Allow Excel to copy Generic.xll to the standard folder. It loads silently, no messages (including no message saying it loaded Generic.xll)

  • No functionality from Generic.xll appears.

  • Close and reopen Excel - upon reopening, I get a message box saying "The file format and extension of 'GENERIC.xll' don't match. The file could be corrupted or unsafe..." (If I say "Yes" it loads it like a text file, showing me binary code in the XLL in the spreadsheet.)

Based on previous (Windows XP/32) XLL experience, this message can mean almost anything - including a lack of required DLLs. So,

On Windows 7/64 computer:

  • Install Microsoft Visual C++ 2010 x64 Redistributable - 10.0.30319. No impact.

  • Install Microsoft Visual C++ 2012 Redistributable (x64) - 11.0.51106. No impact.

  • Run "Dependency Walker for Win64(x64) Version 2.2.600, Developed by Steve P. Miller"

  • File - Open - Generic.xll

  • It shows it can't find:
    -- XLCALL32.DLL // Typical from my Windows XP experience on working XLLs
    -- API-MS-WIN-CORE-COM-L1-1-0.DLL
    -- API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.DLL
    -- API-MS-WIN-CORE-WINRT-L1-1-0.DLL
    -- API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL
    -- API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL
    -- API-MS-WIN-SHCORE-SCALING-L1-1-0.DLL
    -- DCOMP.DLL
    -- IESHIMS.DLL // Typical from my Windows XP experience on working XLLs

So, now I'm stumped. I thought I had a 64-bit problem, but I'm beginning to wonder if I have a Windows 7 problem.

Help?

Thanks,

Tim

micstr
  • 5,080
  • 8
  • 48
  • 76
user2326756
  • 51
  • 1
  • 5

2 Answers2

3

Sounds like you know a few things about this. XLCALL32 and IESHIMS in depends are not your problem.

My guess is that it is a 64-bit issue. I finally managed to get 64-bit builds working with http://xll.codeplex.com. Maybe you can find something there that you will find useful.

Keith A. Lewis
  • 761
  • 4
  • 7
1

Watch out for the XLL load process. It's not the simple DLL load that we expect when we're writing code to be loaded by a normal process.

If you have a test program that runs perfectly - but then you add the working code to your Excel Add-in and get the "This file could be corrupted or unsafe" message... I suggest you:

  • check your initialization code for calls that Excel does not allow during the load process.

If, during initialization, your code executes a call that Excel doesn't like you will get the meaningless error message and your add-in will be re-loaded as a text document. Unfortunately I haven't done my homework on the details regarding the restrictions imposed by Excel; in general, though, I've found that:

  • The problem can be solved, very simply, by delaying the initialization.

So far I've found the AutoOpen event has been handy (though there may be a better way - let me know if you find one.) I've used the following concept successfully to avoid this problem:

// within the AutoLoad event handler
static bool init_completed = false;
if ( init_completed == false )
{
   initialize_all();    
   init_completed = true;
}

This allows Excel to load the XLL successfully. By the time the AutoLoad event is called it seems that Excel does not impose any restrictions on the code - allowing the initialization code to execute.

Again, though, the AutoLoad event might not be the best place - YMMV - so please update this page if you find something better.

I seriously hope I find this page quickly next time I make this mistake!

Sam Azer
  • 186
  • 3