После разработки с помощью Excel Interop с .Net какое-то время я все больше раздражаюсь тем, сколько "странных вещей" случается - например, этот вопрос, который я опубликовал ранее - My Проблема.
Я ценю, что это не прямой вопрос и не просто совместное использование опыта, но я считаю, что было бы полезно, однако, узнать людей, которые величайшие неприятности/странные вещи, которые у них были, и как они преодолели их.
Таким образом, я могу узнать, с какими проблемами я могу столкнуться в будущем:)
Спасибо
Самая раздражающая особенность Excel interop для меня заключается в том, что каждый раз, когда вы делаете что-либо, он создает COM-объекты за кулисами, но все они нуждаются в утилизации, иначе Excel не будет закрываться при вызове Close(). И если вы пропустите один, часто трудно понять, где.
К счастью, здесь я нашел этот поток, который предлагает несколько способов решения проблемы.
Вы получите другой Interop, скомпилированный на компьютере с другой версией MS Office.
В основном это означает, что для дополнительной версии для дополнительной версии требуется дополнительная машина (физическая или виртуальная) и дополнительные лицензии Visual Studio, Windows и MS Office.
При развертывании версии для клиента мне пришлось архивировать образ виртуальной машины для компиляции этой версии, потому что я не мог гарантировать, что буду использовать ту же версию MS Office на моей машине разработки.
Извлечение памяти из-за того, что многие открывают разные экземпляры приложений Office.
Тщательное программирование может разобраться, но внутренние ошибки в приложениях могут испортить ваши предположения.
МОСТ странно - необязательные параметры во всех методах 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
Самое неприятное для меня то, что вы получаете, казалось бы, случайные ошибки/исключения/сбои.
Например, мне иногда нужно преобразовать большой набор тысяч книг между форматами (xls/xlsx) из консольного приложения С#. Excel редко обрабатывает все эти книги за один проход без ошибок. Запуск нескольких раз вызывает проблемы с разными файлами. Итак, если a.xls и b.xls находятся в моем наборе файлов, Excel может потерпеть неудачу на a.xls на первом проходе и b.xls на втором проходе.
У машины намного больше места на диске/диске, чем требуется приложениям. Приложение однопоточное, поэтому нет проблемы с несколькими экземплярами Excel, создающих хаос.
Я наблюдал это поведение с Excel 2003 и Excel 2007.
В конечном итоге я модифицировал свое приложение для учета этого факта и отслеживал, какие книги были успешно преобразованы, так что второй проход может очистить беспорядок, оставленный первым проходом.
Отсутствие поддержки автоматизации...
Тот факт, что вы не можете запускать Excel в автоматизированной или неинтерактивной среде, например, на сервере. Это можно сделать, но не надежно и не без взлома систем, что часто нецелесообразно для среды продуктов. Но это не ограничивается Excel.
Подробнее см. здесь. Я сделал недавнее исследование некоторых альтернатив, которые вы можете найти здесь: Чтение файлов Excel в качестве процесса сервера
Это привело к бесчисленным проблемам для меня и других, и я прочитал много сообщений о Stackoverflow о проблемах, связанных с использованием Excel на сервере. Это просто не стоит хлопать по этому пути, тем более что Vista и выше просто не работают с Office 2k7 через автоматизацию.
1 - Тот факт, что для записи на лист из другого потока вы должны реализовать IMessageFilter и даже с этим, вы все равно придется ударить его молотком
2 - Как отметил Марк Байерс, "одноточечное правило" ... вздох...
3 - И, конечно, что в ясном месте ЛЮБОЙ из этого помечен так, вместо этого мы должны тралить самые темные углы сети, надеясь наткнуться на какое-то обоснование...
(Andrew Whitechapel, однако, любезно написал множество чрезвычайно полезных статей - спасибо, Андрей, вам просто жаль, что вам пришлось... )