Protect an Excel Workbook

You’ve built a powerful Excel application with VBA macros, and now you want to distribute it without exposing your source code. In this tutorial, you’ll walk through the complete automatic workflow: VBA Padlock analyzes the workbook you already have, compiles your logic into a protected DLL, and produces a protected copy where your macros still work, but your code is gone.

What you’ll get:

• A protected copy of your workbook (MyExcelApp_protected.xlsm) whose macros and buttons work exactly as before
• A compiled, encrypted DLL containing your VBA logic
• (Optional) An activation system with hardware-locked license keys

Time needed: 10-15 minutes

1. Launch VBA Padlock

2. Click “Open Office File” in the Protect tab (or press Ctrl+O)

3. Select your Excel workbook or add-in (.xlsm or .xlam file); for this tutorial, we’ll use a file called MyExcelApp.xlsm

4. VBA Padlock reads your VBA modules straight from the workbook (macros stay disabled during the read) and analyzes them automatically

That’s it: no importing, no copy-pasting code. Your modules appear in the Project Explorer, each with a verdict badge, and a .vbapadlock project folder is created next to your file to hold settings and analysis data.

Suppose MyExcelApp.xlsm contains a standard module Greetings with functions like these:

Sub HelloWorld()
    MsgBox "Hello from MyExcelApp!", vbInformation, "MyExcelApp"
End Sub

Function CalculateDiscount(Price, DiscountRate)
    If DiscountRate < 0 Or DiscountRate > 1 Then
        CalculateDiscount = Price
    Else
        CalculateDiscount = Price * (1 - DiscountRate)
    End If
End Function

Sub WriteToCell(CellAddress, Value)
    Application.ActiveSheet.Range(CellAddress).Value = Value
End Sub

All of these will move to the DLL, including the ones that talk to Excel through the Application object.

Click View Report in the Protect tab (the review also opens after each analysis). Every procedure gets a disposition:

For a typical workbook, expect your standard modules to show -> DLL and your event handlers (Workbook_Open, Worksheet_Change, button handlers in sheet modules) to stay in VBA. That’s by design: Office only fires events on code living in the host module.

If a procedure you expected to move shows VBA with a reason like shared module-level state 'Counter', you can restructure the code and click Re-analyze, or simply accept the verdict. Per-procedure checkboxes let you keep any routine in plain VBA on purpose.

The automatic workflow fills in working defaults, but two tabs are worth a glance before shipping:

• Project Info: Application Title, Version, Copyright, the output DLL name, and the auto-generated Security Code and Project GUID.
• References: ExcelConstants and OfficeConstants are pre-selected, so symbolic constants like xlUp or msoTrue compile straight into the DLL.

1. Click “Produce Protected Office File”, or Test Run (Ctrl+F5) to produce and open the result in Excel

2. The progress dialog compiles your modules, injects the wrappers and the VBAPLBridge module into a copy of your workbook, and verifies the result

3. On success you’ll see “Protected File Created” with an Open in Excel button. Your folder now looks like this:

MyExcelApp\
├── MyExcelApp.xlsm             (your source - keep it private!)
├── MyExcelApp.vbapadlock\      (project settings)
├── MyExcelApp_protected.xlsm   (the protected copy - ship this)
└── bin\
    ├── MyExcelApprun32.dll     (32-bit runtime)
    ├── MyExcelApprun64.dll     (64-bit runtime)
    └── MyExcelApp.dll          (your compiled code - satellite DLL)

1. Open MyExcelApp_protected.xlsm in Excel (enable macros when prompted)

2. Run your macros. Buttons, Alt+F8 macros, worksheet functions: everything works as before

3. Press Alt+F11 and look at your modules: the procedure names are still there, but each body is now a one-line wrapper delegating to the compiled DLL through VBAPL_Execute

Because the wrappers keep the original names and signatures, worksheet formulas that call your VBA functions (=CalculateDiscount(A1, 0.15)) keep working too.

If you want to require an activation key before your application runs, follow this step. If you’re just protecting your code without licensing, skip ahead to Step 7.

1. Switch to the “Licensing Features” tab in the VBA Padlock ribbon

2. Click “Activation Settings”

3. Check “Activation key is required to run the protected VBA application”

Hardware locking ties each license key to a specific computer, preventing key sharing.

1. In the Activation Settings tab, check “Create hardware-locked keys”

2. Click “Hardware ID Options…” to choose which hardware components to include:

   • Computer Name (recommended)
   • Windows Volume Serial (recommended)
   • BIOS Serial Number (recommended)
   • CPU Serial (optional; some CPUs don’t report it)
   • MAC Address (not recommended; changes with network adapters)

Licensing rules are baked into the DLL, so run Produce Protected Office File again (back on the Protect tab). The new protected copy now enforces activation: the activation dialog appears automatically when a protected function runs without a valid license.

