Сохранение документа Excel

[Soup]

Подскажите пожалуйста, может кто в курсе,как сохранить документ Excel(объект класса ComExcelDocument_RU) по необходимому мне пути?
Спасибо!

[MikeR]

Собственно надо выполнить следующее

excelWorkBook.SaveAs(_fileName);

а в ComExcelDocument_RU добавить метода типа getexcelWorkBook()
это можно посмотреть из макроса при сохранении документа

[Gustav]

Ну, или прямо к "документу" в нужном месте привязаться, если лень добавлять getexcelWorkBook().
m_comDocument по сути и есть WorkBook:

m_comDocument.SaveAs(_fileName);

[gl00mie]

Подниму старую тему. В 2009-й понадобилось сделать так, чтобы отчеты в виде Excel-файлов могли формироваться в пакетном задании, выполняемом на сервере. Понятное дело, ComExcelDocument_RU сразу пошел лесом, потому что не инкапсулирует конструктор, работает через COM и объявлен как клиентский класс, но дело не в этом. Пакетник крутится на Windows Server 2008 R2 (64-битном - других R2 не бывает), и вот стала в пакетном задании на вызове SysExcelWorkbook.SaveAs() стабильно вылезать ошибка, мол, метод завершен неверно. "Я его и так, и эдак, со словами и без слов", провозился не один день с вариантами вызова метода, а дело оказалось вот в чем: в системном профиле виндов в Windows Server 2008 (обычном и R2) какого-то фига не стало каталога Desktop - может, разработчики виндов посчитали, что он больше не нужен или еще что... Если этот каталог создать, то ошибка на вызове SaveAs() волшебным образом пропадает! Соотв., нужно создать каталог

• для Windows 2008 Server x64 (включая R2) - вот тут:

  %SystemRoot%\SysWOW64\config\systemprofile\Desktop

• для Windows 2008 Server x86 - вот тут:

  %SystemRoot%\System32\config\systemprofile\Desktop

[Damn]

Я так понимаю, что ошибка также не будет возникать если в данном случае использовать Microsoft Office 2010 64bit. У меня серверные пакетные задания корректно сохраняют файлы *.xls без каталога %SystemRoot%\SysWOW64\config\systemprofile\Desktop на сервере.
C Office 2007 тоже долго мучился пораньше бы ваше сообщение.

[gl00mie]

Если вдруг кому взбредет в голову запускать AOS под непривилегированным пользователем и создавать на нем файлы Excel - так, чтобы Excel запускался на сервере, то его ждут новые приключения, связанные с правами доступа. Для теста я использовал простой джобик:

SysExcelApplication xl;
SysExcelWorkbook    wbk;
;
xl = SysExcelApplication_NET::construct( ClassRunMode::Server );
xl.visible( false );
wbk = xl.workbooks().add();
wbk.saveAs( DEV_xInfoDirectoryServer( DirectoryType::Temp ) + 'test.xls' );
xl.quit();

Здесь:

• SysExcelApplication_NET - это переписанная на .NET обертка для работы с Excel, умеющая работать в т.ч. на сервере, см. тему Взаимодействие с Excel через .NET (семейство классов SysExcel)
• DEV_xInfoDirectoryServer - обертка для xInfo::directory() в Global, выполняемая явно на сервере и возвращающая пути такими, как их видит AOS

Так вот, первое, с чем приходится столкнуться, - это что создание экземпляра SysExcelApplication_NET на сервере валится с ошибкой, при этом в eventlog создается сообщение вида

Цитата:

The machine-default permission settings do not grant Local Activation permission for the COM Server application with CLSID {00024500-0000-0000-C000-000000000046} and APPID Unavailable to the user DOMAIN\AX2009AosUser from address LocalHost (Using LRPC). This security permission can be modified using the Component Services administrative tool.

Все бы хорошо, но в апплете Component Services ни разу не видать чего-либо, похожего на CLSID {00024500-0000-0000-C000-000000000046}.

ШАГ 1. Идем в редактор реестра и добавляем туда что-то вроде этого (ветка HKCR\CLSID\{00024500-0000-0000-C000-000000000046} там уже есть):

REGEDIT4

[HKEY_CLASSES_ROOT\CLSID\{00024500-0000-0000-C000-000000000046}]
"AppID"="{00024500-0000-0000-C000-000000000046}"

