19.11.2018, 12:50 | #1 |
Участник
|
D365FO: когда обновление ломает доработку
А давайте сюда собирать примеры, в каких случаях такие нужные ежемесячные обновления могут тихо сломать невинную доработку.
В другой ветке я уже приводил пример с лукапом, когда мы создаем обработчик события onLookup на контроле, а потом Майкрософт решает перекрыть метод lookup на том же котроле, и наш обрабочик становится мертвым кодом. Только что напоролся на нечто другое: Если к таблице А добавить поле и релейшн на таблицу Б, причем в таблице А уже есть некоторое поле и релейшен, указывающие на ту же таблицу Б в другом контексте, то вызов QueryBuildDataSource.relations(true) где угодно может привести к неожиданным результатам. |
|
|
За это сообщение автора поблагодарили: Vadik (1), raz (1), ax_mct (3), Pokersky09 (2). |
05.12.2018, 13:55 | #2 |
NavAx
|
class LedgerJournalCheckPost
мы использовали CoC на LedgerJournalCheckPost.postTrans(), последнее обновление: X++: [SysObsoleteAttribute('Method postTrans has been deprecated. Please use postTransV2 method instead.', false)] protected boolean postTrans( Вот вам бесшовный и неразрушающий. |
|
|
За это сообщение автора поблагодарили: trud (2), sukhanchik (3), Ivanhoe (3), Stitch_MS (3). |
05.12.2018, 14:53 | #3 |
Administrator
|
Та же самая ситуация с примером, который использует Entiti.
Была Entiti под названием "X". Ее использовали в коде для целей загрузки некоего справочника (потому что исходный формат загрузки сильно отличался от предполагаемого, который был в стандарте). После обновления была выпущена Entiti под название "XV2", а предыдущая была объявлена устаревшей. Ну и собственно все. Код формально компилируется, но фактически - не работает. В конкретно моем случае это была замена с EcoResProductEntity на EcoResProductV2Entity и замена класса EcoResProductEntityToCrossTableDataAdaptor на EcoResProductV2EntityToCrossTableDataAdaptor. Соответственно - сломался импорт номенклатур при переходе с 7.3 на 8.0. Учитывая, что этих версий Entiti в частности при загрузке клиентов / поставщиков уже минимум 3 штуки я видел - то подозреваю, что их использование в коде - могло бы также привести к необходимости корректировки этого кода. Также хочу отметить, что (правда тут никто не обещал, что все останется как есть) в 8.1 с выходом русской локализации код по импорту выписки переписали на использование GER-настроек, в связи с этим физически русский код по импорту выписки в 8.0 и ранее отличается от того, что вышло в 8.1 (конечно русская функциональность была отключена, но это не мешало использовать существующий код для целей написания самописного импорта выписки на базе стандартного кода)
__________________
Возможно сделать все. Вопрос времени Последний раз редактировалось sukhanchik; 05.12.2018 в 14:55. |
|
05.12.2018, 15:59 | #4 |
Участник
|
https://docs.microsoft.com/en-us/dyn...considerations
Цитата:
Some methods will be attributed as obsolete to signal that they will be fully deprecated in the future. Any compiler warning that is generated due to the calling or wrapping of an obsolete method should be investigated to ensure that the expected code path still exists. In some cases, Microsoft code will directly call the new method in place of the obsolete method. When this happens, the code built around the obsolete method will not execute when expected.
|
|
05.12.2018, 16:15 | #5 |
NavAx
|
Дело в том, что в предыдущей версии нет и намека на предстоящие изменения.
X++: /// true if the journal was posted successfully; otherwise, false. /// </returns> protected boolean postTrans( LedgerVoucher _ledgerVoucher, |
|
05.12.2018, 20:29 | #6 |
Участник
|
Стоит взять пример с разработчиков DirectX, которые знали, что если кто-то выпускал игры для 6-й или 7 версии, то последующие версии не должны сломать функционал старых игр. Итог превзошел все ожидания. Интерфейсы менялись крайне редко, а если менялись, то по сути создавались новые, более совершенные или более полезные, обрастая новыми методами, либо измененными старыми. Старый же код продолжал жить, радуя поклонников ретро-игр.
__________________
// no comments |
|
24.12.2018, 12:35 | #7 |
Участник
|
Цитата:
Сообщение от dech
Стоит взять пример с разработчиков DirectX, которые знали, что если кто-то выпускал игры для 6-й или 7 версии, то последующие версии не должны сломать функционал старых игр. Итог превзошел все ожидания. Интерфейсы менялись крайне редко, а если менялись, то по сути создавались новые, более совершенные или более полезные, обрастая новыми методами, либо измененными старыми. Старый же код продолжал жить, радуя поклонников ретро-игр.
Как бы и старый код не должен ломаться и новые фичи будут доступны для новых разработок. Но что-то пошло не так... Решили использовать старые имена для public end points (OData)... |
|
|
За это сообщение автора поблагодарили: trud (2). |
27.01.2019, 15:14 | #8 |
Участник
|
Еще пример. Класс SubledgerJournalizerProjectExtension,
X++: protected ProjEmplTrans createProjHourTrans(Container _projectActualHeaderContainer, SourceDocumentLineItem _sourceDocumentLineItem, ...) { ProjEmplTrans projEmplTrans; PSAComponentGroupAssignment psaComponentGroupAssignment; projEmplTrans.clear(); #declareProjectActualHeaderContainerVariablesMacro #projectActualHeaderContainerMacro = _projectActualHeaderContainer; projEmplTrans.ProjId = actualProjectId; projEmplTrans.CategoryId = actualCategoryId; projEmplTrans.ActivityNumber = actualActivityNumber; projEmplTrans.LinePropertyId = actualLinePropertyId; X++: #localmacro.declareProjectActualHeaderContainerVariablesMacro RefRecId actualSourceDocumentLine; DataAreaId actualProjectDataAreaId; ProjId actualProjectId; ProjCategoryId actualCategoryId; smmActivityNumber actualActivityNumber; ProjLinePropertyId actualLinePropertyId; CurrencyCode actualTransactionCostCurrency; CurrencyCode actualTransactionSalesCurrency; CurrencyCode accountingCurrency; ProjTaxGroup actualTaxGroupId; ProjTaxItemGroup actualTaxItemGroupId; DimensionDefault actualDefaultDimension; Qty actualQuantity; AmountCur actualTransactionCurrencyCostAmount; AmountMST actualAccountingCurrencyCostAmount; AmountCur actualTransactionCurrencySalesAmount; AmountMST actualAccountingCurrencySalesAmount; #endmacro #localmacro.projectActualHeaderContainerMacro [ actualSourceDocumentLine, actualProjectDataAreaId, actualProjectId, actualCategoryId, actualActivityNumber, actualLinePropertyId, actualTransactionCostCurrency, actualTransactionSalesCurrency, accountingCurrency, actualTaxGroupId, actualTaxItemGroupId, actualDefaultDimension, actualQuantity, actualTransactionCurrencyCostAmount, actualAccountingCurrencyCostAmount, actualTransactionCurrencySalesAmount, actualAccountingCurrencySalesAmount ] #endmacro И в этом классе такой метод не один. |
|
28.01.2019, 02:51 | #9 |
Banned
|
Цитата:
Сообщение от Stitch_MS
Еще пример. Класс SubledgerJournalizerProjectExtension,
Т.е. в методе createProjHourTrans первый параметр _projectActualHeaderContainer -- это, по сути, 17 параметров. Если изменить макросы, то список параметров в createProjHourTrans вроде как не изменился, возможно не будет считаться за breaking change, и может по-тихому сломать расширение, изменяющее значение одного из элементов в контейнере. И в этом классе такой метод не один. В любом языке и на любой платформе так не пишут. Это как кучку в лифте наложить. Максимум два часа времени создать сериализующийся класс для передачи эти параметров если очень надо упаковкой между клиентом и сервером. А если все на сервере то вообще дебилы. |
|
28.01.2019, 09:54 | #10 |
Участник
|
|
|
28.01.2019, 11:26 | #11 |
Banned
|
Это австриец Michael Gall писал. Или по крайней мере концепцию создавал. Очень приятный и талантливый парень, кстати. Ну и вполне заслуженно блестящую карьеру сделал.
|
|
28.01.2019, 16:43 | #12 |
Banned
|
Цитата:
https://www.linkedin.com/in/migall/ Но передавать динамическую кучку таким образом как-то не по программистски совсем. Даже если без расширений, а просто в одной команде это уже проблемное место. Бывают компромиссы но здесь просто недостаток опыта в программировании вообще. |
|
28.01.2019, 16:55 | #13 |
Moderator
|
Цитата:
Сообщение от ax_mct
Ну с PHD в Computer science не поспоришь.
https://www.linkedin.com/in/migall/ Но передавать динамическую кучку таким образом как-то не по программистски совсем. Даже если без расширений, а просто в одной команде это уже проблемное место. Бывают компромиссы но здесь просто недостаток опыта в программировании вообще. </SARCASM> |
|
|
За это сообщение автора поблагодарили: AlGol (2), Vadik (1), ax_mct (3), vmoskalenko (2). |
31.01.2019, 18:07 | #14 |
NavAx
|
|
|
|
За это сообщение автора поблагодарили: ax_mct (5). |
01.02.2019, 02:02 | #15 |
Banned
|
Не уверен что по теме так как вроде бы здесь все на примерах и эта статья шире
Небольшое summary Цитата:
Providing there's no deferral, the production update is executed a week after the sandbox update.
The customer wasn't able to test, though, during the week - some key stakeholders were out of the office. We responded to the email to inform Microsoft we needed to defer, and never heard back. We waited up until the deadline, still didn't hear back, so we reached out to ASfP (Advanced Support for Partners). They told us to create a severity A support ticket requesting the deferral, which we did. Support said they'd tell the team and they'd follow up with us. The update happened anyways. Цитата:
To our customer, though, we look like idiots that can't figure out what we're doing.
Последний раз редактировалось ax_mct; 01.02.2019 в 02:05. |
|
22.05.2019, 10:27 | #16 |
NavAx
|
Очередная проблема при апдейте на PU26.
Есть пара стандартных классов DocuTemplateRender и ExportToExcelDataEntityHelper, они обеспечивают поддержку entities, когда можно открывать данные в excel, править и публиковать назад в d365fo. Нам пришлось их продублировать, т.к. стандарт не работает в пакетном режиме. Так вот в PU26 поменялись списки поддерживаемых .net модулей, вот что заменили. До PU26 X++: using Microsoft.Dynamics.ApplicationPlatform.Services.Instrumentation; using Microsoft.Dynamics.ApplicationPlatform.Environment; X++: using Microsoft.Dynamics.ApplicationPlatform.@Client.Instrumentation; |
|
|
За это сообщение автора поблагодарили: Stitch_MS (2). |
22.05.2019, 11:39 | #17 |
Banned
|
Цитата:
Сообщение от raz
Очередная проблема при апдейте на PU26.
Есть пара стандартных классов DocuTemplateRender и ExportToExcelDataEntityHelper, они обеспечивают поддержку entities, когда можно открывать данные в excel, править и публиковать назад в d365fo. Нам пришлось их продублировать, т.к. стандарт не работает в пакетном режиме. Так вот в PU26 поменялись списки поддерживаемых .net модулей, вот что заменили. До PU26 X++: using Microsoft.Dynamics.ApplicationPlatform.Services.Instrumentation; using Microsoft.Dynamics.ApplicationPlatform.Environment; X++: using Microsoft.Dynamics.ApplicationPlatform.@Client.Instrumentation; |
|
22.05.2019, 11:44 | #18 |
NavAx
|
При ребилде наших моделей после накатки PU26.
|
|
|
За это сообщение автора поблагодарили: ax_mct (3). |
22.05.2019, 14:27 | #19 |
Участник
|
JFYI
https://docs.microsoft.com/en-us/dyn...ed/one-version Цитата:
Backward compatibility does not include non-X++/metadata APIs. Microsoft reserves the right to update versions of any dependencies the product uses, as well as remove dependencies without early warning. Microsoft does not commit to maintain backwards compatibility of dependent software libraries unless expressly stated.
|
|
|
За это сообщение автора поблагодарили: ax_mct (3). |
22.05.2019, 20:26 | #20 |
Участник
|
D365FO 7.2 PU20 -> PU24 - Ошибка после установки PU24 поверх v.7.2 PU20
Установка PU24 поверх v.7.2 PU20 привело к тому, что модель перестрала компилироваться из-за того, что использовался "."-оператор, а чтобы избежать ошибки, надо было использовать "::"-оператор разрешения области (scope resolution operator).
Было: object1 = class1.Method1(...) Стало: object1 = class1::Method1(...) Остался только один вопрос: почему? |
|
|
За это сообщение автора поблагодарили: Stitch_MS (2). |
Теги |
d365fo |
|
|