Допустим выгрузить конфигурацию в файлы.
Скопировать нужные файлы в каталог с будущим расширением.
В файлах расширения изменить ГУИД-ы.
В файлах конфигурации изменить имена объектов.
Потом все это дело загрузить в конфигурацию и расширение.

Взлетит? Или это фантастика?

(0) Советую свои реквизиты и объекты в расширение не тащить.

Не взлетит

(1) +100500

(1), (3) Спорить не буду. Но (0) возможен или нет?

(2) "Какие ваши доказательства?"

(4) Если Вы готовы пройти через тысячу ошибок формата потока, то флаг Вам в руки, барабан на шею и паровоз навстречу.

(0) Можно.
А можно просто поставить EDT

(6) Ну ок. Доводы, конечно но такие себе.

(7) Хм. И куда там глянуть? Разверни мысль, плиз.

комменты изучи https://infostart.ru/public/1304175/

для EDT вроде плагин видел но сейчас не могу найти

Я тоже голосую за EDT. Там хотя бы виден свет в конце туннеля.

(0) А как код собираешься переносить в расширение?

(0) видел способ превращения конфигурации расширения в конфигурацию, пользовался сам, работает
но там было "пару байтов об асфальт"
а менять гуиды - не наглотаешься ли пыли?

(9) Почитал, спасибо.

(11) Копи-пастой. Или там тоже могут быть какие-то вопросы?

(12) Что за способ?

(1)(3) Можно конкретные примеры проблем?

(13) Кода меньше, чем объектов? Если код переносить будешь копи-пастой, то и объекты так перенеси

(15) Перенос кода, это перенос кода. А перенос объекта это перенос реквизитов и их типов, вот тут ИМХО самое длительная и кропотливая работа.

(14) Перенос доработок конфигурации в расширение

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

(16) Копи-паст переносит с сохранением типа. Так много объектов, что проще потратить время на разбор структуры, отладку программы, чем копи-пастом перенести?

(18) Ситуации же разные бывают, потому странно, когда категорично такое заявляют.
А чем вам в сравнении помешал созданный в расширении объект?
А примеры пропажи данных можете привести? Вот на ровном месте пропали созданные в расширении объекты? Так-то при должном "умении" и всю базу можно потерять без всяких расширений.

(19) В том-то и проблема. )) Типы-то тоже частично переезжают в расширение. Ну на первый взгляд дофигища...

(20) Можно. Но объекты в расширении теряются быстрее. :)

(20) см (17)

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

(13) "Что за способ" - в поиск, я не сохранял ссылку
надеюсь больше не понадобится

ОФФ.
🤔 Странное вы что-то обсуждаете...
Как можно автоматизировать перенос в расширение доработок кода?
Кроме быть может совсем уж простых.
Большинство доработок в конфигурации и в расширении делаются по разному и не переносимы прямым копипастом.
Точнее практически все, кроме каких-нибудь совсем простых случаев типа добавить реквизит и вывести поле для его редактирования на форму объекта.
А ещё есть проблема функциональности расширений, которая меняется от версии к версии.

(20) Пока не появится вменяемый инструмент, позволяющий сравнивать конфигурацию с расширением и в одном окне видеть все доработки в графическом виде, функциональность и применимость расширений останется весьма и весьма ограниченной.
О проблеме совместимости нескольких расширений я вообще молчу. Если у вас больше двух расширений, которые могут пересекаться между собой, единственным способом хоть как-то контролировать их работоспособность, комплементарность, совместимость, консистентность и вообще корректную работу друг с другом и с основной (расширяемой) конфигурацией, остаётся исключительно только тестирование. Причём тестирование полноценное - с максимальным количеством возможных сценариев, ролей и прав пользователей, исходными данными и т.д.
Расширения идеальны в качестве временных патчей (исправления, которые будут немедленно удалены сразу после выхода очередного релиза конфигурации, где исправления будут уже внутри самой конфигурации), подключаемых отчетов и обработок (вместо старого механизма внешних отчетов и обработок), и для доработок выполненных полностью независимо от основной конфигурации, "сбоку" без вмешательства в объекты расширяемой конфигурации (хотя такие вещи проще сделать внутри самой конфигурации). Для всего остального следует внимательно подумать - стоит ли связываться с расширениями, чтобы потом время, которое было сэкономлено при установке обновления конфигурации тратить на разбор косяков и причин, по которым доработка в расширении вдруг перестала работать корректно ожидаемым образом.

(26) >>в одном окне видеть все доработки в графическом виде

Есть кнопка "измененные и добавленные в расширении".

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

(26) Так кто спорит, это только подтверждает, что применяемость зависит от ситуации.

(20)У меня тоже ни разу не было проблем с хранением данных в расширении. Но где-то тут читал что при ТИИ пропадали данные у людей.

(24)Ну чтобы добавить новый объект в конфу нужно же включить возможность редактирования конфигурации, так?

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

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

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

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

ИзменениеИКонтроль в помощь

>>Когда программа просто молча отрабатывает (без ошибок), но результат выдаёт вовсе не тот, который ожидает пользователь.

Ты это только тестами отследишь

(32)Понял вас. В (24) вы пишете что никак не усложняют обновления. А в (32) пишете что чуть дольше будет. Как-то не сходится :)

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

(35) а что сложнее чуть дольше обновление, или разбор глюков если расширение отвалится ?

(36)Какая разница то? :) Если в конфе что-то поменялось на что были завязаны доработки, то переписывать нужно будет как если бы доработки были в конфе, так и если бы они были в расширении.

Время затраченное на обновление дороже.

(34) >> ИзменениеИКонтроль в помощь

Костыль. Не решает и половины возникающих проблем.

>> Ты это только тестами отследишь.

Именно об этом  я и говорю.
Кстати доработок внутри конфигурации это тоже касается.
Но доработки внутри конфигурации хотя бы видны глазами в окне трёхстороннего сравнения/объединения при обновлении.
Доработки в расширении в сравнении с основной конфигурацией не видны никак. Только руками открывать каждый объект/модуль и глазами просматривать.

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

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

(39) (40) какой-то поток дичи

(40) поддерживаю

(40)Вот веришь, нет, не приходится ничего искать глазками, всё работает и всё обновляется на ура.

(40) У меня 30 баз бух и 30 зуп, вижу в страшном сне как я бы их обновлял "просматривая глазками", спасибо, не надо.
Расширения, при грамотном использовании - классная технология, которая снимает кучу головняка.

И обновлятор форева!

(40) Разница в скорости обновления.

Когда у тебя доработки в расширениях можно быстро обновить типовую на замке.
И она будет работать!
Позволит сдать отчетность вовремя.
И далее можно не торопясь восстанавливать работу только нужных расширений.

А не сидеть ночью и в выходные мыле, сводя обновления.

(46)+ Но это конечно если доработки не значительные, почти все софтовые.
Хард доработок с новыми реквизитами/метаданными почти нет.

Если же туева туча хард-доработок, тогда логично снимать с замка и почти все пилить в самой конфе.
Особенно если вмешательства в типовые регламентные механизмы, тут кроме как ручками/глазками каждое обновление никак да.

Ну и еще разница в том насколько надо привязать базу к себе - актуально для некоторых.
Чтобы без разраба в теме даже обновиться не смогли ))