Хостинг сервисов AX 2012 на IIS и ошибка Duplicate type with name [..] in assembly 'Dynamics.Ax.Application'

[gl00mie]

В ряде случаев бывает нужно хостить сервисы AX 2012 на IIS для доступа не по NET.TCP, а по HTTP/HTTPS. Это включает создание расширенного входящего порта AIF, его настройку, выбор хоста IIS и развертывание на нем соответствующего сервиса. Здесь я хотел бы остановиться на ряде проблем, которые могут при этом возникнуть, и способах их решения.

Во-первых, при настройке расширенного порта AIF нужно избегать использования символов подчеркивания в названии. На проектах AX 2012 часто используются префиксы или суффиксы в именах объектов, отделенные символом подчеркивания, так вот, в названии порта должны быть только буквы и цифры, больше ничего, никаких символов подчеркивания, иначе AIF будет ругаться.

Во-вторых, следует создавать очень лаконичные классы контрактов сервисных операций, которые вы собираетесь хостить на IIS. Из кода всех контрактов (входных и выходных) обязательно уберите все-все методы, кроме parm* и, может, construct(). Убедитесь, что в контрактах нет никакой логики и ссылок на посторонние классы приложения. Это также означает, что для хостинга на IIS контракты не должны реализовывать интерфейс SysOperationValidatable и содержать метод validate() - вся валидация входных параметров должна быть перемещена в код сервиса. Если контракты используют наследование, то ради хостинга на IIS, скорее всего, от него также придется отказаться. Это критически важный момент: логика, осуществляющая развертывание сервиса, с одной стороны, выкладывает на IIS подмножество Dynamics.Ax.Application.dll*.netmodule-файлов скомпилированного в CIL приложения с нужными типами, а с другой стороны, видимо, не распознает в классе контракта ссылки ни на какие иные типы, кроме тех, что получены через сигнатуры методов с DataMemberAttribute. Поэтому любая ссылка из класса контракта на другой тип, скажем, любой вызов checkFailed() (ссылка на Global) приведет к тому, что на IIS могут оказаться не все необходимые .netmodule-файлы скомпилированного в CIL приложения, и тогда IIS просто не сможет загрузить сборку сервиса. Проявляться это может в желтом экране смерти при попытке обращения к сервису (включая его WSDL-описание) с ошибкой вида:

BadImageFormatException: Could not load file or assembly 'Dynamics.Ax.Application.*' or one of its dependencies. An attempt was made to load a program with an incorrect format.

Здесь IIS будет ругаться на какую-то конкретную сборку, и совет включить поддержку 32-битного кода для пула приложений не поможет. Дело просто в том, что на IIS оказались развернуты не все .netmodule-файлы, которые нужны.

В-третьих, даже если предыдущие рекомендации были соблюдены, после развертывания сервиса может появиться ошибка вида:

Duplicate type with name 'Dynamics.Ax.Application.*' in assembly 'Dynamics.Ax.Application'

Здесь в качестве имени типа может быть один из контрактов развернутых сервисов. В интернете полно заметок о том, как бороться с такой ошибкой, практически везде предлагается пересобрать CIL с небольшими вариациами шаманских действий, типа ручной очистки каталога XppIL и обрезания (truncate) таблицы SysXppAssembly в базе моделей. Из моего скромного опыта, эти ритуальные действия были актуальны для очень старых сборок ядра, а сейчас это - пустая трата времени, CIL и так пересобирается нормально. Что действительно важно - это провести нужную работу на стороне хоста IIS, где развернуты сервисы, потому что ошибка проявляется именно там.

Итак, предположим, что после глобальной компиляции приложения со всеми предосторожностями CIL был успешно полностью пересобран. Удалите файлы приложения AX Dynamics.Ax.Application.* на хосте IIS, разверните сервисы на этом хосте повторно и проверьте даты появившихся .netmodule-файлов. На хосте IIS файлы сервисов AX располагаются, как правило, в %ProgramFiles%\Microsoft Dynamics AX\60\AifWebServices\Bin - после развертывания убедитесь, что даты модификации .netmodule-файлов соответствуют вашему свежесобранному CIL. Если попадаются файлы с более старой датой модификации, то лучше деактивировать развернутые на этом хосте сервисы, удалить все файлы %ProgramFiles%\Microsoft Dynamics AX\60\AifWebServices\Bin\Dynamics.Ax.Application.dll*, а также любые подкаталоги с файлами Dynamics.Ax.Application.dll* (резервные копии или еще что). Затем разверните сервисы повторно и еще раз сравните даты. Если все сошлось, удалите закэшированные файлы приложения AX на хосте IIS во временном каталоге ASP.NET. IIS загружает файлы развернутого сервиса не напрямую из %ProgramFiles%, а из копии, которая создается в

%SystemRoot%\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\MicrosoftDynamicsAxAif60\

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

На этом этапе у меня, во всяком случае, запрос WSDL сервиса стабильно вместо желтого экрана смерти начинает возвращать то, что нужно