[HKEY_CLASSES_ROOT\AppID\{00024500-0000-0000-C000-000000000046}]
@="Microsoft Excel"

Теперь в Component Services\Computers\My Computer\DCOM Config мы видим "Microsoft Excel" и можем специально для него добавить права (Local Access, Local Launch, Local Activation) для группы, в которой собраны учетные записи AOS'ов:

Здесь я исхожу из того, что на вкладке Identity мы выбрали запуск DCOM-сервера под тем пользователем, который собственно его запускает (The launching user) - это логично, раз мы решили ограничить права самого AOS'а.
Теперь как минимум экземпляр SysExcelApplication_NET у нас создается, и под тем пользователем, под которым работает AOS, запускается процесс Excel.exe. Однако, на строке добавления новой книги Excel у нас вылетает исключение Exception::CLRError без какого-либо текста сообщения. Его причина заключается в том, что Excel хоть и запускается под нашим непривилегированным пользователем, но пытается получить доступ на изменение к ряду каталогов в %SystemRoot%\SysWOW64\config\systemprofile.

ШАГ 2. На каталоги

Цитата:

%SystemRoot%\SysWOW64\config\systemprofile\AppData\Local\Microsoft\Windows\Temporary Internet Files
%SystemRoot%\SysWOW64\config\systemprofile\Desktop

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

[gl00mie]

Описанная выше настройка была приведена для случая, когда 64-битный локальный процесс пытается активировать COM-сервер через DCOM, однако, если это пытается сделать 32-битный локальный процесс, приведенный способ настройки может не сработать (коллега тут наступил недавно на эти грабли). Оказывается, если нужно настроить права для работы 32-битных локальных приложений под 64-битными виндами, может потребоваться выполнять настройку из 32-битной же версии Management Console. Чтобы ее запустить, необходимо в в ком.строке указать параметр "-32" (запуск mmc без параметров из-под 32-битнго приложения в моем случае эффекта не дал), после чего добавить остастку Component Services и там уже настраивать права

[FreeD]

Добрый день. Подскажите пожалуйста, что делать с ошибкой -
"COM-объект класса "Excel.Application" не удалось создать. Убедитесь, что объект был должным образом зарегистрирован на компьютере "user1".".
На локальной машине?
На соседней машине работает.

[Товарищ ♂uatr]

Цитата:

Сообщение от FreeD

"COM-объект класса "Excel.Application" не удалось создать. Убедитесь, что объект был должным образом зарегистрирован на компьютере "user1".

