AX2009 References сервиса из AX2012

[demianimp]

Прошу помочь.

Создал сервис в AX2012 согласно этой инструкции. После чего добавил в AX2009 ссылку на службу.

Создаю джоб и пытаюсь получить данные из службы. Но аксапта выдает ошибку:
System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.IO.FileNotFoundException: Не удалось найти файл App.config в местоположении сборки на сервере. Наиболее вероятной причиной этого является код, выполняющийся на уровне клиента. Запустите код на уровне сервера.
at Microsoft.Dynamics.IntegrationFramework.WebService.WebReferenceBase.Init(String webReferenceName, String wcfSoapClientType, String endpointConfiguration)....

вопрос, что я сделал не так или недоделал?

[Raven Melancholic]

А из какого-либо средства проверки, типа SoapUI и подобных работает? Ну или, если в Visual Studio сделать ссылку на сервис и попробовать через сгенерированный прокси класс достучаться работает?
И, как вариант, вот это:

Цитата:

Создаю джоб...

А если не из джоба, а из серверного класса или серверного статического метода работает?

[demianimp]

Что тестирование показало:
1) Когда добавил другой веб-сервис, то аксапта2009 отработала корректно и без ошибок;
2) Работает только на сервере;
3) Добавил в VS референс на сервис аксапты2012, там все отработало корректно;
4) аксапта2009 отказывается работать с сервисом от аксапта2012.

Показывает доступные методы из сервиса с переменными, но компилятор говорит "Класс Tutorial.Tutorial_LabServiceClient не содержит эту функцию."
5) Но все равно при new не может найти App.config

[Raven Melancholic]

Цитата:

Показывает доступные методы из сервиса с переменными, но компилятор говорит "Класс Tutorial.Tutorial_LabServiceClient не содержит эту функцию."

А если подсунуть не null, а пустой объект именно с точки зрения NET.

public static System.Object CLRMissing()
{
    System.Type                 type;
    System.Reflection.FieldInfo infoRef;
    System.Object               missing;
    ;

    type        =  System.Type::GetType("System.Reflection.Missing");
    infoRef     =  type.GetField("Value");
    missing     = inforef.GetValue(Null);

    return missing;
}

[demianimp]

Все равно говорит, что не содержит этой функции

[demianimp]

Нашли решение через

Tutorial.CallContext    callContext;
serviceData = labService.getCustData(callContext, '1');

[demianimp]

Продолжаем попытки подружить AX2009 с AX2012 через сервис.

Что удалось выяснить.
1) При добавлении референса, AX2009 добавляет его по адресу %programFiles%\Microsoft Dynamics AX\50\Application\Appl\%NameApp%\ServiceReferences\%NameService%
2) При работе с %NameService%, почему-то ищет в %programFiles%\Microsoft Dynamics AX\50\Server\%NameAOS%\Bin. Причем это только для сервиса из AX2012.
3) Оказалось, что callContext нужно все таки инициализировать

callContext = new Tutorial.CallContext()

Вопрос, где производиться настройка, чтобы AX2009 смотрела %programFiles%\Microsoft Dynamics AX\50\Application\Appl\%NameApp%\ServiceReferences\%NameService%, а не %programFiles%\Microsoft Dynamics AX\50\Server\%NameAOS%\Bin?

[demianimp]

Разобрались, оказывается если референс назвать MDMExchange, то все работает через одно место, а вот если обозвать ExchangeMDM или NDNExchange, то работает все корректно, как задумано создателями.

Всем спасибо за участие.

[demianimp]

Цитата:

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

Вопрос, где производиться настройка, чтобы AX2009 смотрела %programFiles%\Microsoft Dynamics AX\50\Application\Appl\%NameApp%\ServiceReferences\%NameService%, а не %programFiles%\Microsoft Dynamics AX\50\Server\%NameAOS%\Bin?

Оказалось, что вопрос все еще актуальный.
Есть несколько одинаковых версий серверов. На одних работает, на других нет.
На которых работает смотрит в папку %programFiles%\Microsoft Dynamics AX\50\Application\Appl\%NameApp%\ServiceReferences\%NameService%, а на которых отказывается работать смотрит %programFiles%\Microsoft Dynamics AX\50\Server\%NameAOS%\Bin.

