Что сделать, чтобы сбросить кэш кода класса, который выполняется при вызове сервиса

[mazzy]

ax2012. есть класс RetailTransactionServiceOrders и метод searchCustomerOrderList
этот метод вызывается из класса RetailTransactionService
который, в свою очередь, реализует на X++ логику поиска заказов для serviсе
который, в свою очередь вызывается из POS


вчера для отладки я изменил код в этом методе.
сегодня удалил код из слоя sys

но сервис все равно работает по старому!!!

по-видимому где-то есть кэш кода. Подозреваю, что это dll-библиотеки.

Делалось:
* Инкрементная компиляция в CIL
* AOS перезагружался
* у пользователя галочка "выполнять в CIL" включалась/выключалась
* IIS перезагружался
* кэши в средствах разработки сбрасывались. все 4 = словарь, элементы и прочее

Что нужно сделать, чтобы сбросить кэш кода и заставить сервис выполнять текущую версию кода?

=====================
Похожая тема: Не обновляется класс при пакетной обработке

[gl00mie]

Цитата:

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

вчера для отладки я изменил код в этом методе. сегодня удалил код из слоя sys
Делалось: Инкрементная компиляция в CIL

Замечено, что инкрементная компиляция CIL подхватывает только объекты с более поздней, чем какая-то там, датой изменения, а когда удаляешь модифу с текущего слоя разработки, возвращаясь к стандарту, инкрементный CIL этого "не видит". Надо полностью CIL пересобрать.

Цитата:

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

* у пользователя галочка "выполнять в CIL" включалась/выключалась

Это влияет только на логику, выполняющуюся в клиентской сессии на сервере. А сервисы, как и пакетные задания, всегда выполняются в CIL - они по-другому в 2012 не умеют.

[Ivanhoe]

Перед запуском AOS папку XPPIL удаляли?

[mazzy]

Цитата:

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

Надо полностью CIL пересобрать.

пля... спасибо.

Цитата:

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

Перед запуском AOS папку XPPIL удаляли?

нет. это тестовая у клиента. там несколько человек крутится...

[Logger]

Цитата:

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

Замечено, что инкрементная компиляция CIL подхватывает только объекты с более поздней, чем какая-то там, датой изменения, а когда удаляешь модифу с текущего слоя разработки, возвращаясь к стандарту, инкрементный CIL этого "не видит". Надо полностью CIL пересобрать.

А если не хочется / нет времени полную пересборку делать ?
После удаления модифы, сделать фиктивные изменения в коде на нижнем слое (добавив коммент), чтобы код переехал на usr и дата модификации стала бы текущей. И сделать инкрементный CIL. Так поможет ?

[Ivanhoe]

Если уже встретили "глюк" с CIL - то лучшее решение (самое быстрое) - удалить XPPIL, запустить АОС и сделать полную сборку CIL. На нормальной системе это займет минут 15-20 максимум.

[Kabardian]

Нагуглил статью по теме: AX for Retail 2012: Customizing the Transaction Service. Цитирую коммент оттуда:

Цитата:

For some reason (mainly related to the .Net Business Connector) the X++ code is sometimes cached and it is difficult to force it to take the new code.

The best way that I've found to force it to take the new code is to restart the Windows Process Activation Service in your local services on your Real-Time Service machine.

Т. е. нужно перезапустить службу Windows Process Activation Service и кэш должен сброситься.

[axotnik88]

Цитата:

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

Если уже встретили "глюк" с CIL - то лучшее решение (самое быстрое) - удалить XPPIL, запустить АОС и сделать полную сборку CIL. На нормальной системе это займет минут 15-20 максимум.

+1, но я еще изначально папку переименовую, и создаю такую же. Бывает удаление XPPIL занимает до 10 мин.

[Ivanhoe]

Папку, конечно, переименовываем, чтобы не ждать. Создавать не нужно - создатся сама.

[gl00mie]

Цитата:

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

я еще изначально папку переименовую, и создаю такую же. Бывает удаление XppIL занимает до 10 мин.

Обычно тормозит не столько удаление файлов сборки и отладочной информации в XppIL (пара тысяч файлов), сколько удаление XppIL\Source (пара-тройка сотен тысяч файлов). Подкаталог Source можно не удалять - на работу приложения он не влияет и вообще заполняется, только если на АОСе включена отладка.