Добрый день!
Программный код выполняется на сервере? Если это так, то в данном контексте речь именно о AOS и настройки необходимо выполнять именно на нем.
Действия изложенные gl00mie несколькими сообщениями выше в "ШАГ 1" (как правило, в реестре не нужно вносить каких-либо поправок) в "DCOM Config" (настраиваем доступ для логина Business Connector'a) решают данную ошибку.

Однако, вслед за ней возникает новая. Ее возможно решить настроив доступ к каталогам изложенным gl00mie в ШАГ 2.

[alex55]

Цитата:

Сообщение от gl00mie

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

Спасибо за инструкцию. Пытаюсь по ней настроить создание файла Word из AX4 через business connector. IIS работает под Local System, приложение в нем под нужным пользователем. По ходу настройки из лога исчезла исходная ошибка об отсутствии permission, но ошибка создания COM-объекта по прежнему повторяется. Причем даже если сейчас права у пользователя убрать, DCOM ошибка в логе почему-то не возникает.

Напрягает момент что в DCOM-настройках для Word на закладке Location невозможно поставить флаг Run application on this computer. Обязательна ли его установка? Пытался жестко прописать через имя текущего сервера, но не помогло. Офис 32-битный, винда 64-битная. Настраиваю через mmc comexp.msc /32 под админом.

Еще хотел уточнить для чего предполагалось настраивать %SystemRoot%\SysWOW64\config\systemprofile\AppData\Local\Microsoft\Windows\Temporary Internet Files? И правильно ли я понимаю что при моей конфигурации каталог Desktop нужно в System32 создавать?

[alex55]

Цитата:

Сообщение от alex55

Причем даже если сейчас права у пользователя убрать, DCOM ошибка в логе почему-то не возникает.

Напрягает момент что в DCOM-настройках для Word на закладке Location невозможно поставить флаг Run application on this computer. Обязательна ли его установка?

Эти вопросы снимаю, немного со значениями в реестре напутал. Сейчас вижу что процесс WINWORD.exe стартует и висит под нужным пользователем, но при этом ошибка все равно еще остается:

"COM-объект класса "Word.Application" не удалось создать. Убедитесь, что объект был должным образом зарегистрирован на компьютере... Объект "COM" не может быть создан
Ошибка времени выполнения: COM Объект не инициализирован."

(C)\Classes\COM\error
(C)\Classes\ComOfficeDocument_RU\getCOMErrorMsg - line 7
(C)\Classes\ComOfficeDocument_RU\initApplication - line 28
(C)\Classes\ComOfficeDocument_RU\newFile - line 8

Возможно как раз с каталогами связано, хотя Desktop в обеих каталогах создал и права на него раздал.

[Logger]

Попробуйте зайти под эти пользователем на комп и запустите word и excel.
Вдруг им еще чего то недостает, а так они сами создадут.

[alex55]

Цитата:

Сообщение от alex55

Сейчас вижу что процесс WINWORD.exe стартует и висит под нужным пользователем, но при этом ошибка все равно еще остается:

"COM-объект класса "Word.Application" не удалось создать. Убедитесь, что объект был должным образом зарегистрирован на компьютере... Объект "COM" не может быть создан
Ошибка времени выполнения: COM Объект не инициализирован."

В итоге нормально заработал только вариант когда на закладке Identity в настройках DCOM жестко задан нужный пользователь. Не уверен что возможны работающие альтернативы для данной конфигурации.

Цитата:

Сообщение от Logger

Попробуйте зайти под эти пользователем на комп и запустите word и excel.
Вдруг им еще чего то недостает, а так они сами создадут.

Заходил, запускал, никаких проблем не заметил в интерактивном режиме под данным пользователем.

[gl00mie]

Цитата:

Сообщение от alex55

для чего предполагалось настраивать %SystemRoot%\SysWOW64\config\systemprofile\AppData\Local\Microsoft\Windows\Temporary Internet Files? И правильно ли я понимаю что при моей конфигурации каталог Desktop нужно в System32 создавать?

При запуске через DCOM процесс офисного 32-битного приложения (Word/Excel) использует системный профиль пользователя, который хранится не в %SystemRoot%\Users\<userId>, а в %SystemRoot%\SysWOW64\config\systemprofile\. Word/Excel зачем-то используют каталоги Desktop и Temporary Internet Files, без них он может не запуститься либо не создать файл. При этом для варианта настройки Identity == The launching user сам процесс запускается под учеткой того пользователя, который активирует офисное приложение через DCOM. Из этого выходит, что для нормальной работы нужно дать этому пользователю доступ на указанные каталоги в системном профиле.
В Windows Server 2012 и выше для успешного запуска через DCOM 32-битных офисных приложений также нужно самостоятельно создать каталог %SystemRoot%\SysWOW64\config\systemprofile\Desktop.

[Logger]

Добавлю еще для полноты картины
Вывод в Excel на сервере

Цитата:

Еще нашел для MS Office 2010, что надо добавить в папку C:\Windows\System32\config\systemprofile\AppData\Local\Microsoft\
папку Shemas и дать на нее права .Net BusinessConnector'у

[Logger]

Цитата:

Сообщение от alex55

В итоге нормально заработал только вариант когда на закладке Identity в настройках DCOM жестко задан нужный пользователь. Не уверен что возможны работающие альтернативы для данной конфигурации.

А у нас все нормально заработало.
Но был странный баг.
Если юзер админ, то все работает.
Если выкинуть из админов, то такая ошибка:

Цитата:

The server {00024500-0000-0000-C000-000000000046} did not register with DCOM within the required timeout.

причем она происходит на попытке открыть книгу Excel.
Вылечили случайно так:
1. Сделали юзера админом.
2. Залогинились под ним через RDP (тем самым для него создался профиль на сервере)
3. Выкинули юзера из админов, ребутнули сервак.

После этого все работает.
Вероятно папка Desktop в профиле бывает нужна не только для системного профиля но и для учетки, под которой запускается процесс, использующий Excel. Поэтому для нее должен быть создан профиль (но это опять же предположение исходя из симптомов)