При компиляции не видит подключённых dll через references

[egater]

При компиляции не видит подключённых dll через references. Работаю в ax2009,dll написана на c#. Подключаю dll как в примере Dynamics и .net (Dot net rocks)

[gl00mie]

а компиляция происходит на том же хосте, где лежит добавленная в references DLL? и где именно она лежит, в GAC или в каталоге bin клиента?

[egater]

Данная dll лежит в bin клиента, также пробовал добавить через GAC.В обоих случаях references, в коде компилятор подсвечивает как не существующий объект.

[egater]

1)Добавляю библиотек в gas слой
gacutil /i mydll.dll

2)На всякий случай регистрирую типы r
regasm mydll.dll
3)Создаю в аксапте в узле references создаем ссылки на protobuf-net.dll и DiadocApi.dll
В итоге в текстовом редакторе при попытке обратиться к dll он подсвечивает ее название как не существующий объект.
Может я пропустил какое то действие?

[pedrozzz]

Цитата:

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

3)Создаю в аксапте в узле references создаем ссылки на protobuf-net.dll и DiadocApi.dll
В итоге в текстовом редакторе при попытке обратиться к dll он подсвечивает ее название как не существующий объект.
Может я пропустил какое то действие?

В SDK Диадока идет 3 библиотеки (DiadocApi.dll, protobuf-net.dll и Newtonsoft.Json.dll), чтобы использовать Диадок API из Аксапты, надо, чтобы все три библиотеки были или в каталоге bin или в GAC. В references потом достаточно добавить только DiadocApi.

При этом обращение к библиотеке идет через пространство имен Diadoc, т.е.

Diadoc.Api.DiadocApi  api  = new Diadoc.Api.DiadocApi(...)

[jonny]

Библиотека должна быть strong named , для использования в аксапте. Но этого мало, как то мучился с самописной dll, заработало только после того как добавил ее в узел Polisy Assemblies в .Net Framework 2.0 Configuration (утилита такая). Добавлять можно через интерфейс, можно через командную строку

[gl00mie]

Для успешной компиляции X++ надо, чтобы клиент "видел" сборку, на которую ссылается код. Если компиляция будет запускаться на хосте AOS'а, то достаточно зарегистрировать сборку в GAC, если же она будет запускаться на другом хосте, то на нем также должна быть эта сборка - в GAC либо в bin клиента, которым будет компилироваться код.

[Sergikrus]

Цитата:

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

Для успешной компиляции X++ надо, чтобы клиент "видел" сборку, на которую ссылается код. Если компиляция будет запускаться на хосте AOS'а, то достаточно зарегистрировать сборку в GAC, если же она будет запускаться на другом хосте, то на нем также должна быть эта сборка - в GAC либо в bin клиента, которым будет компилироваться код.

У меня следующая ситуация, есть сборка, которую я зарегил в GAC на AOS, компиляция проходит, код исполняется, работает. Устанавливаю клиентское приложение сотруднику, при исполнении кода возникает ошибка Объект "CLRObject" не может быть создан ругается на строчку где объявлена эта сборка в classDeclaration. Если эту сборку положить в bin клиента, то все работает. Как бы должно быть достаточным регистрации в GAC, но нет!

[gl00mie]

.NET-сборка - это в общем случае кусок исполняемого кода. Очевидно, что кусок исполняемого кода должен располагаться там, где он исполняется (если не рассматривать вариант запуска с сетевой шары). Поэтому если у вас есть серверный код, использующий сборку, то достаточно зарегистрировать ее в GAC на всех хостах AOS'ов, если же сборку использует клиентский код, то она должна быть доступна на всех хостах, где запускается клиент Аксапты.
GAC - это сугубо локальный ресурс, к которому имеют доступ только локально выполняющиеся приложения. Чтобы сборка, зарегистрированная в GAC, была доступна на компе "сотрудника", она и зарегистрирована должна быть на компе "сотрудника", а не только на хосте AOS'а, где вы запускаете компиляцию кода.

[offenmeier]

в любом случае, когда я компилирую на сервере код, и он не компилируется из-за какого-то компонента из DLL, и я уверен, что все нужные DLL либо в bin сервера, либо в bin клиента, либо в assembly папке на сервере, а ещё лучше везде где только можно, то я поступаю так:

- остановить АОС
- убить AOI (если 2009 аксапта или более ранняя. если 2012, стереть всю папку с XppIL)
- запустить АОС
- полная компиляция (и CIL, если 2012)

