Frequently Asked Questions

A Signed License is used with NuGet-distributed products to activate either a trial or fully-licensed mode. Current products that use a Signed License include:

• SpreadsheetGear Engine for .NET
• SpreadsheetGear for Windows

SpreadsheetGear for .NET Framework does not use Signed License strings.

The Signed License itself is a string generated from either the Evaluation Downloads page or the Licensed User Downloads page. It should be supplied in your application with the following line of code, which should be called somewhere before any other SpreadsheetGear API is called:

SpreadsheetGear.Factory.SetSignedLicense("YOUR SIGNED LICENSE HERE");

See the Signed License page for more details.

Any use of or reliance on this information is at your own risk and is without recourse to SpreadsheetGear LLC. This information is subject to change without notice.

SpreadsheetGear 2010 for .NET Framework, SpreadsheetGear 2012 for .NET Framework and SpreadsheetGear 2017 for .NET Framework, SpreadsheetGear 2023 for .NET Framework, SpreadsheetGear Engine for .NET (formerly called SpreadsheetGear for .NET Standard) and SpreadsheetGear for Windows are self-classified with an ECCN of 5D992.c under EAR 742.15(b)(1), a license designation of NLR (“No License Required”), an Authorization Type of MMKT ("Mass Market") and an Export Registration Number (ERN) of R108616. These products encrypt Microsoft Excel documents using the .NET Framework Cryptography APIs as described in “2.3.4 ECMA-376 Document Encryption” of the document known as “[MS-OFFCRYPTO]: Office Document Cryptography Structure” which can be found here.

SpreadsheetGear 2012 for Silverlight and all other SpreadsheetGear software have an ECCN of EAR99.

Please see "10. Export Rules" in the SpreadsheetGear End User License Agreement for more information.

Beginning in Version 9, we renamed "SpreadsheetGear for .NET Standard" to "SpreadsheetGear Engine for .NET". This was done for a couple of reasons:

• Before the name change, this product only targeted .NET Standard. But in Version 9 we started targeting both .NET Standard 2.0 and .NET 6, necessitating a name change.
• To clarify the role of this product as primarily being a spreadsheet engine. Other products can supplement SpreadsheetGear Engine for .NET, such as using "SpreadsheetGear for Windows" to bring in Windows Forms / WPF UI controls, image rendering, printing, etc.

The reason for AutoFit columns being slightly off is that the font metrics provided to us by .NET differ from those used by Microsoft Excel. You can work around this problem by adding a fudge factor to the column width after calling AutoFit(). Example:

IRange column = worksheet.Cells["A:A"].Columns;
column.AutoFit();
column.ColumnWidth *= 1.08;

Or when AutoFitting multiple columns:

IRange columns = worksheet.Cells["A:D"].Columns;
columns.AutoFit();
foreach (IRange column in columns)
{
    column.ColumnWidth *= 1.08;
}

This is a known limitation. When copying data from Microsoft Excel, they place several different versions of your data on the Clipboard, the two primary versions being:

• A "Biff8" representation, i.e., an Excel 97-2003 / *.xls file, containing your copied data.
• A Binary Open XML representation, i.e., an Macro-Enabled Open XML / *.xlsb file.

SpreadsheetGear must use the *.xls representation of the Clipboard data because SpreadsheetGear does not yet support reading or writing *.xlsb files. The older *.xls file format has limits of 256 columns and 65,536 rows (compared to the larger limits of Open XML files--16,384 columns and 1,048,576 rows), and so data beyond these limits will not be included when pasting into SpreadsheetGear. Other aspects of data could also get lost, such as more advanced Conditional Formatting options like Icon Sets, more than 3 rules, etc., since these are not supported in *.xls.

SpreadsheetGear utilizes an optimization in Open XML files that omits writing out certain sheet data attributes that are not always required. Omitting these attributes has the benefit of significantly reducing the file size of some workbooks--particularly files with a lot of cell data. While this optimization is compliant with the Open XML specification, OleDb cannot handle files that do not always write out these attributes.

To work around this, you can set the IWorkbookSet.Experimental property to the value of "OleDbOpenXmlWorkaround", which will cause SpreadsheetGear to always write out these attributes and so allow OleDb to read the files:

// Create an IWorkbookSet with the OleDbOpenXmlWorkaround option enabled
IWorkbookSet wbs = Factory.GetWorkbookSet();
wbs.Experimental = "OleDbOpenXmlWorkaround";

// Open or create a workbook.
IWorkbook workbook = wbs.Workbooks.Open(@"C:\Path\To\Workbook.xlsx");

// Save file and OleDb should be able to now read it
workbook.SaveAs(@"C:\Path\To\Workbook_OleDb.xlsx", FileFormat.OpenXMLWorkbook);

The cause for this issue relates to a breaking change in .NET 5 and later. This is documented by Microsoft:
https://learn.microsoft.com/en-us/dotnet/standard/base-types/string-comparison-net-5-plus

Prior to this change (.NET Core 3.1 and earlier and .NET Framework), an app would use the host Windows OS’ National Language Support (NLS) APIs to perform various tasks relating to localization, string comparisons, etc. Starting in .NET 5, they now use an International Components for Unicode (ICU) library, which isn’t tied to the Windows OS and allows for more consistent behavior across various runtimes (Windows, Linux, etc.).

Unfortunately, this change results in behavioral differences when performing tasks such as sorting or text comparison, and can potentially have an impact on the results of a number of SpreadsheetGear functions and features, such as those listed above. However, keep in mind this can also affect your own code that might depend on certain behaviors for string comparison / sorting / etc…

Microsoft does provide a way to revert your app to use NLS with .NET 5 or later when running on Windows, which will cause SpreadsheetGear to revert to its previous behavior and results. Please visit the following for instructions on how to make this change, which involves enabling a “System.Globalization.UseNls” setting in your *.csproj or runtimeconfig.json file: https://learn.microsoft.com/en-us/dotnet/core/extensions/globalization-icu

SpreadsheetGear 2023 assemblies come with IntelliSense Help which works with all supported versions of Visual Studio. If you recently installed a new version of SpreadsheetGear, you may need to remove any references to SpreadsheetGear assemblies from your project using the Solution Explorer window in Visual Studio. First, remove any old references, then, add any new ones back by using the .NET tab of the Add Reference dialog.