This project has moved and is read-only. For the latest updates, please go here.


File format and extension don't match: Excel 2013


I am trying to follow the "Getting Started with Excel-DNA" procedure and every time I open the Test1.xll file I get an error "File format and extension don't match". I have the option to proceed; however, when I do the worksheet just populates with random characters. I have attached a screenshot to show what is happening.

I am using Excel 2013 with Windows 7. I have the .NET 3.5.1 runtime installed and I have macro security set as low as it will go.
Closed Sep 5, 2013 at 9:11 PM by govert
I'm not sure how to trace this further. Apart from the 64-bit case, I don't know of other cases where this problem has occurred.


govert wrote Jul 18, 2013 at 10:53 AM

You probably have the 64-bit version of Excel installed, and need to open the ExcelDna64.xll instead. (Or copy ExcelDna64.xll to Test1.xll).

You can check your Excel version by going to File->Account, Click 'About Excel' and look at the first line.

nickvise wrote Jul 18, 2013 at 12:23 PM

It says I have the 32-bit version of Excel on that about page. Either way, when I try to open either version of the ExcelDna.xll file I get the same result. Anything else I can check? I am really excited to use this tool.

govert wrote Jul 18, 2013 at 12:48 PM

Some more things you can check:
  1. Are you using the current release version of Excel-DNA (version 0.30)?
  2. Can you try to load the ExcelDna.xll sample in the Distribution folder (either double-click on it, or File->Open)?
  3. Is VBA installed in your Excel (check by just pressing Alt+F11 and verifying that the VBA IDE is displayed)?
  4. Do you have an unusual anti-virus program installed?

andyhasit wrote Oct 6, 2014 at 11:45 AM

Hi, it could be that the machine cannot find some of the dll files referenced by the xll (in the background it references quite a lot of them). People tend to encounter this problem at the point of deploying their xll on another machine even though it worked fine on the development machine (which probably had visual studio installed at some point which made sure all these dlls were present/accessible in path).

Try using Dependency Walker which shows you the dlls it cannot find and take it from there.

For info: