Overview
In organisations subject to confidentiality requirements, documents carry a sensitivity label (Microsoft Information Protection). But when a user prints such a document to a virtual PDF printer, the resulting file loses that label: the PDF can then circulate freely, with no control. SNCDetector was built to close that gap.
Installed in Word, Excel and PowerPoint, the add-ins detect that a classified document is about to be printed to PDF and redirect the operation to Office's native PDF export, which does preserve the metadata and the confidentiality level. The user stays in control, but the classification is never lost by accident.
Architecture
The suite is designed around the Template Method pattern. An abstract base class carries all the shared logic — detection, label reading, user dialogue, logging — and defines the few points where behaviour differs from one application to another. Three concrete add-ins, one per Office application, only implement those specific points. The bulk of the code is written once.
Each add-in is a VSTO add-in that hooks into Office's print events when the host application starts. The challenge is not so much the detection as the diversity of the event models: Word, Excel and PowerPoint do not expose the same hooks nor the same cancellation options. A notable part of the design is about absorbing those differences without duplicating the business logic.
Behaviour is fully configurable through the Windows registry — silent or interactive mode, logging, printer lists — with sensible defaults created on first run. The whole is covered by 125 NUnit unit tests that validate the decision matrix and the configuration reading, independently of Office.
Technical decisions
Writing the logic once. Rather than three independent add-ins, all the detection logic was isolated in a shared base class. Each Office application only contributes its specifics. As a result, a behaviour fix immediately benefits all three add-ins, and supporting a new application would come down to a few methods.
Working with each host's constraints. PowerPoint, in particular, offers no clean way to cancel a print: its event model is poorer than Word's or Excel's. The solution was not to work around the problem but to adapt the experience — informing the user at the right moment and neutralising the side effects of a cascading trigger. Each application is handled according to what it actually allows, not according to an ideal model.
Making Office-bound code testable. A VSTO add-in depends on Office COM objects that cannot be instantiated in a test. The decision logic was therefore extracted from any dependency on Office and placed in the base class, which made it possible to cover it with 125 automated tests through a dedicated test implementation. The part that is genuinely Office-bound stays thin and is verified manually.