Isolated server

xlsgen > overview > Isolated server

xlsgen has two run-time modes :

xlsgen.dll, or in-process, a component that gets loaded as part of your client application or host.
xlsgen.exe, or local server, a component that runs outside your client application or host.

Why pick the local server over the other one ?

crash isolation
- should xlsgen crash, the xlsgen.exe process would crash without interfering with the client application or host.
32-bit/64-bit isolation
- should you run on a 64-bit operating system, the question of whether xlsgen.exe is 32-bit or 64-bit does not matter anymore since a 64-bit operating system can run both (respectively through the WOW64 layer and natively).
load balancing
- should the component be under intense load, a separate process makes it possible for the built-in COM load balancing to start another process instance (possibly taking advantage of CPU cores) instead of waiting. The load balancing may create one or more such process instances.
security isolation
- method calls are made externally to another process (xlsgen.exe), which means that the client application or host needs not comply to the rules of in-process components running inside the same process. Should an organization enforce tightened rules regarding security (trusted components, ...), the local server would be the easiest to pick to comply with those rules.
thread isolation
- a separate process automatically means that limitations of threads are alleviated. This run-time mode allows for better use of CPU cores.
locale isolation
- the fact that xlsgen and the client application or host do not share the same thread means that the thread locale (regional settings : timezone, date time format, floating-point character separators, ...) are not dependent either.

Using the local server mode, one or more xlsgen.exe processes show up in the Windows task manager

Activating the local server

The good news is that none of the client-side source code changes whether you are using the in-process mode or the local server mode.

But a one-time local COM registration is needed. It works as follows :

Hit Windows+R to open-up the command-line window
Type "<path>\xlsgen.exe" /REGSERVER, where <path> is C:\program files\xlsgen by default (after a default install), and hit Enter.
A message box shows up, telling whether the registry keys were successful created or not. click OK.

Note : if you are running Windows 7, Windows 8 or any version of Windows where the user does not run as an administrator, you may have to put this into a .bat file, right-click and choose Run as administrator.

Once this activation is done, the creation of a running instance of xlsgen will automatically start a new process, xlsgen.exe, unless the process is already running and it can process the load.

Based on customer feedback, it appears that sometimes users running under lower privilege accounts on Windows 64-bit need to take additional steps in order for the isolated server to work. Here is a recap :

once the isolated server is COM-registered (see above), verify that the registry keys are indeed created. For this, hit Windows+R, enter REGEDIT.EXE and hit enter.
Verify that the following registry key exists : HKEY_CLASSES_ROOT\CLSID\{089D25AC-7618-4FEF-9BB1-6FDDF1FD3B3A}\LocalServer32
If not, create it manually
Verify that the default value associated to this registry key (right panel of the registry editor), points to xlsgen.exe, and that this is a correct file path. If not, make the appropriate changes.
At this point, the registry is ready. You can quit the registry editor and try whether the isolated server works.
If the isolated server does not work, a likely reason is security related.
It is very likely that security issues will actually trigger application events from Windows COM/DCOM, and a list of the events can be seen in the Events viewer. The Events viewer is available in the Windows configuration panel / Administrative tools. This can help you figure out what might be the issue. The Events viewer may, for instance, name the user under which the process is trying to run, and this can help you configure the system so that this user has enough privilege to run this process. There is a system-wide configuration tool called DCOMcnfg.exe (which is short for Distributed COM configuration), which is part of Windows. You can start it by hitting Windows+R, type DCOMcnfg.exe and hit enter.
Unfold "Component services / Computers / My computer / DCOM configuration", and you should see a key called "ExcelGenerator".
In case you don't see the "ExcelGenerator" key, the workaround works as follows. Hit Windows+R, enter mmc -32 and hit enter. Then add the Component services snap-in from there. That should fix it and from now on it will be possible to use DCOMcnfg.exe. When you do this, the tool looks up all COM components available for use, including "ExcelGenerator" and shows it in the list.
Right-click on "ExcelGenerator", choose Properties and click on the Security tab. From there, change the appropriate security option to "everyone". This change is for ensuring you can run xlsgen.
You can quit the registry editor and try whether the isolated server works.
In one customer case, running behind ASP.NET 64-bit, a special user called IIS_USR had to be added to the list of persons with Execution authorization and access, in the Security tab.
That should get the isolated server up and running. We have not heard of a single customer giving up on getting the isolated server up and running.

Switching back to the in-process mode

If you are willing to stop using the local server, you may either 1) use the COM-free technique, which automatically loads xlsgen.dll as part of the client application or host, or 2) re-activate the in-process mode by doing the following :

Hit Windows+R to open-up the command-line window
Type regsvr32 "<path>\xlsgen.dll", where <path> is C:\program files\xlsgen by default (after a default install), and hit Enter.
A message box shows up, click OK.

When xlsgen.exe is needed?

The fact that your client application or host runs on a 64-bit operating system does not automatically mean you have to use xlsgen.exe instead of xlsgen.dll. In fact, if the client application or host is a 32-bit image, then you can use the one or the other. If, however, the client application or host is a 64-bit image, then you need to use xlsgen.exe or the 64-bit version of xlsgen.dll.

Registration modes

Two registration modes are available :

/S : silent registration. The COM registration, by default, shows a successful/failed message box after the COM registration process. By using the silent mode, this message does not show at all.
/K : keep mode. The xlsgen.exe process does not kill itself when the engine instance is no longer used by the client application.

Pass these flags along with the /REGSERVER command.