Unlocking Chilkat in Classic ASP

Chilkat is unlocked by calling UnlockBundle at least once per ASP worker process. It's OK for UnlockBundle to be called redundantly.

Putting the call to UnlockBundle in the Application_OnStart within the Global.asa does not provide a mechanism to run code once per server process. Here's why:

What Global.asa Actually Does

Application_OnStart runs once per application domain, not per process. It's triggered when the first request comes in and the ASP application starts. But if the web application is configured to run with multiple worker processes (e.g., in a Web Garden scenario in IIS), each process has its own memory space and own copy of the application state. However, Application_OnStart might not be reliably called once per process, especially under load balancing, recycling, or other factors.

Solution: Use Session_OnStart

You can use Session_OnStart in Global.asa to run your initialization code — if the following conditions are acceptable for your scenario:

When Session_OnStart Works for Per-Process Init

If your initialization code:

• Is lightweight (Yes, UnlockBundle is lightweight.)
• Can safely run multiple times (Yes, it is OK to call UnlockBundle multiple times.)
• Does not require exclusive access
• Only needs to run eventually per process (i.e., it's fine if it runs 5–10 times on startup in the same process)

Then Session_OnStart is a practical and simple place to put it.

Why It Might Work for Your Use Case

• In ASP Classic, every new user session triggers Session_OnStart.
• On a server process that just started, the first few incoming requests will cause it to run.
• So eventually, every server process that handles user sessions will run this code.

It’s not precise per-process execution, but it can act as a best-effort mechanism.

Limitations and Caveats