Различные Excel CLSID для Excel вызывают проблемы с Interop в C# программе
В основном мне просто нужно знать разницу между этими 2 CLSID. У меня есть сервер, чистая установка, недавно с офисом. В DCOM под приложением Excel у меня есть APPID {00020812-0000-0000-C000-000000000046}. Я установил конкретные удостоверения и разрешения на запуск для этого AppID.
Когда я запускаю свое приложение, которое конвертирует файл Excel, я получаю:
Ошибка: не удалось получить фабрику класса COM для компонента с CLSID {00024500-0000-0000-C000-000000000046} из-за следующей ошибки: 8000401a Не удалось запустить процесс сервера, поскольку настроенный идентификатор указан неверно. Проверьте имя пользователя и пароль.
Я посмотрел этот идентификатор CLSID, это также GUID приложения Excel. Это не то, что указано в DCOM, хотя. Так что я думаю, что у меня здесь конфликт? Возможно разные версии office или x86 vs x64 archs, конкурирующие друг с другом на одной коробке, возможно?? Я не уверен, как мне установить 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 SDKs\Windows\v7.0\Samples\com\ фундаменты \dcom\dcomperm). Этот инструмент работал. Нет больше ошибки идентификации.
Я не получил ошибку со старым инструментом DcomPerm, но почему-то он не все правильно подключил. Очевидно, что Interop - это некое корпоративное решение, и все это имеет смысл.
1 ответ
Вам нужно использовать компоненты, предназначенные для выполнения на стороне сервера (например, такие как Aspose) или просто использовать Open XML SDK в случае открытых файлов XML (.xslx и т. Д.), См. Добро пожаловать в Open XML SDK 2.5 для офиса для получения дополнительной информации.
Как упоминалось в комментариях ранее, Microsoft в настоящее время не рекомендует и не поддерживает автоматизацию приложений Microsoft Office из любых необслуживаемых неинтерактивных клиентских приложений или компонентов (включая ASP, ASP.NET, DCOM и NT Services), поскольку Office может демонстрировать нестабильное поведение и / или тупиковую ситуацию при работе Office в этой среде.
Если вы создаете решение, работающее в контексте сервера, вы должны попытаться использовать компоненты, которые были сделаны безопасными для автоматического выполнения. Или вы должны попытаться найти альтернативы, которые позволяют хотя бы части кода работать на стороне клиента. Если вы используете приложение Office из серверного решения, приложению не хватит многих необходимых возможностей для успешной работы. Кроме того, вы будете рисковать стабильностью вашего общего решения.