В последнее время из-за популярности расширений часто сталкиваюсь с ситуацией, что после обновления 1С методы расширения не работают (Вместо, После, Перед, кроме ИзмененияИКонтроль), т.к. меняется количество параметров или название перехватываемой процедуры.

И 1С об этом стоически молчит.

Можно ли как-то выявить подобные моменты, хотя бы синтаксическим контролем (он тоже молчит) или еще как?

Сходи на курсы по программированию. Там научат

(1) не смог пройти мимо темы с Г1С?

(0) правой кнопкой мыши щелкаешь по списку расширений и там есть пункт типа проверка применения расширений.

(0) тесты, тесты и еще раз тесты

На одном из семинаров 1С предлагал для расширений сделать модуль с проверкой совместимости, код там пишет разработчик. Этот код выполняется перед синтаксическим и другим контролем расширения и на понятном языке сообщает пользователю о проблеме если она есть и не разрешает использовать расширение.
Проверка запускается после обновления конфигурации или перед попыткой установить расширение.
Дойдёт ли до реализации, не знаю.

(3) Спасибо, КЭП, но вопрос не об этом. Перечитайте...
(5) что, до сих пор не сделали?

можно в принципе парсинг устроить, но лень...

(6) а в чем вопрос? (3) дает нам список всех процедур, которые с ошибками. А дальше просто иду по этим процедурам и смотрю, что поменялось, если процедуры большие, то сравнение файлов, смотрю, чем отличаются.

(7) в том, что если поменялось количество параметров или название процедуры, то проверка применимости об этом "умолчит", не сталкивались что ли? Я тоже наивно предполагал, что 1С сообщает о таких нюансах.

Напиши в 1с или на партнерском.
Этот вопрос как раз по теме там

(9) а как написать в 1с от меня лично (ну чтобы в корзину не отправили), от лица клиента не хочу? и на партнерском меня нет.

(10) Никак. Нужен франчID

(11) ну вот и напиши от себя, я на авторство не претендую, это же беспредел, такой бардак с расширениями...

(12) ну вот сформируй текст обращения с конфигу с вопроизведением, пришли на [email protected], я отправлю.
pdf и cf.

(12) вообще-то одно из основных изменений в расширении процедуры - это часто добавляются параметры. Поэтому обычно в расширении другое количество параметров и это не ошибка, и проверять количество параметров не нужно. И (10) прав, это пожелание на 99% отправят в корзину.

МенеджерРасширенийКонфигурации (ConfigurationExtensionsManager)
ПроверитьВозможностьПримененияВсех (CheckCanApplyAll)
Синтаксис:
ПроверитьВозможностьПримененияВсех()
Возвращаемое значение:
Тип: Массив.
Возвращает массив объектов типа ИнформацияОПроблемеПримененияРасширенияКонфигурации
Описание:
Проверяет возможность применения всех расширений конфигурации информационной базы в текущей области данных по порядку загрузки с учётом уже участвовавших в проверке расширений.
Доступность:
Сервер, толстый клиент, внешнее соединение.
Использование в версии:
Доступен, начиная с версии 8.3.9.

(14) как ты себе это представляешь? "в расширении другое количество параметров"
с аннотацией &Вместо, &Перед или &После

(16) вот и я не понял, о чем это HHHH, наверное был пьян. Параметры у него множились, ггг

(15) Морт, ты уже второй, который не вкурил, о чем речь в вопросе. Забавно.

(0) Пока только вручную. Восьмерка еще сырая! (с)
Обычно я пишу кейсы по контрольным точкам проверки, для жирных клиентов конечно

(19) вот думаю, пись парсинг или нет. Есть где-нибудь код по разбору кода 1с, чтобы выделить заговолоки функций модулей?

(20) С вашим подходом надо радоваться таким вещам) 1ску клиент обновил, ваши расширения перестали работать. Вы такой, это 1ска такая секая и выставляете пару часиков за работу, чтобы подправить вызываемые функции. Это же золотая жила для вас, а вы хаете))

В многочисленных обсуждениях достоинств и недостатков расширения я о подобной проблеме не раз писал.
И случай изменения количества параметров не самый худший. Эта проблема хотя бы сразу всплывает после обновления. Соответственно разработчик может её быстро исправить. И можно спокойно работать дальше.

