Ситуация, когда после обновления платформы 1С режим «1С:Предприятие» запускается без проблем, а при попытке войти в «Конфигуратор» система выдает ошибку о несоответствии версий, является довольно распространенной. Особенно часто это встречается при переходе на новые ветки платформы, такие как 8.3.22 и выше. На первый взгляд ситуация кажется парадоксальной: база открывается, версия в справке совпадает, но разработчик или администратор не может приступить к работе. Давайте подробно разберем, почему это происходит, и проанализируем шаги, которые помогут полностью устранить проблему.
Проанализируем архитектуру установки современных версий 1С. Начиная с последних релизов, компания 1С предоставляет несколько вариантов инсталляторов. Основная причина нашей проблемы кроется в том, что для работы в режиме «1С:Предприятие» (управляемое приложение) достаточно наличия Тонкого клиента. Однако для работы «Конфигуратора» технически необходим Толстый клиент.
Рассмотрим ситуацию: при обновлении системный администратор мог скачать и установить только пакет setuptc.exe (Тонкий клиент). В этом случае в папке с новой версией платформы (например, C:\Program Files\1cv8\8.3.22.1923\bin) просто отсутствуют необходимые файлы для запуска конфигуратора. Когда вы нажимаете кнопку «Конфигуратор» в окне запуска, система пытается найти исполняемые файлы. Не найдя их в папке новой версии, загрузчик может попытаться обратиться к файлам старой версии платформы. В итоге возникает конфликт: база уже переведена на новый формат версии 8.3.22, а конфигуратор пытается запуститься от версии 8.3.21. Именно это и вызывает сообщение о несоответствии.
Решение: Убедимся, что на компьютере установлена именно «Технологическая платформа», а не только ее «Тонкий» компонент. Необходимо запустить полный инсталлятор (setup.exe) и в списке компонентов проверить наличие пункта «1С:Предприятие — Толстый клиент и конфигуратор».
Разберем, как работает механизм выбора версии. За запуск 1С отвечает стартер 1cestart.exe. Он анализирует настройки информационной базы и пытается подобрать наиболее подходящую версию платформы из установленных в системе.
Иногда возникают ситуации, когда в настройках конкретной базы жестко прописана версия, или же стартер «засыпает» и не видит свежеустановленную папку. Посмотрим, как это проверить:
8.3.21, то даже при наличии установленной 8.3.22, конфигуратор будет пытаться запуститься на старом ядре.Для исправления ситуации рекомендуется либо оставить это поле пустым, либо указать маску 8.3, чтобы система всегда выбирала самый актуальный релиз в рамках ветки.
Выясним причину, связанную с разрядностью. В клиент-серверном варианте работы крайне важно соответствие разрядности библиотек. Если на сервере установлена 64-битная версия 8.3.22.1923, а на локальном компьютере администратора установлена 32-битная (x86) версия того же самого релиза, то при определенных условиях взаимодействия (особенно при запуске конфигуратора) может возникнуть ошибка несоответствия. Это происходит из-за того, что конфигуратор требует прямого взаимодействия с серверными компонентами через COM-соединения или специфические библиотеки, которые чувствительны к разрядности процесса. Мы рекомендуем использовать идентичную разрядность на стороне сервера и на рабочих местах администраторов.
Посмотрим на настройки системного уровня. В папке с установленной платформой (обычно C:\Program Files\1cv8\conf) находится файл conf.cfg. Это текстовый файл, который управляет поведением загрузчика. Рассмотрим пример его содержания:
SystemId=1C:Enterprise
ConfLocation=C:\Program Files\1cv8\conf
InstalledLocation=C:\Program Files\1cv8
Если в этом файле или в аналогичном файле в папке конкретной версии прописаны некорректные пути (например, параметр InstalledLocation ведет в папку, где нет исполняемых файлов конфигуратора), запуск будет обрываться с ошибкой. Проанализируем этот файл на предмет «зависших» путей от старых установок, которые могли остаться после некорректного удаления предыдущих версий платформы.
Если переустановка толстого клиента не помогла, разберем методику полной очистки временных файлов. Обычное удаление базы из списка и повторное добавление очищает только пользовательские настройки, но не затрагивает кеш конфигураций. Выясним, где хранятся эти данные.
Необходимо очистить следующие директории (замените UserName на имя вашего пользователя):
%AppData%\1C\1cv8%LocalAppData%\1C\1cv8В этих папках хранятся идентификаторы баз и закэшированные метаданные. При обновлении платформы (особенно при переходе между техническими ветками, как с 8.3.21 на 8.3.22) старый кеш может конфликтовать с новыми механизмами отрисовки интерфейса конфигуратора, вызывая ложные сообщения о несоответствии версий. Важно: перед удалением убедитесь, что все процессы 1cv8.exe и 1cv8s.exe завершены через диспетчер задач.
Рассмотрим ситуацию с ярлыками на рабочем столе. Часто пользователи и администраторы создают ярлыки, ведущие напрямую к исполняемому файлу версии, например:
"C:\Program Files\1cv8\8.3.21.1644\bin\1cv8.exe" CONFIG /F "ПутьКБазе"
Если вы обновили платформу до 8.3.22.1923, а база данных уже была открыта в режиме предприятия под новой версией, она автоматически конвертируется под новый релиз. Попытка запустить такой ярлык (ведущий к 8.3.21) в режиме CONFIG приведет к ошибке, так как старый исполняемый файл не может работать с обновленной структурой базы. Проанализируйте свойства ваших ярлыков и замените прямые пути на вызов универсального стартера 1cv8s.exe или актуализируйте путь к новой версии.
Подводя итог, можно составить пошаговый план действий при возникновении ошибки несоответствия версий в Конфигураторе:
setup.exe из полного дистрибутива и доустанавливаем компонент.AppData, если первичные меры не помогли.8.3.22 может блокироваться системой безопасности, что приводит к откату загрузчика на старые версии библиотек.Следуя этой методике, мы гарантированно восстановим работоспособность Конфигуратора и обеспечим стабильную работу системы после обновления.