Проблема касалась моих предположений, основанных на том, где что-то было размещено. У меня был установщик, который развернул надстройку в целевом месте развертывания. Все файлы пошли в эту папку. Я думал, что если все библиотеки находятся в одном месте, их все нужно найти. Это было основано на моем представлении о том, что приложение запускается и ищет файлы в первую очередь локально. Моя ошибка состояла в том, что приложение, которое запускалось, было Office Outlook - и оно работает в определенной папке c. Когда я получил файл не найден, я подумал, что этого не может быть, потому что файлы все вместе. НО продукты Office при загрузке ADD Ins не ищут в том месте, где определено, что надстройка находится (в отличие от неуправляемых DLL-библиотек - управляемых - может быть иного).
Конечный результат состоял в том, что неуправляемая DLL не была обнаружена, потому что она не обнаруживалась ни в одном из расположений хранилища Windows. Таким образом, правильным было обновить путь, чтобы указать местоположение этого дополнения. Что решило проблему не найден. Что раздражает, так это то, что отладчик Visual Studio, похоже, работает над аспектом определения библиотек DLL, из которых запускается приложение. Что в целом хорошо - за исключением того, что с VSTO запускаемое приложение находится где-то еще, - но VS все еще искал в папке проекта папку, чтобы найти файлы. Делая это несколько неясным. Это не должно происходить. Отладка VS должна попытаться или, по крайней мере, быть настраиваемой для работы в контексте сценария реального мира. Если это произойдет - я, конечно, не смог найти эту конфигурацию.
Питер