Что самое неприятное/странное, что случилось с вами, используя Excel Interop

После разработки с помощью Excel Interop с .Net какое-то время я все больше раздражаюсь тем, сколько "странных вещей" случается - например, этот вопрос, который я опубликовал ранее - My Проблема.
Я ценю, что это не прямой вопрос и не просто совместное использование опыта, но я считаю, что было бы полезно, однако, узнать людей, которые величайшие неприятности/странные вещи, которые у них были, и как они преодолели их. Таким образом, я могу узнать, с какими проблемами я могу столкнуться в будущем:)

Спасибо

Ответ 1

Самая раздражающая особенность Excel interop для меня заключается в том, что каждый раз, когда вы делаете что-либо, он создает COM-объекты за кулисами, но все они нуждаются в утилизации, иначе Excel не будет закрываться при вызове Close(). И если вы пропустите один, часто трудно понять, где.

К счастью, здесь я нашел этот поток, который предлагает несколько способов решения проблемы.

Ответ 2

Вы получите другой Interop, скомпилированный на компьютере с другой версией MS Office.

В основном это означает, что для дополнительной версии для дополнительной версии требуется дополнительная машина (физическая или виртуальная) и дополнительные лицензии Visual Studio, Windows и MS Office.

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

Ответ 3

Извлечение памяти из-за того, что многие открывают разные экземпляры приложений Office.

Тщательное программирование может разобраться, но внутренние ошибки в приложениях могут испортить ваши предположения.

Ответ 4

МОСТ странно - необязательные параметры во всех методах Office. Для меня, как программист С# Missing.Value, как конечно.

например, метод SaveAs принимает 12 аргументов, и требуется только одно из них, и вы получили такой код

result.SaveAs('file',Missing.Value,Missing.Value,Missing.Value,Missing.Value,Missing.Value,Missing.Value,Missing.Value,Missing.Value,Missing.Value,Missing.Value,Missing.Value)

Также подпись зависит от версии межсетевого взаимодействия, каждая крупная версия Excel добавляет некоторые параметры в подпись и полностью уничтожает ваш код.

ref и out также непригодные конструкции.
Одна рекомендация - используйте VB.NET для взаимодействия в офисе - это правильный инструмент для такой вещи или подождите С# 4.0

Ответ 5

Самое неприятное для меня то, что вы получаете, казалось бы, случайные ошибки/исключения/сбои.

Например, мне иногда нужно преобразовать большой набор тысяч книг между форматами (xls/xlsx) из консольного приложения С#. Excel редко обрабатывает все эти книги за один проход без ошибок. Запуск нескольких раз вызывает проблемы с разными файлами. Итак, если a.xls и b.xls находятся в моем наборе файлов, Excel может потерпеть неудачу на a.xls на первом проходе и b.xls на втором проходе.

У машины намного больше места на диске/диске, чем требуется приложениям. Приложение однопоточное, поэтому нет проблемы с несколькими экземплярами Excel, создающих хаос.

Я наблюдал это поведение с Excel 2003 и Excel 2007.

В конечном итоге я модифицировал свое приложение для учета этого факта и отслеживал, какие книги были успешно преобразованы, так что второй проход может очистить беспорядок, оставленный первым проходом.

Ответ 6

Отсутствие поддержки автоматизации...

Тот факт, что вы не можете запускать Excel в автоматизированной или неинтерактивной среде, например, на сервере. Это можно сделать, но не надежно и не без взлома систем, что часто нецелесообразно для среды продуктов. Но это не ограничивается Excel.

Подробнее см. здесь. Я сделал недавнее исследование некоторых альтернатив, которые вы можете найти здесь: Чтение файлов Excel в качестве процесса сервера

Это привело к бесчисленным проблемам для меня и других, и я прочитал много сообщений о Stackoverflow о проблемах, связанных с использованием Excel на сервере. Это просто не стоит хлопать по этому пути, тем более что Vista и выше просто не работают с Office 2k7 через автоматизацию.

Ответ 7

1 - Тот факт, что для записи на лист из другого потока вы должны реализовать IMessageFilter и даже с этим, вы все равно придется ударить его молотком

2 - Как отметил Марк Байерс, "одноточечное правило" ... вздох...

3 - И, конечно, что в ясном месте ЛЮБОЙ из этого помечен так, вместо этого мы должны тралить самые темные углы сети, надеясь наткнуться на какое-то обоснование...

(Andrew Whitechapel, однако, любезно написал множество чрезвычайно полезных статей - спасибо, Андрей, вам просто жаль, что вам пришлось... )