Data analysis and visualization for Excel®, for free.
For more information about this project, see https://www.xltoolbox.net.
The XL Toolbox NG source code is written in (mostly) C# with Visual Studio Professional 2013 and targeted for the .NET framework 4.0.
For my own sake, I try to document the code well. In addition to the
comments in the source code, you can find
Doxygen-generated pages at
https://bovender.github.io/XLToolbox (or check out the
Building the project
Some additional DLLs (FreeImage, LCMS) as well as the VisualStudio
solution user options file (
NG.v12.suo) are not included in the Git
repository and must be manually taken care of after cloning the
- FreeImage.DLL: Load the FreeImage solution contained in the XL
Toolbox respository, build the
FreeImageproject (not the 'Plus' project) for both
amd64configurations, then copy the resulting DLLs to
- LCMS.DLL: Clone the repository from
https://github.com/mm2/Little-CMS, load a project file from the
Projectssubfolder, build the library for both 32-bit and 64-bit, and copy the DLLs into the same folders as described above.
- Change the startup project of the XLToolbox solution to
XLToolboxForExcelby right-clicking on this project.
When building the DLLs, make sure to use the
Release configuration to
avoid additional dependencies that may not be met on all target systems
Debug configuration is used (namely,
Notes regarding Debug configuration
The Visual Studio project files have been hand-edited to use different sources of the Bovender assembly: In the Debug configuration, the assembly is referenced locally. In the Release configuration, the assembly is referenced as a NuGet package. This has the advantage (for me) that I can make changes to Bovender without having to release a new NuGet package every time I want to test it in the NG solution.
This is my directory structure:
x:\ Code bovender\ Bovender\ BovenderUnitTests\ xltoolbox\ NG\ XLToolbox\ XLToolboxForExcel\ UnitTest\
The bovender assembly is thus referenced from the XLToolbox project file
(which resides in
If you want to build with Debug configuration, but do not have the Bovender assembly in the same directory structure as I have, you can (and should) use the Debug (Bovender via NuGet) configuration.
Code-signing the binaries
The sources do of course not include the confidential strong name key (.snk) file that is needed to sign the binaries. If you want to build the solution yourself, you have different options:
Clone the Git repository and subsequently remove the code signing option from all of the project properties to build unsigned binaries. It is best to use a separate branch to make the changes to the projects properties. If you later update the repository from remote, you can git-rebase this branch on top of HEAD.
On Windows, obtain the sources and supply a strong name key file in every subdirectory of the extracted source tree. The Visual Studio project properties expect the file name to be "xltb.snk". The original strong name key file is not included in the distributed sources for obvious reasons.
Clone the Git repository on a *nix file system. The repository contains symbolic links named "xltb.snk" in the subdirectories that point to a strong name key file in an unrelated directory "../private/" that lies outside of the repository. Therefore you would only need to create such directory and put the strong name key file in there. For instance:
# make new directory that holds everything and enter it mkdir XLToolbox chdir XLToolbox # clone the repository into `source` git clone git://git.code.sf.net/p/xltoolbox/ng-code source # make directory for strong name key file mkdir private # Then, start Windows and create a new strong name key file # named `xltb.snk` in the `private` directory.
Creating a strong name key file
Visual Studio comes with the
sn.exe tool that you can use to create a .snk
file. It is somewhat hidden; you may for example find it in:
C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\bin
In the command window,
cd to this directory and execute:
sn.exe -k xltb.snk move xltb.snk <drive:\path\to\sources_or_private>
Whether you have to move the .snk file to the
private directory or to the
source directory depends on what method you have chosen above. On
Windows-only systems where you will likely not be using symlinks, you need
to copy the .snk file to each and every subdirectory in the source tree.
It should go without saying that you cannot of course mix binaries from the original distribution with binaries that you build yourself, as they do not share the same strong name key.
Daniel's XL Toolbox NG Copyright (C) 2014-2018 Daniel Kraus <email@example.com>, <firstname.lastname@example.org> Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.