Geek Answers Handbook

Creating an XLL Excel add-in for Windows 7/64 bit (cross-compilation in Windows XP / 32)

I am not a qualified Windows programmer, but I have created and maintained the XLL add-in for 32-bit Windows XP / Excel for many years. Now I would like to create a version for Windows 7/64, and I'm having problems - I can’t even get the Generic.xll example to work.

Here is the simplest version of what I did - it’s a pity that it is long and pedantic.

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

  • Download and install the Microsoft Excel 2013 SDK.

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

  • SET TYPE = RELEASE

  • SET PLATFORM = x64 // I think it was pre-configured

  • 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 products for Office \ Excel2013XLLSDK \ SAMPLES \ GENERIC \ x64 \ RELEASE \ GENERIC.xll received in C: \ 2013 to the network folder available on the Windows 7/64 computer.

On a Windows 7/64 computer:

  • Launch Excel 2013

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

  • Allow Excel to copy the Generic.xll file to the standard folder. It loads silently, no messages (including no message that it has been downloaded by Generic.xll)

  • No features from Generic.xll appear.

  • Close and reopen Excel - after reopening I get a window with the message "The file format and the extension" GENERIC.xll do not match. The file may be damaged or unsafe ... "(if I say" Yes ", it loads it as text file showing me the binary in xll in a spreadsheet.)

Based on the previous (Windows XP / 32) XLL experience, this message can mean almost everything, including the lack of necessary DLLs. In this way,

On a Windows 7/64 computer:

  • Install Microsoft Visual C ++ 2010 x64 Redistributable - 10.0.30319. Does not affect.

  • Install the Microsoft Visual C ++ 2012 Redistributable (x64) - 11.0.51106. Does not affect.

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

  • File - Open - Generic.xll

  • He shows that he cannot find:
    - XLCALL32.DLL // Typically from my experience with Windows XP in 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 // Typically from my experience with Windows XP when working with XLL

So now I'm at a standstill. I thought I had a 64-bit problem, but I'm starting to wonder if I have a problem with Windows 7.

reference

Thanks,

Tim

+4
source share
2 answers

It sounds like you know something about this. XLCALL32 and IESHIMS depend on your problem.

I assume this is a 64-bit issue. Finally, I managed to get 64-bit builds working with http://xll.codeplex.com . Perhaps you can find something there that you find useful.

+1
source

Follow the XLL boot process. This is not a simple DLL loading that we expect when we write code loaded by a regular process.

If you have a test program that works fine, but then you add the working code to the Excel add-in and get the message "This file may be damaged or dangerous" ... I suggest you:

  • Check the initialization code for calls that Excel does not allow during the download process.

If during initialization, your code makes a call that Excel does not like, you will receive a meaningless error message, and your add-in will be reloaded as a text document. Unfortunately, I did not do my homework regarding the restrictions imposed by Excel; In general, I found that:

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

So far, I have found that the AutoOpen event was convenient (although there may be a better way - let me know if you find it.) I have successfully used the following concept 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 successfully load XLL. By the time the AutoLoad event occurs, it seems that Excel does not impose any restrictions on the code, allowing you to execute the initialization code.

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

I really hope that I will quickly find this page the next time I make this mistake!

0
source

More articles:


All Articles