Развертывание VSTO 3.0 на предприятии:
Ничего особенно хитрого в этом нет. Я определенно рекомендую вам использовать для развертывания систему упаковки ваших компаний, такую как Altiris или SCCM. При упаковке убедитесь, что вы добавили проект CustomInclusionList (и настроили его в соответствии с документами MSDN) + при необходимости подписали свои сборки, если у вас есть сертификат подписи кода.
Если вы находитесь в закрытой среде, вам понадобится технология упаковки, позволяющая устанавливать пакет как администратор. В противном случае развертывание будет кошмаром.
Будьте осторожны, когда заставляете упаковщиков переписать пакет, созданный Visual Studio. Необходимо убедиться, что все ключи реестра сохранены, пользовательские действия и т. Д.
Вы, вероятно, будете развертывать в куст HKCU, что означает, что пользователи не смогут удалить надстройку самостоятельно (если они не являются администратором).
Обратите внимание, что если пользователи получают приглашение открыть офисное приложение с вопросом «Хотите ли вы установить / не устанавливать этот плагин и т. Д.», То проект custominclusionlist настроен неправильно или у вас отсутствует раздел реестра.
В Citrix:
Кажется, это работает нормально. Главное, чтобы серверы Citrix были полностью обновлены до последней сборки Office со всеми необходимыми компонентами, установленными до развертывания. Это тривиально, если у вас хорошо поддерживается система исправлений. Как другой ответчик ничего особенного не сказал с Citrix. Это будет просто работать, следует установить в HKCU, чтобы избежать каких-либо проблем.
PowerToys для VSTO:
Да, это здорово. Они одинаково хорошо работают с VB или C #. они не зависят от языка, я думаю, что утверждение, на которое вы ссылаетесь, означало, что они были написаны на C #.
При развертывании убедитесь, что вы включили сборку расширений либо локально, либо в GAC. он не будет установлен на компьютер пользователя, даже если на нем уже установлен компонент Office 2007 PIA.
При использовании C # поверх VB.net:
без комментариев! да, я бы пошел на C #, хотя некоторые жалуются, что он более многословен, чем VB для проектов VSTO, я думаю, что большая часть этого является наследием. Ищите действительно плохие методы, которые имеют как 30 необязательных аргументов, у вас есть несколько способов справиться с этим сейчас. Напишите метод расширения самостоятельно или в большинстве случаев используйте методы, доступные в пространствах имен Excel.Extensions и Word.Extensions. Также вы можете писать перегрузки в статическом вспомогательном классе и вызывать такие методы, как Open, используя только те параметры, которые вы собираетесь использовать.
В конечном счете, вы должны принять решение, основываясь на том, что лучше большинству программистов, и, как следствие, на ваших силах в ресурсах программистов. Вы можете быть гуру в C #, но если остальные 9 парней являются мастерами VB.net, то имеет смысл делать проекты в VB.net. все еще пытаюсь преобразовать их, но реальное решение - с техналом / менеджером, а не с обезьянами кода.