 |
| 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 isolation
- 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 activation 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, click OK.
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.
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.
xlsgen documentation. © ARsT Design all rights reserved.