Гораздо хуже, когда измененный в расширении метод просто перестаёт использоваться в очередной версии конфигурации поставщика. Например вместо него сделали другой метод. А старый оставили для совместимости. В результате после обновления формально расширение работает и никаких ошибок не выдаёт. Но внесённые расширением изменения/доработки не функционируют.
А с любовью авторов типовых конфигураций и типовых библиотек регулярно перетаскивать методы и функции из одних общих модулей в другие такие ситуации становятся не такими уж и редкими.

Единственный способ решения проблемы (0) - тестирование. Проверка работоспособности каждой доработки каждого расширения после каждого обновления. Собственно говоря то, о чём говорят в (4) и (5).
Как тестировать - личное дело каждого. Для простых случаев можно вручную (написать чек-лист к расширению - что проверить после обновления), и попытаться повесить эту обязанность на заказчика. Для сложных - изобретать свой велосипед или пытаться применять что-то из того что предлагает 1С - сценарное тестирование и т.п. инструменты.

(21) ты перепутал, у меня не такой подход. Я не паразит, я несу клиенту ценность.

(22) это понятно, но соответствие параметров можно было бы выявить и без тестирования, на уровне контроля возможности применения. Удивлен, что 1с это не сделало, а потом Конструктор 1С утверждает, что 1С - не говно.

(21) ошибки исправлять всегда влом - ибо это нужно ппц как срочно, все приходится бросать и исправлять

(20) парсер, а толку от него? Особенный прикол когда ты расширял процедуру например в общем модуле, а после очередного обновления эта процедура безвозвратно канула в лету, причем вместе с модулем :)

(26)
1. Выгружаю всю конфу в файлы.
2. Выгружаю все расширения в файлы.
3. Запускаю парсер, проверяю возможность применения.
Проффит.

(26) так ты это увидишь и подумаешь, что расширять теперь. Не надо паники и всепропальничества

(17) ну, например задача: в функции общего модуля добавить свой параметр, и его обрабатывать в коде функции. По твоему получается, что в расширении это сделать невозможно, и нужно лезьть с изменениями в основную конфигурацию?

(27) проверяешь только по "сходимости" процедур или как то еще?

(27) это все очень долго. Влом будет вме это делать

(28) а что плохого в том чтобы изменять конфигурацию?

(31) вы что, это табу)) это же потом ждать сравнение конфигураций каждый раз, когда ее обновляешь. А когда на замке, щелк щелк и готово)

(23) ну вот, 1ска вам позволяет нести ценность N раз после обновлений)) "а потом Конструктор 1С утверждает, что 1С - не говно." - я так понимаю вы утверждаете обратное?

(31) плохого в том, что после внесения изменений на форму (ну там группу или команду или реквизитов формы напихать своих) при обновлении эти формы обычно хреново обновляются... а программные изменения форм не каждый погромист осилит/заставит себя погромировать

(34) или изменения в дин.списках на формах

(31) это не ваша зона ответственности, а вендора
ваша зона ответственности - адаптировать код вендора под себя

(33) ага, постоянно это утверждаю.

(37) но приходится в по уши в г@вне влачить своё бренное существование (на хлеп с маслом)

(37) получается вы любите работать с говном? Даже профессию связали с этим. Вот это я понимаю отношение к делу с вашим восприятием))

(37) https://rtfm.wiki/_media/windows/vinnie_1c.jpg

(34) Вроде речь зашла про общий модуль. Насчет форм: в расширениях формы автоматически обновляются далеко не во всех случаях.

(36) А где написано что это нельзя делать в основной конфе?

(24) Ключевой смысл моего высказывания в (22) заключается в том, что синтаксический контроль применимости расширения (если когда-нибудь будет сделан) почти никак не решает проблему. Видимо потому в 1С и не хотят особо с этим заморачиваться. Трудозатраты на 100 рублей с выхлопом на 3 копейки. Да ещё и при том, что это никак не снимет необходимость перетестировать все доработки в каждом из расширений после обновления основной конфигурации.

(38) для меня ближе аналогия с доктором. Есть корпорация зла, которая травит людей. А я лечу их, облегчаю их мучения. Так-то. Чумной 1С-доктор, так сказать.

(42) можно, если вы мазохист. В расширении все доработки в одном месте, а так на здоровь, лазайте сравнением-объединением по всей конфе. Не говоря уже о том, если обновляется несколько релизов. Юноша, вы сперва опыта наберитесь, потом своё мнение высказывайте.

