Различные CLSID excel для Excel вызывают проблемы с Interop в программе C#

В основном мне просто нужно знать разницу между этими двумя CLSID. У меня есть сервер, чистая установка, новый образ с офисом. В DCOM в приложении Excel у меня есть APPID {00020812-0000-0000-C000-000000000046}. Я установил для этого идентификатора приложения определенные права доступа и разрешения на запуск.

Когда я запускаю свое приложение, которое конвертирует файл Excel, я получаю:

Ошибка: не удалось получить фабрику классов COM для компонента с CLSID {00024500-0000-0000-C000-000000000046} из-за следующей ошибки: 8000401a Не удалось запустить серверный процесс, поскольку настроенное удостоверение неверно. Проверьте имя пользователя и пароль.

Я посмотрел этот идентификатор CLSID, это также GUID приложения Excel. Однако это не то, что указано в DCOM. Я так понимаю, у меня тут конфликт? Возможно, разные версии офиса или архитектуры x86 и x64 конкурируют друг с другом на одной и той же коробке?? Я не уверен, как я должен установить Identity User на {00024500-0000-0000-C000-000000000046}, поскольку он не указан в DCOM. Я посмотрел вокруг, но не нашел много на эту тему. Любая помощь будет принята с благодарностью.

Небольшое обновление по этой проблеме с исправлением!!!!!

Хотя я был готов принять ответ ниже, поскольку взаимодействие - это плохая автоматизация для серверных приложений/служб. Я знаю, что это правда. Оказывается, в моем случае у меня была плохая утилита dcomperm.exe, которую я откуда-то взял. У меня были проблемы с установкой Windows 7 .NET 4.0 SDK, поэтому вместо того, чтобы бороться с этой проблемой, я где-то взял скомпилированный DcomPerm из Интернета. Плохая идея. Сегодня утром я нашел способ обойти проблему установки SDK. Затем я смог скомпилировать свой собственный инструмент DcomPerm.exe из справочника SDK (C:\Program Files\Microsoft SDK\Windows\v7.0\Samples\com\fundamentals\dcom\dcomperm). Это средство сработало. Нет больше ошибки идентификации.

Я также не получал ошибок со старым инструментом DcomPerm, но почему-то он не все правильно подключал. Очевидно, что с учетом того, что Interop является своего рода обидчивым, не корпоративным решением, все это имеет смысл.


.net c# excel office-interop dcom
person Puerto    schedule 29.06.2016    source источник
comment
Вы запускаете эту программу внутри службы или внутри IIS? Если это так, вы можете прочитать статью базы знаний Соображения по автоматизации Office на стороне сервера, есть много проблем, с которыми вы можете столкнуться, и похоже, что вы столкнулись с одной из них. Короткая версия переключается на Open XML SDK, если это возможно, она может читать xlsx-файлы и не имеет проблем, связанных с COM-взаимодействием.   -  person Scott Chamberlain    schedule 29.06.2016
comment
Это сервисное приложение. И я согласен, Interop отстой. Но пока это должно остаться. Вот основная проблема: если я зайду в DCOM, изменю пользователя на интерактивного, а затем изменю пользователя обратно на конкретного пользователя, с которым я изначально настроил сервер, я больше не получаю ошибку. Я должен упомянуть, что изначально я использую DcomPerm.exe для настройки учетной записи пользователя. Кажется, это работает нормально. Поэтому я просто не уверен, что происходит, когда я устанавливаю пользователя в графическом интерфейсе, по сравнению с тем, когда я устанавливаю пользователя программно, используя инструмент командной строки.   -  person Puerto    schedule 29.06.2016
comment
Инструмент взаимодействия требует, чтобы профиль пользователя был загружен для работы, изменение пользователя и его изменение обратно сохраняет профиль загруженным после того, как вы измените его обратно. См. пункт «Идентификация пользователя» в статье базы знаний, на которую я ссылаюсь. И просто напомню вам, что также с этой страницы Microsoft в настоящее время не рекомендует и не поддерживает автоматизацию приложений Microsoft Office из любого автоматического неинтерактивного клиентского приложения или компонента (включая ASP, ASP.NET, DCOM, и NT Services), так как Office может демонстрировать нестабильное поведение и/или зависание при запуске Office в этой среде.   -  person Scott Chamberlain    schedule 29.06.2016
comment
Вы сказали, что взаимодействие должно остаться, но почему оно должно оставаться? какую функцию взаимодействия вы используете, которая недоступна вам в Office Open XML SDK (например, нужна ли вам поддержка файлов .xls)? Если бы вы могли указать, почему мы можем помочь вам найти обходной путь, который заставит работать эту конкретную функцию, не заставляя работать все взаимодействие.   -  person Scott Chamberlain    schedule 29.06.2016
comment
Это инструмент преобразования. OpenXML работает намного лучше для офисных файлов xlsx и docx. Но через этот движок преобразования мы получаем действительно старые вещи. Word 6.0, Excel 5.0 и т. д. Новые библиотеки взаимодействия могут читать эти старые версии Office. Я действительно не пытаюсь здесь защищать Интероп, я его ненавижу. У меня просто нет другого решения на данный момент. И даже если бы я это сделал, потребовалось бы много времени, чтобы внедрить изменение и выпустить его в производство в моей среде. Но я весь в ушах. Спасибо за вклад, Скотт!   -  person Puerto    schedule 29.06.2016

Ответы (1)


arrow_upward
1
arrow_downward

Вам нужно использовать компоненты, предназначенные для выполнения на стороне сервера (например, такие, которые предоставляет Aspose) или просто использовать Open XML SDK в случае открытых файлов XML (.xslx и т. д.), см. Добро пожаловать в Open XML SDK 2.5 для Office для получения дополнительной информации.

Как упоминалось в комментариях ранее, Microsoft в настоящее время не рекомендует и не поддерживает автоматизацию приложений Microsoft Office из любого автоматического неинтерактивного клиентского приложения или компонента (включая ASP, ASP.NET, DCOM и службы NT), потому что Office может демонстрировать нестабильное поведение и/или взаимоблокировку при запуске Office в этой среде.

Если вы создаете решение, работающее в контексте на стороне сервера, вы должны попытаться использовать компоненты, которые были сделаны безопасными для автоматического выполнения. Или вы должны попытаться найти альтернативы, которые позволяют хотя бы части кода выполняться на стороне клиента. Если вы используете приложение Office из решения на стороне сервера, у приложения не будет многих необходимых возможностей для успешной работы. Кроме того, вы рискуете стабильностью всего решения.

person Eugene Astafiev    schedule 29.06.2016