xlsgen > overview > COM-free Deployment

COM-free deployment is a technique meant to avoid the requirement to register xlsgen as a COM component. Makes it easier to successfully deploy applications using xlsgen. This technique works across all Windows operating system versions.

It's optional, so if you are happy with the way xlsgen works for you, just ignore the remainder of this page, existing xlsgen code will continue to run just fine.

xlsgen does not require COM registration anymore. COM registration is a standard mechanism, and all standard Setup build tools (such as InstallShield, Wise, Install2Go, the VisualStudio Setup wizard, ...) support this mechanism. And COM registration can be done by hand at any moment using the following command-line : regsvr32 <path>\xlsgen.dll to register the component, and regsvr32 -u <path>\xlsgen.dll to unregister it.

What's the point then? With always more stringent install requirements, especially entreprise deployments, the COM-free deployment technique comes handy. It means it becomes possible to deploy and run this application in limited-user environments. Since the registry is not used, it means the xlsgen.dll file can simply be copied anywhere on the hard drive and be referenced by its sole path in some client application code. As a bonus, this technique works regardless the operating system version it runs on. We are not talking here about the Windows XP side-by-side mechanism which, by definition, requires Windows XP in the first place.

Avoiding COM registration is a great benefit to high-level programming languages such as Java and .NET languages. It's indeed not obvious why a Java developer writing a Java application should have to deal with COM to begin with.

xlsgen exposes an entry-point, a regular Start() function, and you can take advantage of it to directly load xlsgen, get an instance of IXlsEngine the root interface to the API, and start using it.

To C/C++ developers, it means you can forget about CoInitialize()/CoCreateInstance()/CoUninitialize() and replace it with a cold Start() function call. Here is a sample code in C++ :

::CoInitialize(NULL);
xlsgen::IXlsEnginePtr engine( __uuidof(xlsgen::CoXlsEngine) );


// note : the xlsgenLoader class loads xlsgen as a regular dll, and calls 
//  the Start() entry point
xlsgenLoader xlsgen("xlsgen.dll");

if (!xlsgen.IsInitialized())
  return;
  
xlsgen::IXlsEnginePtr engine = xlsgen.Start();
xlsgen::IXlsWorkbookPtr wbk = engine->New( L"sample1.xls" );
xlsgen::IXlsWorksheetPtr wksht = wbk->AddWorksheet( L"samplesheet" );
wksht->Label[1][2] = L"Hello world!";
wbk->Close();

In order to deploy a C/C++ application this way, you only need to make sure file "xlsgen.dll" is accessible accordingly to the path it is being referred to in the code above. In most cases, you probably want to put a copy of file "xlsgen.dll" in your application folder (and a copy of the license file).

To Java developers, an XlsEngine constructor overload lets you pass the fully qualified path of the xlsgen.dll file, and that's it. You get an instance of the component in return and are ready to go. The implementation of this constructor in turn loads the dll given its path, and calls the Start() function. Here is a sample code in Java :

XlsEngine engine = new XlsEngine();

XlsEngine engine = new XlsEngine("xlsgen.dll");

XlsWorkbook workbook = engine.New("sample.xls");
XlsWorksheet wksht = workbook.AddWorksheet("samplesheet");
wksht.putLabel(1,2, "Hello world!");
workbook.Close();

In order to deploy a Java application this way, you only need to make sure file "xlsgen.dll" is accessible accordingly to the path it is being referred to in the code above. In most cases, you probably want to put a copy of file "xlsgen.dll" in your application folder (and a copy of the license file).

To .NET developers, the only thing to do in your code is to add a simple [DllImport("xlsgen.dll")] platfom invoke call, and then call the Start() method. It returns an IXlsEngine instance, and you are ready to go. Here is a sample code in C# :

xlsgen.CoXlsEngine engine = new xlsgen.CoXlsEngine();

[DllImport("xlsgen.dll")]
static extern IXlsEngine Start();

IXlsEngine engine = Start();
IXlsWorkbook wbk = engine.New( @"sample.xls" );
IXlsWorksheet wksht = wbk.AddWorksheet( "samplesheet" );
wksht.set_Label(1,2, "Hello world!");
wbk.Close();

In order to deploy a .NET application this way, you only need to make sure that file "interop.xlsgen.dll" is in the application folder, and file "xlsgen.dll" is accessible accordingly to the path it is being referred to in the code above. In most cases, you probably want to put a copy of file "interop.xlsgen.dll" and file "xlsgen.dll" in your application folder (and a copy of the license file). File "interop.xlsgen.dll" is produced by Visual Studio at compile-time. You can also produce this file using the .NET tlbimp tool from the .NET SDK.

To VB (classic VB, i.e. version 5.x/6.x or VB.NET) developers, the following pattern can be used :

Dim engine As CoXlsEngine
Set engine = CreateObject("ExcelGenerator.ARsTDesign")

' this piece of code must be added in a VB module

Declare Function Start Lib "xlsgen.dll" () As CoXlsEngine


Sub generate()

Dim engine As CoXlsEngine
Set engine = Start()

Dim wbk As IXlsWorkbook
Set wbk = engine.New("sample.xls")

Dim w As IXlsWorksheet
Set w = wbk.AddWorksheet("name1")

w.Label(1,2) = "Hello world!"

wbk.Close

End Sub

In order to deploy a VB application this way, you only need to make sure file "xlsgen.dll" is accessible accordingly to the path it is being referred to in the code above. In most cases, you probably want to put a copy of file "xlsgen.dll" in your application folder (and a copy of the license file).

If you are using VBA, not VB, using the Declare statement implies to put the code above in a module window, not in a worksheet or workbook code window : when you are in the VBA editor, right-click on the project node on the left, and choose Insert / Module.

To Delphi developers, the following pattern can be used :

type
   TStart = function(): Pointer; stdcall;

var
  Handle: THandle;
  Start: TStart;
  engine : IXlsEngine ;
  wbk : IXlsWorkbook ;
  wksht : IXlsWorksheet ;
begin
   OleCheck(CoCreateInstance(
      Class_CoXlsEngine,
      nil,
      CLSCTX_ALL,
      IXlsEngine,
      engine));
  Handle := LoadLibrary('xlsgen.dll');
  @Start := GetProcAddress(Handle, PAnsiChar('Start'));
  engine := IXlsEngine(Start());
  wbk := engine.New('sample.xls');
  wksht := wbk.AddWorksheet('Sheet1');
  wksht.Label_[2,3] := 'Hello World' ;
  wbk.Close();
  engine := Nil
end;

Actually, code samples related to charts all show a way to load xlsgen without relying on COM. Go check them out.

What makes this possible? A good part of the reason why it is possible in the first place is that xlsgen.dll is a dll, not an executable. Crossing the executable boundaries would require some specific technology, arguably part of the COM library (COM implements a typical client/server socket transport to cross process boundaries). So as long as xlsgen ships as a dll, it is possible to avoid COM. Note that the COM layer still brings a great interop layer which in turn gives you intellisense in your IDE, as well as the object browser in Visual Studio/Eclipse/IntelliJ. So it's not like COM should be burnt and forgotten. But for deployment purposes and run-time, it's not a requirement anymore.