(45) Олеш, я хотя бы увижу такие проблемы как ты в сабже описываешь при просмотре дважды измененных.

(46) такие проблемы как я описываю, можно найти парсингом. Мне кажется эпоха "дважды измененных" прошла. Выносить изменения в расширения де-факто становится стандартом. Но если вы предпочитаете мучать код, на здоровье, жаль тех, кто придет после вас обслуживать килиента. Дорого-сердито.

Мне это напоминает одного программиста, который настойчиво изменения в формах делал руками, а не кодом. Ну привык он так. А потом во фране его клиента дали мне и я перетащил все изменения в код, потому что не мазохист.

(47) Васян, точно парсинг, а не фистинг?

Читай тут
Проверка методов при контроле применимости расширения в Конфигураторе
8.3.22 https://wonderland.v8.1c.ru/blog/razvitie-rasshireniy-8-3-22/

(45) Кто бы говорил об опыте. На косяках, с которыми ты только сейчас столкнулся, люди уже не одну собаку съели ещё на заре появления расширений.
И сделали для себя соответствующие выводы - когда расширения нужны и хороши, а когда целесообразнее всё таки основную конфигурацию поломать.

(50) вот смотрю на твой вывод мучать конфигурацию и не понимаю - где здесь мудрость, где тут рацио?

(49) ну хоть что-то:

В версии 8.3.22 проверка таких методов будет сделана и в режиме Конфигуратор. В команду «Проверка применимости расширений» добавятся две проверки для методов, не являющихся обработчиками стандартных событий:

Проверка, что существует метод в основной конфигурации, указанный в аннотации

Проверка, что список параметров метода в расширении соответствует параметрам в основной конфигурации (количество и модификаторы передачи по значению)

Разработчикам будет значительно проще адаптировать расширения в случае изменения основной конфигурации.

В текущей версии 1C:Enterprise Development Tools описанные проверки уже реализованы:


Можно открыть 8.3.22 или IDE и в ней накатить CF на пустую базу и проверить расширения. Гм... хоть что-то.

(50) когда ты на фиксе и когда ты фришник - это немного разные подходы к доработкам

(43) Допустим разработчик продаёт набор расширений. Для каждого релиза своё расширение. Со своей стороны он всё протестировал. А клиент забыл или забил проверить совместимость расширений и получил после обновления непонятные ему ругательства.
Была бы проверка как в (5), получил бы внятное сообщение, либо автообновление расширения.
(52) Это помощь разработчику, а клиента оставили одного разбираться с этим.

(52) все уже получается 1ска не говно и вы больше не ассенизатор?))

(42) нигде, как и многое другое
это смотря какой стиль вы выбираете и какие методики практикуете

(54) а какой код можно написать в проверке расширения.
Вот в типовой перестали юзать метод. Как это кодом можно проверить?

И вообще я говорил про сейчас, а не про всю историю

(58) не туда

(59) а Вафель где?

(55) он как амбре. маскирует г@вно духами

АМБРЕ́

УСТАРЕЛОЕ•ИРОНИЧЕСКОЕ
Приятный запах устар. теперь ирон. о дурном запахе.

французы целую индустрию придумали, чтоб не мыться

(60) в бане за в..ну

(57) Если ВерсияКонфигурации <> СовместимаяВерсияРасширения Тогда
   Сообщить("Обновите МоёРасширение на версию " + СовместимаяВерсияРасширения);
КонецЕсли;

О совместимости конкретного расширения с конкретным релизов разработчик уже позаботился. Проблема в пользователе - он не обновил расширение после обновления конфигурации.

(53) >> когда ты на фиксе и когда ты фришник - это немного разные подходы

Безусловно это тоже учитывается.
Тут даже дело не в фикс/фриланс. А в том сопровождается ли конфигурация в одно лицо единственным человеком (не важно - фикс/фрилансер), который может контролировать каждое изменение/доработку и ставит заказчику обновления. Или речь идёт о разовой доработке, которая должна работать в отрыве от своего автора после любого обновления исходной конфы.