To test the activation flow on your own computer:

1. Click “Key Generator” in the Licensing Features ribbon

2. The Hardware ID field shows your computer’s ID

3. Click “Generate Key” and copy the generated key; you’ll enter it in the activation dialog

The bridge exposes the licensing API to your VBA, so you can integrate checks wherever you like, for instance a Workbook_Open handler in ThisWorkbook:

Private Sub Workbook_Open()
    If Not VBAPL_IsLicenseValid() Then
        VBAPL_ShowActivation
    End If
End Sub

Or let users look up their Hardware ID to send it to you:

Sub ShowMyHardwareID()
    MsgBox "Your Hardware ID is:" & vbCrLf & VBAPL_GetHardwareID(), _
           vbInformation, "Hardware ID"
End Sub

See the VBA Bridge API Reference for the complete VBAPL_* list. The bundled 04_LicensingDemo example shows the full lifecycle (EULA, trial, activation, deactivation) wired into a real workbook.

You’re ready to ship. VBA Padlock includes a Distribution tab to package your files with the correct folder structure.

1. Click “Distribute” in the Protect tab

2. Confirm the file label shows your protected copy (if it says no protected copy has been produced yet, run Produce first; Distribution will warn you before shipping an unprotected source)

3. Choose one of two options:

   • Create ZIP Archive…: creates a ready-to-ship ZIP file
   • Copy to Folder…: copies all files to a specified directory

4. For this tutorial, select “Create ZIP Archive…” and choose a destination (e.g., MyExcelApp_v1.0.zip):

   MyExcelApp_v1.0.zip
   ├── MyExcelApp_protected.xlsm
   └── bin\
       ├── MyExcelApprun32.dll
       ├── MyExcelApprun64.dll
       └── MyExcelApp.dll

Include this in your distribution (e.g., in a README.txt):

INSTALLATION INSTRUCTIONS
=========================

1. Extract all files to a folder on your computer (e.g., C:\MyExcelApp\)

2. IMPORTANT: Keep the folder structure intact. The 'bin' folder must remain
   in the same directory as the .xlsm file

3. Open the .xlsm file in Excel

4. If you see a security warning, click "Enable Content"

5. If prompted, enter your activation key and click "Activate"

6. You're ready to use the application!

IMPORTANT:
- Keep the .xlsm file and the 'bin' folder together at all times
- Do not move or rename files in the 'bin' folder
- The 'bin' folder contains 3 DLL files that are required for operation

Congratulations! Your Excel workbook is protected: the logic runs from an encrypted DLL, and the workbook you ship contains only wrappers and glue code.

Cause: The compile gate kept it in the workbook; the row’s reason tells you why (event handler, shared module-level state, depends on a kept procedure, unresolved host global…).

Solution: See the Protection Review reference for each reason and its fix. Typical remedies: move event logic into a standard-module Sub, add Option Explicit, or restructure module-level variables. Then click Re-analyze.

Cause: Excel cannot find the DLL files in the bin\ folder.

Solution:

1. Make sure the bin\ folder exists in the same directory as the protected workbook
2. Verify that the bin\ folder contains all three DLL files:
   • MyExcelApprun32.dll
   • MyExcelApprun64.dll
   • MyExcelApp.dll
3. Do not rename or move the bin\ folder or any files inside it

Cause: The activation key does not match the user’s Hardware ID.

Solution:

1. Ask the user for their Hardware ID (they can run the ShowMyHardwareID macro or call VBAPL_GetHardwareID())
2. Generate a new key specifically for that Hardware ID using the Key Generator
3. Do not reuse keys generated for a different computer

Cause: The stored license was deleted (e.g., Windows reinstall, registry cleanup).

Solution: The user needs to reactivate with their existing key. If the hardware has not changed, the same key will work again.

Cause: Excel’s security settings block macros.

Solution: Add the application folder to Excel’s Trusted Locations:

1. Go to File > Options > Trust Center > Trust Center Settings
2. Click Trusted Locations
3. Click Add new location and browse to your application folder

Cause: The return value of a generic VBAPL_Execute call is a Variant. If you assign it to a strongly typed variable without conversion, you may get a type mismatch.

Solution: Use CStr(), CDbl(), CLng(), or similar conversion functions when assigning the result to a typed variable, or declare your receiving variable as Variant. (The wrappers generated by Produce handle this for you.)

• Automatic Protection Workflow: The concepts behind this tutorial
• VBA Bridge API Reference: Complete list of all VBAPL_* functions
• Protect a Word Document: Similar tutorial for Word
• Protect an Access Database: Similar tutorial for Access
• Activation Settings: Detailed activation settings reference
• Key Generator: Advanced key generation options
• Produce & Test Run: The production pipeline reference