Я могу предложить ответ на последнюю часть вашего вопроса об избежании проблемы.
Один из способов обойти это состоит в том, чтобы отделить код, который явно не ссылается на библиотеки VSTO, в другой проект, а затем протестировать его - я понимаю, что это, вероятно, потребует усилий, чтобы фактически иметь код, который не ссылается на VSTO .
Но, таким образом, код, который вы тестируете, - это код, который можно протестировать без ссылки на VSTO, а код, специфичный для VSTO, вероятно, будет протестирован с помощью интеграционных тестов (вручную или через API, например White - где Белому не нужно ссылаться на VSTO, потому что он просто запускает исполняемый код, который использует VSTO)
Хотя это может означать значительный редизайн - например, вам может потребоваться создать классы-обертки - и это может оказаться для вас нецелесообразным в данный момент, но я считаю, что это обычно считается хорошей практикой (это своего рода разделение интересов ), поскольку это облегчает управление кодом и часто помогает изолировать определенные ошибки от осложнений VSTO.