Мне было поручено создать инструмент финансового планирования в Excel, который выиграет от некоторых пользовательских функций/макросов.
Моя первоначальная реакция заключалась в использовании VBA. Я использовал его для управления Excel раньше (скажем, 5 лет назад). Но потом я начал задаваться вопросом, лучше ли мне использовать VSTO.
У кого-нибудь есть опыт использования обоих техников и можно перечислить плюсы и минусы, чтобы я мог оценить, какой курс будет лучше.
Я бы посоветовал вам придерживаться VBA для стандартной разработки с помощью Excel и изучать .NET на этой стороне. Использование .NET - это, безусловно, следующий шаг, но это значительно упрощает разработку Excel.
Кроме того, VSTO не позволяет создавать пользовательские функции рабочего листа ( "UDF" ), поэтому для этого вам понадобится внешний интерфейс VBA или создать управляемую надстройку COM без использования VSTO. Для сравнения, VBA позволяет создавать UDF практически без усилий.
Использование .NET имеет много преимуществ, в основном в отношении строгого набора, полных возможностей ООП и возможности организации проектов большего размера. но VBA имеет огромные преимущества перед .NET, когда дело доходит до развертывания, что довольно сложно с Excel при работе с .NET или VSTO. VBA также является более легким языком, чтобы учиться и начинать с.
В целом, я бы предложил использовать VBA для повседневной разработки, но изучите VB.NET или С# на стороне, чтобы ваши навыки программирования могли расти за пределами арены Excel. В конце концов, ваши навыки .NET могут стать достаточно сильными, чтобы вы предпочли использовать его по сравнению с VBA, но в этот день вам придётся стать хорошим .NET.
(Для другого аналогичного мнения об этом см. Я могу потерять преимущества записи макросов, если я разрабатываю приложения Excel в Visual Studio?.
Изменить: обновить комментарий к Энди, ниже:
Такие проблемы, как развертывание, отладка и UDF были теми, что я искал информацию для сравнения на. Судя по ответам на вопрос, я должен был упомянуть, что У меня 5+ лет опыта работы с С#, тогда как мои навыки VBA (или отсутствие из них) выходят только 3-4 раза в десятилетие.
Хорошо, да, ты должен был сказать! Большинство людей с такими вопросами, как программисты VBA, которые хотят попасть в .NET. Поэтому я неправильно понял.
В вашем случае вы должны использовать С#, но я бы настоятельно предложил использовать С# 4.0 для Visual Studio 2010 для этого, он значительно улучшит синтаксис, который требуется при работе с объектной моделью COM, например Excel. VS 2010 в настоящее время находится в бета-версии 2, а дата RTM установлена на 12 апреля, поэтому мы почти там.
Что касается развертывания, то с вашим опытом я не думаю, что у вас будет слишком много проблем с пакетами установки и т.п., а Visual Studio Tools for Office (VSTO) искусно хороша для двух вещей:
Создание настраиваемой ленты для вашей надстройки с помощью конструктора перетаскивания. Без конструктора drag-and-drop вы должны предоставить XML вместо этого. XML прекрасно подходит, если вы спросите меня, но разработчик drag-and-drop действительно мечтает использовать
Использование элементов управления .NET на листе. Я не знаю, является ли это частью того, что вы планируете делать, но VSTO позволяет использовать элементы управления .NET на рабочем листе. Это действительно хорошая возможность для .NET-программиста, поскольку эти элементы управления немного более гладко выглядят и специально разработаны для работы с .NET.
К сожалению, VSTO доступен только для Excel 2003 и выше, и я думаю, что вам нужно создать отдельные надстройки для Excel 2003 и Excel 2007. С другой стороны, можно создавать управляемые COM-надстройки, созданные без использования VSTO совместимый для Excel 2000 и выше без труда. Наконец, VSTO не поддерживает создание UDF и, следовательно, вам придется либо создать надстройку управляемой автоматизации для этого, либо использовать интерфейс VBA, который вызывает ваши функции VSTO.
В целом, я бы пошел с VSTO, если вы можете ограничить себя Excel 2007 и выше. Я бы рассмотрел VSTO, если ваши требования к Excel 2003 и выше. И я бы пошел с управляемой надстройкой COM, если вам нужно работать в версиях Excel 2000 и выше.
Для поддержки UDF я бы создал управляемую надстройку автоматизации, которая была бы жизнеспособной для Excel 2002 и выше. Если вам нужны UDF в Excel 2000 или ниже, вам понадобится внешний интерфейс VBA, который вызывает COM-видимые методы в вашей сборке .NET.
Это основные pro и con, как я вижу. Дайте мне знать, если вам нужно знать больше.
- Майк
Учитывая ваше знакомство с С#, я бы рекомендовал вам посмотреть Addin Express (затраты) и Excel DNA (бесплатно), а также VSTO. Addin Express имеет версию нейтрального PIA, которая упрощает развертывание, может обрабатывать обе функции и команды и может использовать интерфейсы Automation и XLL (XLL намного быстрее, чем автоматизация). Excel DNA более оптимизирован к интерфейсу XLL, но отлично подходит для разработки функций листа.
Отказ от ответственности: у меня нет никакой связи с помощью Addin Express или Excel DNA
Я не думаю, что в коде VBA в Excel есть что-то непоправимое. Это имеет преимущество работы в пространстве процессов excel, а взаимодействие VBA с объектной моделью Excels очень простое. Однако вы (и ваши пользователи) должны действительно думать о своем инструменте как надстройке Excel.
Если вы хотите, чтобы у вашего инструмента была отдельная идентификация, отличная от Excel, тогда вам будет предоставлена автоматизация. Это немного медленнее (вы "вышли из процесса" ), а объектная модель немного менее чиста, но ваш инструмент будет иметь свою личность.
(обратите внимание, если вы используете С#, и если у вас есть опция VS2010 и С# 4, есть куча усовершенствований автоматизации, которые стоят обновления)
SpreadsheetGear for.NET позволяет добавить компонент таблицы Excel, совместимый с Excel, в ваши .NET(WinForms, ASP.NET и т.д.). ) приложений без нижних дескрипторов (производительность, простота использования) COM Interop.
Вы можете узнать больше об элементе управления электронной таблицей SpreadsheetGear Windows Forms здесь, см. живые примеры ASP.NET здесь и загрузите бесплатную пробную версию здесь, если вы хотите попробовать сами.
Отказ от ответственности: у меня есть SpreadsheetGear LLC
Здесь много замечательных ответов, поэтому я постараюсь сделать то, что еще не было сделано. Я бы придерживался VBA. Есть много причин, но основными факторами для меня были бы:
Однако VBA явно не очень защищен, поэтому, если у вас есть код, который вы хотите скрыть, лучше всего пойти с .Net probobly.