Вообще факторов множество. И каких-то единых универсальных подходов нет. Есть только какие-то общие принципы, которые в отдельных случаях тоже не особо подходят.
Типа несвязанные между собой доработки лучше делать в разных расширениях. Но при этом расширения одного и того же объекта метаданных лучше чтобы были в каком-то одном расширении.
Расширением данных лучше не пользоваться (если возможно).
Серьёзные доработки каких-то сложных и больших подсистем (например, расчет НДС) лучше делать в самой конфе. Во всяком случае пока 1С не предоставит механизм трёхстороннего сравнения с расширением (основная конфа / новая конфа поставщика / расширение). Или хотя бы просто сравнения основной конфигурации с конфигурацией расширения.
Не злоупотреблять в расширениях использованием программного интерфейса стандартных библиотек. Т.к. библиотеки меняются ещё чаще самих конфигураций.
Список можно ещё дальше продолжать. У каждого разработчика он свой и зачастую зависит не только от собственного опыта, но и от конкретных конфигураций.

(57) >> Вот в типовой перестали юзать метод. Как это кодом можно проверить?

Да никаким.
Если неиспользуемый метод из конфигурации поставщик не удалил, а оставил (для совместимости, например), то об этой прекрасной новости нам сообщит пользователь с криками "А-а-а-а-а! Всё пропало! Ваша доработка не работает!". Причем иногда это может происходить спустя много времени после того, как проблема возникла.
Был случай, когда в расширении к БП был доработан механизм заполнения регистра ЗаписиКнигиПокупок. Маленькая простейшая доработка. Несколько кварталов конфа регулярно обновлялась и всё прекрасно работало. После какого-то очередного обновления расширенный метод перестал вызываться. Проблема всплыла только спустя месяц или два, когда бухгалтеры начали сводить отчетность по НДС (книги, журналы, декларацию).

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

(64) в корне не согласен. Расширения для того и придуманы, чтобы ядро не ковырять. Привыкайте к правильным методикам программирования

(66) Васян, а как ты запросы в расширении пишешь и без контекстной подсказки работаешь?

(66) Никакие "правильные" методики программирования не работают без правильных методик поддержки разработанного кода.
Пример в (0) - яркое тому доказательство.
Сначала ты через *опу что-от напрограммировал, а потом твоё через*опное творение эпическим образом отвалилось после обновления.
Если это пример правильных методик, то либо методики не совсем правильные, либо те, кто их применяет, что-то делают не так.

>> Расширения для того и придуманы, чтобы ядро не ковырять.

Твоё понимание расширений - это твоя личная фантазия, не основанная ни на чём. 1С нигде не декларировала подобных целей (закрыть ядро для изменений).
И это твоё понимание связано с двумя проблемами. Первая - крайне малый опыт создания сложных расширений. Вторая - отсутствие опыта длительной поддержки сложных расширений после более чем десятка обновлений основной конфигурации.
Одно дело - состряпать простое расширение, добавляющее какой-нибудь реквизит в документ, на форму, и обработку этого реквизита в проведении.
И совсем другое - поддерживать зоопарк различных расширений, каждое из которых лезет в базовые процессы и прикладную бизнес-логику конфигурации. Которые пересекаются между собой и затрагивают десятки объектов из различных подсистем.

Наберешься опыта и мнение твоё серьёзно поменяется. Вот увидишь. Я когда-то тоже нёс пургу похожую на то, что ты сейчас говоришь.

(66) так ты и не умел никогда программировать

(67) так можно же добавить нужные метаданные.
и таки 1с рекомендует их добавлять

(70) Есть ссылка на рекомендацию?

(68) Расширения можно и нужно использовать для изменения, в т.ч. и базовых алгоритмов.
Современные типовые просто невзлетят без расширений, как в скорости разработки, так и в поддержке обновлений.
Ваш негативный опыт - это ваш негативный опыт, эдакий синдром утенка.

(72) у лохов ничего не взлетит

Расширение конфигурации.

было
Данная возможность не предоставлялась.    

стало
Для команды Конфигуратора Проверка применимости расширений реализованы дополнительные проверки:
Проверка существования метода, указанного в аннотации.
Проверка соответствия количества параметров методов и модификаторов передачи значений в методе основной конфигурации и расширения.
Данные проверки выполняются для методов, которые не являются обработчиками событий.

з0чем
Упрощено исправление ситуаций, когда в основной конфигурации перестал существовать расширяемый метод или у расширяемого метода изменилось количество параметров или модификаторы передачи параметров.

Источник: https://dl03.1c.ru/content/Platform/8_3_22_1368/1cv8upd_8_3_22_1368.htm#87d8d2b8-7910-11ec-aa69-0050569f678a