ax2009: Как обновить(!) Service Reference не перегружая AOS? (не привлекая внимания санитаров)

[mazzy]

Идет разработка веб-сервиса (если важно, то разработка в ax2012)
поэтому у веб-сервиса постоянно появляются классы-методы и происходит изменение интерфейсов.

в ax2009 можно зарегистрировать веб-сервис.
ax2009 автоматом кладет исходники и dll в %Appl%\ServiceReferences\%myWebService%

и пока не было выполнения на сервере, этот reference в ax2009 можно даже обновить (правая кнопка мыши \ Regenerate)

но как только выполнили веб-сервис на AOS - сливай воду, туши свечи - нужно перегружать AOS, если хочется обновить веб-сервис на ax2009

Метод AifWebReferenceUtil.copyServiceReferenceToAOS() сообщает:
".Net assembly is locked by AOS, please restart AOS to load the new generated assembly."

бесит.
кто и как боролся с этим?

[Logger]

Видел такие мучения. Коллега в 2009-й делал по другому.
Просто генерил новую dll со сборкой. Имя было новое. Грузил ее в память и вызывал нужные методы через дотнетные аналоги SysDictClass. На первый взгляд неудобно, но нужно было 1-2 метода и его это устраивало. По совокупности гемора оказалось меньше.

Не уверен что так и надо в вашем случае, но как крайний вариант...

[Logger]

Еще на этапе разработки можно код сделать клиентским. Тогда возможно удастся обойтись только рестартом клиента без рестарта аоса.

[mazzy]

Zitat:

Zitat von Logger

Просто генерил новую dll со сборкой. Имя было новое.

добавить еще один референс с другим именем можно
но выполнить любой веб-сервис можно только на сервере.
чтобы сервер узнал о новом референсе с таким же веб-сервисом, нужно перегрузить АОС.
а это привлекает санитаров.

Zitat:

Zitat von Logger

Грузил ее в память и вызывал нужные методы через дотнетные аналоги SysDictClass. На первый взгляд неудобно, но нужно было 1-2 метода и его это устраивало.

да, такой вариант рассматривался.
но такой подход напрочь лишает всех преимуществ intelliSence,
убирает статический контроль и отменяет контракты.

ну, и всю религию веб-сервиса надо свести к 1-2 методам.
а остальное в рантайме.

при таком подходе скрипач (веб-сервис с WCF) не нужен.
вполне можно юзать что-нибудь более традиционное.

Zitat:

Zitat von Logger

По совокупности гемора оказалось меньше.

По совокупности гемора больше, поскольку все проверки на соблюдение контрактов уходят в рантайм.
Нет, конечно можно "ничего не проверять"...

Но может можно обновить Service Reference НЕ перегружая AOS?

[Logger]

Zitat:

Zitat von mazzy

добавить еще один референс с другим именем можно
но выполнить любой веб-сервис можно только на сервере.
чтобы сервер узнал о новом референсе с таким же веб-сервисом, нужно перегрузить АОС.
а это привлекает санитаров.

Там все было более радикально.
usdl ссылка скармливалась .Net библиотеке, которая генерила dll - обертку.
Далее все работа шла с этой dll. т.е. референса не было вообще. Конечно никакого Intellisence не было. Код мог работать как на клиенте так и на сервере. Авторизация тоже была возможна, а не как сейчас, только анонимные подключения.

[mazzy]

Zitat:

Zitat von Logger

Там все было более радикально.

В ax2009 можно увидеть пример такой реализации в мексиканском семействе объектов EInvoiceCFDI*
Правда "мексы" не от хорошей жизни так сделали - им нужна была авторизация по сертификату

[gl00mie]

Zitat:

Zitat von mazzy

как только выполнили веб-сервис на AOS - нужно перегружать AOS, если хочется обновить веб-сервис на ax2009

Zitat:

Zitat von mazzy

Но может можно обновить Service Reference НЕ перегружая AOS?

В данном случае "обновить Service Reference" - это выгрузить одну .NET-сборку и загрузить другую с тем же именем, но другим кодом внутри, правильно? CLR умеет выгружать сборки только вместе с AppDomain, в который(е) они загружены. В AX2012 на такой случай сделали настройку Allow hot swapping of assemblies when the server is running, которая заставляет AOS создавать новый AppDomain на каждую новую клиентскую сессию - и выгружать этот AppDomain, когда соотв. сессия завершается. В AX2009 такой возможности нет, насколько я помню, так что остается разве что перезагружать AOS. Как при этом не привлекать внимание санитаров? А запустить "свой собственный" AOS прям... хоть из ком.строки, на отдельном TCP-порту, проверять сервис, потом прибивать AOS по Ctrl-Break в консоли. Как минимум, другим пользователям это помешать не должно.

[mazzy]

Zitat:

Zitat von gl00mie

В данном случае "обновить Service Reference" - это выгрузить одну .NET-сборку и загрузить другую с тем же именем, но другим кодом внутри, правильно?

не только. нужен intelliSence и прочие радости разработки с WCF и групповой разработки в частности.

Zitat:

Zitat von mazzy

но такой подход напрочь лишает всех преимуществ intelliSence,
убирает статический контроль и отменяет контракты.

=================

Zitat:

Zitat von gl00mie

А запустить "свой собственный" AOS прям... хоть из ком.строки, на отдельном TCP-порту, проверять сервис, потом прибивать AOS по Ctrl-Break в консоли. Как минимум, другим пользователям это помешать не должно.

так я еще не извращался
знатное курево

но мысль с отдельным AOS - продуктивная.
Действительно стоит попробовать поставить второй АОС в кластер и перегружать только его.
И вообще каждому разработчику свой АОС в кластере!
Эк меня заносит

Спасибо за совет.

[dech]

Сам не пробовал, но нашел интересную статейку по этому поводу.
Там кстати тоже ссылочка есть на hot swapping assembies without AOS restart, про которую gl00mie писал.
https://daxmusings.codecrib.com/2011...eployment.html

[lvan]

https://docs.microsoft.com/en-us/dyn...ectedfrom=MSDN