если всё равно не видит, перезапустить сервер.

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

[alicedr]

У меня аналогичная ситуация с AX2012CU13. Есть:
а) своя библиотека "MyDll" написанная для .Net 4.5.2, которая использует библиотеки:
б) Newtonsoft 6.0.8 под .Net 4.5
в) и еще одну, SDK под .Net 4.5.2, назовем ее SDKDll

Все три библиотеки:
1) скопированы в папку C:\Program Files (x86)\Microsoft Dynamics AX\60\Client\Bin
2) скопированы в папку C:\Program Files\Microsoft Dynamics AX\60\Server\MyDEV\bin
3) добавлены в GAC (практика показывает что этот шаг необязателен)
4) перегрузка АОСа с очисткой AUC файлов.
5) добавлены в АОТ как референс. Пробовали добавлять выбирая из списка, выполняя "Browse" и выбирая библиотеку в папке клиента/или в папке сервера
6) создаем новый джоб в АОТ, начинаем писать Newtonsoft, и видим что Аксапта видит библиотеку.
7) создаем новый джоб в АОТ, начинаем писать MyDll, и ничего.
8) при попытке скомпилировать переменную использующую референс на MyDll, получаем ошибку "Variable MyDll has not been declared."

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

На сервере где библотека не опознается, пробовали следующее:
- обновить .net до версии 4,7,2
- обновить .net до версии 4,8
- установить VS redistributable package
- установить VS Studio 2013 Update 4
- установить MS Dynamics VS Tools
- перегрузка сервера
- очистка папки XPPIL и последующий full CIL
- полная компиляция через axcompile и из АХ клиента
- полный СИЛ
- синхронизация базы данных
- перенос проекта с библиотекой в Визуал Студию 2013 из более поздней версии и создание библиотеки из VS2013.
- VS2010 не поддерживает .net 4.5.2 и мы просто не сможем использовать имеющийся SDK
- использование подписанной и неподписанной библиотеки (strong name)
- использование фукции hot-swap для библиотек в настройках АХ сервера

Воз и ныне там.

Наблюдения:
1) На одном из старых серверов в папке клиента и сервера не было библиотеки Newtonsoft. Достаточно было ее скопировать в вышеуказанные папки, добавить референс в АОТ и она моментально стала доступной в коде.
2) Также мы нашли версию "MyDll.dll" написанную несколько лет назад. Исходный код затерялся. Так вот эта библиотека становится видимой так же как и Newtonsoft. Сравнение этой старой версии и новой версии в VS Object browser не показало никаких видимых различий. Target .Net framework для обоих библиотек = 4.5.2

Вопросы:
1) ?????
2) что нужно сделать чтобы библиотека стала видимой для компиляции?
3) что не хватает библиотеке (или что лишнее) чтобы она мгновенно опознавалась Аксаптой, как Newtonsoft?

[alicedr]

Ни у кого нет идей? Там про regasm, fuglovw или папку vsassemblies? Или тема не видна/игнорируется из-за количества комментов/просмотров и нужно создать новую (что типа против правил форума)?

[Товарищ ♂uatr]

Добрый вечер.
Ситуация вполне типичная в рамках различных сред развертывания решения.
То, что проблема возникает на этапе компиляции, говорит о том, что именно клиентское приложение не видит библиотеку. Поэтому наличие библиотеки на стороне сервера здесь не влияет на наличие данной проблемы и на этом внимание акцентировать не стоит.
А на чем стоит акцентировать внимание - единственное ли клиентское приложение используется для компиляции кода на серверах. Вариативность здесь невелика:
1. либо на какой-то конкретной машине клиент не видит целевых библиотек - ищите проблемную машину. Это либо конфигурационный файл клиента, либо действительно не хватает нужных библиотек.
2. либо все клиенты не могут выполнить компиляцию - обратите внимание на тип архитектуры подключенной библиотеки и её зависимостях..

Однако, самым эффективным решением здесь будет использование ПО от sysinternals - process monitor, запустите и смотрите куда Аксапт "лезет" за библиотеками. Так же, логично, проанализировать зависимости у этих трех библиотек, возможно они требуют каких-то дополнительных компонентов.

[alicedr]

Спасибо за идею!
sysinternals - process monitor действительно интересная штука. Подвязавшись под ax32.exe вижу некоторую активность при добавлении референса, но абсолютно ничего относящегося к библиотеке при компиляции.