Цитата:

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

Папку, конечно, переименовываем, чтобы не ждать. Создавать не нужно - создатся сама.

Ранние сборки ядра AX 2012/2012 R2 не хотели запускаться в случае отсутствия каталога bin\XppIL и умели создавать лишь подкаталоги внутри bin\XppIL.

[fed]

Еще есть неплохой вариант:Если в модельной базе данных оттрункейтить таблицу SysXPPAssemblies, то AOS будет просто игнорировать все существующие сборки и при выполнении Full Compile, аккуратненько их перестроит. (Правда, часть ключевых сборок он перестраивает прямо при запуске). Так что не надо ничего удалять - они сами отваляются если попрыгать
Кстати, усечение таблицы происходит во много-много раз быстрее чем удаление кучи сборок с диска.

[UNRW]

Цитата:

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

+1, но я еще изначально папку переименовую, и создаю такую же. Бывает удаление XPPIL занимает до 10 мин.

rd PATH /s /q
работает раз в 10 быстрее чем удалять через проводник

[solo_vv]

Коллеги, подскажите, пожалуйста.
Перед запуском AOS папку XPPIL удаляю (переименовываю). Запускаю AOS папка XPPIL создается но пустая. Заполняется только при полной сборке CIL. Я так понимаю, что если она пустая то заполняться должна при запуске AOS. Так? Если так, что необходимо что она заполнялась?

[gl00mie]

А сколько вы ждали после запуска АОСа, прежде чем прийти к выводу, что XppIL не заполняется до полной сборки CIL? В зависимости от того, есть ли скомпилированное в CIL приложение в базе модели (в таблице SysXPPAssemblies) или нет, АОС при запуске с пустым каталогом XppIL может сам автоматом начать полную компиляцию CIL, а она требует большой подготовительной работы до того, как начнут генериться сборки, в частности, длительное время заполняется каталог XppIL\XML.

[Ivanhoe]

Скорее всего вопрос про конкретный случай. Реально не заполняется папка. Права на папку есть. При старта АОС плохо ругается, что не находит важных сборок (и сам их не создает). Аналогичное поведение на вновь установленном АОС. Версия ядра что R2 CU6, что R2 CU8.

Никто не сталкивался?

[gl00mie]

В таких случаях помогает Process Monitor - может, АОС лезет куда-то не туда, может, ОС его "посылает" при попытке записать что-то в XppIL... Вообще же было бы полезно привести примеры ругани на отсутствующие сборки.

[solo_vv]

Цитата:

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

А сколько вы ждали после запуска АОСа, прежде чем прийти к выводу, что XppIL не заполняется до полной сборки CIL? В зависимости от того, есть ли скомпилированное в CIL приложение в базе модели (в таблице SysXPPAssemblies) или нет, АОС при запуске с пустым каталогом XppIL может сам автоматом начать полную компиляцию CIL, а она требует большой подготовительной работы до того, как начнут генериться сборки, в частности, длительное время заполняется каталог XppIL\XML.

ждали до 30 минут.

[solo_vv]

Цитата:

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

В таких случаях помогает Process Monitor - может, АОС лезет куда-то не туда, может, ОС его "посылает" при попытке записать что-то в XppIL... Вообще же было бы полезно привести примеры ругани на отсутствующие сборки.

