Использовать VBA в приложениях Office 2007?

Office VSTO предлагает множество дополнительных функций по сравнению с Office VBA, и хотя я не верю, что Microsoft сообщила, что собирается прекратить работу VBA (на самом деле, они прямо сказали, что это будет по крайней мере до Office 14; Office 2007 = Office 12) , Я думаю, что перенос ваших приложений на VSTO стоит того, чтобы воспользоваться преимуществами дополнительной гибкости и мощности.

На самом деле я не думаю, что отказ от VBA был бы целесообразным, поскольку изрядное количество программирования Office выполняется на макроуровне бизнес-пользователями, и я не думаю, что это исчезнет в ближайшее время. У этих людей обычно нет доступа к IDE с поддержкой VSTO.

VSTO имеет новые функции, но также имеет ряд серьезных недостатков по сравнению с VBA.

Во-первых, Code Access Security может затруднить развертывание приложений VSTO (это вежливо).

Во-вторых, среда разработки VSTO далеко не так доступна для опытных разработчиков, как VBA. Например, нет макроса для начала работы.

И серьезным препятствием является то, что взаимодействие .NET с внепроцессными COM-объектами не работает. Например, если вы хотите управлять другими приложениями Office (Word, PowerPoint, Outlook) из приложения Excel VSTO, вы найдете несколько копий этих приложений, работающих в фоновом режиме, по причинам, описанным в эта статья базы знаний.

Все это в сочетании с огромными инвестициями в существующие приложения VBA означает, что VBA не исчезнет в ближайшее время.

Microsoft заявила, что будет поддерживаться движутся вперед в обозримом будущем, но они также рекомендуют, чтобы новые приложения использовали VSTO.

Последняя версия MS Office для Mac не поддерживает VBA, а 64-разрядная версия Windows запускает его в виртуальном 32-разрядном внепроцессном режиме. Поэтому, если вы планируете новое приложение, использующее Office в качестве платформы, VSTO определенно вам подойдет, но не стоит слишком беспокоиться о поддержке устаревших версий.

Как отмечает @cori, для MS было бы большим маркетинговым запретом просто отказаться от поддержки и сломать так много существующего программного обеспечения.

Microsoft давала намеки на версию Office с управляемым кодом со встроенным VSTO (предположительно таким же образом, как VB6 IDE интегрирована для VBA, поэтому VS IDE будет интегрирована для VSTO) с момента первого выпуска .NET.

Учитывая, насколько много кода требуется - и учитывая, что это не приведет к появлению каких-либо функций, которые были бы видны пользователям, - я очень сомневаюсь, что это занимает одно из первых мест в списке приоритетов Microsoft. Я могу представить, что они накладывают управляемый кодовый набор объектов поверх существующей кодовой базы (так же, как Джоэл Спольски накладывает набор COM-объектов на существующую кодовую базу C, когда в первую очередь помещает VBA в Excel) и запирают новую IDE. in по умолчанию, скрывая старый. Даже это было бы серьезным упражнением (представьте, что вы пишете макрорекордер!). Конечно, это сделало бы .NET предварительным требованием для Office, которое команда Office примет только под дулом пистолета.

Конечно, они никогда не удалят VBA из продуктов - Excel по-прежнему поддерживает макросы Excel 4, а Word по-прежнему имеет объект автоматизации WordBasic для поддержки макросов Word 6, и нет никаких признаков того, что они удаляются, поскольку их слишком много. унаследованный код для поддержки - и никто не использовал ни одну из этих моделей кодирования за десять лет.

Если Microsoft когда-либо поместит среду .NET в Office (что, честно говоря, я сомневаюсь, когда-либо произойдет), они могут перестать добавлять поддержку VBA для новых функций Office. Это самое близкое к тому, чтобы прекратить поддержку VBA.

Вот комментарий от Microsoft относительно будущей поддержки VBA. Короче говоря, он не исчезнет в версиях Office для Windows (но больше не поддерживается для версий Mac).

VBA еще далеко не обесценился, на самом деле VBA нужно повторно ввести в следующую версию Office на MAC (http://www.microsoft.com/presspass/press/2008/may08/05-13MacBU2008PR.mspx).

Для большинства людей на местах VBA и C XLL (и VB6 !!) по-прежнему являются предпочтительными инструментами. Текущие связи .NET работают медленно и не дают прироста производительности. Инструменты третьей части, такие как ExcelDNA, несколько облегчают боль, но, очевидно, неуправляемая кодовая база Office на основе C (и на ассемблере) нелегко сочетается с .NET.

Надстройки VBA немного сложнее развертывать, но VSTO - еще больше. Кроме того, VSTO требует дополнительных затрат, так как перед запуском кода необходимо запустить среду CLR.

Но самое главное; VSTO избавляет от необходимости писать VBA.