Solidworks is a software that can be run in multiple instances, and the SW API is a secondary development that depends on the SW environment. This in itself is a bug, because the API doesn’t know whether the user is operating SW1 or SW2.
TDO can actually ignore this bug; it can load any number of Service Servlets (SWs) you launch. The problem is that when you operate on SW2, but because you ultimately activated SW1, or your background process activated SW1, TDO will check the environment of SW1. From a code perspective, logically, we have no errors.
We completely block you from starting it because users don’t understand why it’s malfunctioning. They think it’s a bug in TDO, but it’s actually a bug in SW. Even worse, TDO and SW are highly integrated, deeply monitoring your SW’s execution process.
Describing this behavior as a bug might be inappropriate. Just as TDO doesn’t consider whether using other plugins affects our operation, SW has no responsibility to protect the operation of a worthless plugin.
Here, I’ll specifically name SW2019, as it’s the version most prone to background remnants. At least based on our testing and comparison of several versions, this isn’t exactly a problem, but it’s fatal for running plugins.
Why don’t other plugins have multi-process verification? Can you guess?