Кто знает, от чего это зависит?

[Damn]

Такое ощущение, что у вас на некоторых АОСах в файле Ax32Serv.exe.config включена поддержка .Net Framework 4.5 или выше.
На этих серверах штатный механизм создания референсов на веб-сервисы использовать нельзя, АОС будет искать файл app.config в каталоге bin.

[Logger]

А зачем на рабочей это делать?
Можно скопировать папку и импортировать узел аот через xpo. Рестартовать аос.
Должно сработать.

[demianimp]

Цитата:

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

Такое ощущение, что у вас на некоторых АОСах в файле Ax32Serv.exe.config включена поддержка .Net Framework 4.5 или выше.
На этих серверах штатный механизм создания референсов на веб-сервисы использовать нельзя, АОС будет искать файл app.config в каталоге bin.

А как нестандартным импортировать? Что нужно сделать, чтобы заработало?

[demianimp]

Цитата:

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

А зачем на рабочей это делать?
Можно скопировать папку и импортировать узел аот через xpo. Рестартовать аос.
Должно сработать.

Скопировал папку, импортировал узел через XPO (AOS перетер файлы), Рестартовал AOS, все равно ошибка

[Damn]

Предлагаю всё-таки определить в этом дело или нет.
Если на АОСе действительно включена поддержка .NET Framework 4.5, то я например у себя заменил штатный механизм генерации референсов на веб-сервисы. Использую утилиты svcutil.exe и csc.exe. Можно взять утилиты от версии 3.5 (для использования на всех АОСах). А можно взять утилиты от версии 4, их можно использовать только на АОСах с поддержкой .NET Framework 4.5.
Утилиты разных версий генерят немного разные прокси-dll. Отличия перечислять не буду, но они есть.
Внешне для разработчика у меня генерация референсов не изменилась. Тот же диалог, те же сообщения, только файл app.config генерится пустой, так как он не используется. Биндинги и endpoint нужно программно создавать при инициализации soapClient.

[Raven Melancholic]

Цитата:

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

Вопрос, где производиться настройка, чтобы AX2009 смотрела %programFiles%\Microsoft Dynamics AX\50\Application\Appl\%NameApp%\ServiceReferences\%NameService%, а не %programFiles%\Microsoft Dynamics AX\50\Server\%NameAOS%\Bin?

Судя по всему, нигде не задается.
Если посмотреть код Microsoft.Dynamics.IntegrationFramework.WebService.WebReferenceBase.Init, то видно, что указанная ошибка выдается:

protected void Init(string webReferenceName, string wcfSoapClientType, string endpointConfiguration)
{
	Assembly callingAssembly = Assembly.GetCallingAssembly();
	string directoryName = Path.GetDirectoryName(callingAssembly.Location);
	string path = string.Format(CultureInfo.InvariantCulture, CONFIG_FILE_FORMAT, directoryName);
	if (!File.Exists(path))
	{
		throw new FileNotFoundException(resourceMgr.GetString("Consume_WS_AppConfig_NotFound"));
	}

То есть, что-то разное на разных серверах дает Assembly.GetCallingAssembly().Location
В https://docs.microsoft.com про GetCallingAssembly и Location есть примечания про разницу возвращаемых значений для "расширяется встроенным образом," "теневое копирование" и прочих. Для меня эти термины темный лес, может подскажут что-то те, кто хорошо знает NET.

[Raven Melancholic]

Может быть, в методе генерации исходного кода (AifServiceReferenceManager::generate) и его компиляции поставить точку останова после генерации исходного кода но до компиляции и сборки и скопировать куда-нибудь из временных файлов исходных кодов на "правильном" и "ошибочном" серверах и по коду, возмодно, что-то прояснится?

[demianimp]

Цитата:

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

Предлагаю всё-таки определить в этом дело или нет.
Если на АОСе действительно включена поддержка .NET Framework 4.5, то я например у себя заменил штатный механизм генерации референсов на веб-сервисы. Использую утилиты svcutil.exe и csc.exe. Можно взять утилиты от версии 3.5 (для использования на всех АОСах). А можно взять утилиты от версии 4, их можно использовать только на АОСах с поддержкой .NET Framework 4.5.
Утилиты разных версий генерят немного разные прокси-dll. Отличия перечислять не буду, но они есть.
Внешне для разработчика у меня генерация референсов не изменилась. Тот же диалог, те же сообщения, только файл app.config генерится пустой, так как он не используется. Биндинги и endpoint нужно программно создавать при инициализации soapClient.

Да, на серверах действительно включен .NET Framework 4.5, но на каких-то работает, а на каких-то нет.

Цитата:

Сообщение от Raven Melancholic

Судя по всему, нигде не задается.
То есть, что-то разное на разных серверах дает Assembly.GetCallingAssembly().Location

    System.Reflection.Assembly  callingAssembly;
    ;
    new InteropPermission(InteropKind::ClrInterop).assert();
    callingAssembly = System.Reflection.Assembly::GetCallingAssembly();
    info(callingAssembly.get_Location());

На сервере возвращает C:\Program Files\Microsoft Dynamics AX\50\Server\%AosName%\Bin\Microsoft.Dynamics.ClrBridge.dll

Т.е. по идее и сейчас должна возвращаться ошибка.

[Damn]

Цитата:

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

Да, на серверах действительно включен .NET Framework 4.5, но на каких-то работает, а на каких-то нет.

Работает на тех серверах, на которых не запускался механизм создания или обновления референса.
DLL, сгенерированная на АОСе в режиме поддержки Framework 3.5, корректно работает на любых АОСах.
DLL, сгенерированная на АОСе в режиме поддержки Framework 4.5, не будет работать ни на каком АОСе.

Почему у вас на каких-то серверах включена поддержка Framework 4.5, а на каких-то выключена ? Что вы используете из 4.5 ?

[Raven Melancholic]

Цитата:

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

На сервере возвращает C:\Program Files\Microsoft Dynamics AX\50\Server\%AosName%\Bin\Microsoft.Dynamics.ClrBridge.dll
Т.е. по идее и сейчас должна возвращаться ошибка.

Не, тут-то как раз все хорошо - Microsoft.Dynamics.ClrBridge.dll действительно находится в ...\bin и при вызове из кода X++ этот ClrBridge является посредником, чья сборка выполняется.
Я имел ввиду, что WebReferenceBase.Init вызывается из прокси WEB сервиса, который находится в Appl...ServiceReferences... и, по хорошему, location должен вернуть его местонахождение, а там же лежит *.config. Но, в каких-тор случаях что-то явно идет не так и Assembly.GetCallingAssembly() почему-то считает, что он выполняется не в контексте прокси, а в контексте какой-то сборки из bin.
А вот почему он так считает, тут уже мне знаний не хватает.

[demianimp]

Цитата:

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

Работает на тех серверах, на которых не запускался механизм создания или обновления референса.
DLL, сгенерированная на АОСе в режиме поддержки Framework 3.5, корректно работает на любых АОСах.
DLL, сгенерированная на АОСе в режиме поддержки Framework 4.5, не будет работать ни на каком АОСе.

Почему у вас на каких-то серверах включена поддержка Framework 4.5, а на каких-то выключена ? Что вы используете из 4.5 ?

4.5 включен на всех серверах, это и смущает, что на одних работает, а на других нет.

Цитата:

Сообщение от Raven Melancholic

Не, тут-то как раз все хорошо - Microsoft.Dynamics.ClrBridge.dll действительно находится в ...\bin и при вызове из кода X++ этот ClrBridge является посредником, чья сборка выполняется.
Я имел ввиду, что WebReferenceBase.Init вызывается из прокси WEB сервиса, который находится в Appl...ServiceReferences... и, по хорошему, location должен вернуть его местонахождение, а там же лежит *.config. Но, в каких-тор случаях что-то явно идет не так и Assembly.GetCallingAssembly() почему-то считает, что он выполняется не в контексте прокси, а в контексте какой-то сборки из bin.
А вот почему он так считает, тут уже мне знаний не хватает.

string directoryName = Path.GetDirectoryName(callingAssembly.Location);

Разве не будет возвращать всегда C:\Program Files\Microsoft Dynamics AX\50\Server\%AosName%\Bin\ ? Или что-то не понял