Ошибка только одна:
Object Server 03: System.IO.FileNotFoundException: Could not load file or assembly 'Dynamics.Ax.Application' or one of its dependencies. The system cannot find the file specified.
File name: 'Dynamics.Ax.Application'
at System.Reflection.RuntimeAssembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
at System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(AssemblyName assemblyRef, Evidence assemblySecurity, RuntimeAssembly reqAssembly, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
at System.Reflection.Assembly.Load(AssemblyName assemblyRef)
at Microsoft.Dynamics.Ax.MSIL.BatchILMethods..cctor()

=== Pre-bind state information ===
LOG: DisplayName = Dynamics.Ax.Application
(Partial)
WRN: Partial binding information was supplied for an assembly:
WRN: Assembly Name: Dynamics.Ax.Application | Domain ID: 2
WRN: A partial bind occurs when only part of the assembly display name is provided.
WRN: This might result in the binder loading an incorrect assembly.
WRN: It is recommended to provide a fully specified textual identity for the assembly,
WRN: that consists of the simple name, version, culture, and public key token.
WRN: See whitepaper http://go.microsoft.com/fwlink/?LinkId=109270 for more information and common solutions to this issue.
LOG: Appbase = file:///C:/Program Files/Microsoft Dynamics AX/60/Server/WORK_2/Bin/
LOG: Initial PrivatePath = NULL
Calling assembly : Ax32Serv, Version=6.2.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35.
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: C:\Program Files\Microsoft Dynamics AX\60\Server\WORK_2\Bin\Ax32Serv.exe.Config
LOG: Using host configuration file:
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework64\v4.0.30319\config\machine.config.
LOG: Policy not being applied to reference at this time (private, custom, partial, or location-based assembly bind).
LOG: Attempting download of new URL file:///C:/Program Files/Microsoft Dynamics AX/60/Server/WORK_2/Bin/Dynamics.Ax.Application.DLL.
LOG: Attempting download of new URL file:///C:/Program Files/Microsoft Dynamics AX/60/Server/WORK_2/Bin/Dynamics.Ax.Application/Dynamics.Ax.Application.DLL.
LOG: Attempting download of new URL file:///C:/Program Files/Microsoft Dynamics AX/60/Server/WORK_2/Bin/XppIL/Dynamics.Ax.Application.DLL.
LOG: Attempting download of new URL file:///C:/Program Files/Microsoft Dynamics AX/60/Server/WORK_2/Bin/XppIL/Dynamics.Ax.Application/Dynamics.Ax.Application.DLL.
LOG: Attempting download of new URL file:///C:/Program Files/Microsoft Dynamics AX/60/Server/WORK_2/Bin/VSAssemblies/Dynamics.Ax.Application.DLL.
LOG: Attempting download of new URL file:///C:/Program Files/Microsoft Dynamics AX/60/Server/WORK_2/Bin/VSAssemblies/Dynamics.Ax.Application/Dynamics.Ax.Application.DLL.
LOG: Attempting download of new URL file:///C:/Program Files/Microsoft Dynamics AX/60/Server/WORK_2/Bin/Dynamics.Ax.Application.EXE.
LOG: Attempting download of new URL file:///C:/Program Files/Microsoft Dynamics AX/60/Server/WORK_2/Bin/Dynamics.Ax.Application/Dynamics.Ax.Application.EXE.
LOG: Attempting download of new URL file:///C:/Program Files/Microsoft Dynamics AX/60/Server/WORK_2/Bin/XppIL/Dynamics.Ax.Application.EXE.
LOG: Attempting download of new URL file:///C:/Program Files/Microsoft Dynamics AX/60/Server/WORK_2/Bin/XppIL/Dynamics.Ax.Application/Dynamics.Ax.Application.EXE.
LOG: Attempting download of new URL file:///C:/Program Files/Microsoft Dynamics AX/60/Server/WORK_2/Bin/VSAssemblies/Dynamics.Ax.Application.EXE.
LOG: Attempting download of new URL file:///C:/Program Files/Microsoft Dynamics AX/60/Server/WORK_2/Bin/VSAssemblies/Dynamics.Ax.Application/Dynamics.Ax.Application.EXE.

[Alex_KD]

Цитата:

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

но сервис все равно работает по старому!!!

Делалось:
* Инкрементная компиляция в CIL

Мы лечим так -
Убедится, что CIL собрался (если отработал за 5 секунд, делай full CIL)
Recycle Application Pool который отвечает за Real time service (Restart, iisreset и прочее как правило не помогает).

Папку XppIL в R3 удалять не надо, full CIL итак все делает правильно. Ну и Аксапту запускать из под админа надо всегда.

[Alex_KD]

Цитата:

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

Ранние сборки ядра AX 2012/2012 R2 не хотели запускаться в случае отсутствия каталога bin\XppIL и умели создавать лишь подкаталоги внутри bin\XppIL.

Было такое, на какой версии не помню. Дал права на всю папку c AX аккаунту под которым AOS запуcкается - все заработало. Повторюсь, версию не помню....может было на R3, может нет.