search

xlladdins / xll

Excel add-in library
MIT License
104 stars 23 forks source link

Release Configuration producing invalid .xll (both x86 and x64) #6

Closed neptune2 closed 3 years ago

neptune2 commented 3 years ago

When compiling with the Release configuration, add-ins no longer work in Excel (same error for x64 and x86 Release add-ins on respective Excel versions). However, the Debug configuration works correctly for both x64 and x86 versions of Excel for respective add-ins.

Details: Visual Studio Community 2019 Version 16.9.3 (also tried Visual Studio Professional 2019 Version 16.9.3) Cloned xlladdins / xllproject1 (on 5/7/21 and again 5/10/21) - both with VS19 Git and manually with .zip files Excel 365 32-bit and 64-bit (and Excel 2007 32-bit) with respective add-ins

When loading via the Excel add-in dialog, Excel takes a long time to load the Release add-in, but there is no error (the Debug configuration .xll load is quick in comparison). However, the TGAMMA() function is not recognized by Excel for the Release configuration complied .xll.

When double clicking the xllproject1.xll file, the error is:

Excel error Release x64

Answering "Yes" shows a bunch of garbage text in Excel.

I have an older (10/16/20) clone of xlladdins/xll working for all 4 targets but would like to upgrade to the latest.

keithalewis commented 3 years ago

I am seeing the same thing. Will look into it and get back.

keithalewis commented 3 years ago

Working now. Please pull the latest and let me know if you are good now.

neptune2 commented 3 years ago

Thanks for your quick response.

I cloned the xllproject1 and the compile succeeds. However, the change did not fix the issue for the Release configuration (x64)

In the compile log I am getting the following only for the Release configuration:

2>------ Rebuild All started: Project: xllproject1, Configuration: Release x64 ------
2>xllproject1.cpp
2>xll.lib(xll_range.obj) : MSIL .netmodule or module compiled with /GL found; restarting link with /LTCG; add /LTCG to the link command line to improve linker performance
keithalewis commented 3 years ago

That is what I 'fixed' as you should see from the commit messages. It actually has nothing to do with MSIL but turning off whole program optimization seemed to do the trick. I have given xllproject1 a little more TLC and added flags for unsigned char, UTF-8, and WHOLEARCHIVE to drag in various utility add-ins from xll.lib. Can you do another pull and see if that fixes it?

neptune2 commented 3 years ago

I found the remaining problem.

The Whole Program Optimization also needs to be changed to "No" in the xll project (xll.vcxproj) as well.

Thanks again for your critical clue and for your excellent xll library.

keithalewis commented 3 years ago

Glad you like it. I'm never sure when submodules get updated unless I do it manually. If you are interested in Monte Carlo simulation in Excel you might want to look at https://xllmonte.com. Still going through teething pains with that so your feedback would be appreciated.

keithalewis commented 3 years ago

I misunderstood how git submodules work, and probably still do. I've added some github actions to make sure 64-bit builds work for Debug and Release but haven't added the xll.t tests yet. Pull requests welcome. Their yaml matrix is not friendly to x86/Win32 builds but I've manually tested on a machine running 32-bit Excel. Try git submodule update --recursive on your project to get the latest xll code. If that doesn't work I'm sure stackoverflow will have a dozen suggested solutions for various versions of git. :-( Please let me know if you are still having trouble and I'll fix it so we can close this issue. The great thing about computers is they do exactly what you tell them to do. The awful thing about computers is they do exactly what you tell them to do.

neptune2 commented 3 years ago

I have checked that this is now fixed - thanks.

Specifically - I followed the Get Started instructions in README.md: