Имя исходного каталога макета слишком длинное visual studio
Обновлено: 04.07.2024
Я сделал автономный установщик VS Community 2019. При запуске из этого места установщик сообщает о следующей ошибке:
Исходный каталог макета слишком длинный. Имя каталога макета должно быть меньше символов.
2 ответа
Я пытаюсь использовать TypeScript 2.8 в своем Visual Studio 2019 году, поскольку моя команда использует эту версию TS. Однако, когда я перехожу к свойствам проекта -> TypeScript Build, он говорит, что версия недоступна . Я попытался установить эту конкретную версию TS SDK с помощью установщика.
Я хочу перейти с Visual Studio 2017 на Visual Studio 2019 года. Кто-нибудь знает способ не потерять мои проекты и настройки?
Windows OS имеет такое ограничение, что ваш путь не может быть больше определенного числа. Установите его в более простые каталоги уровня диска, такие как "C:\Program Files\Visual Studio" или "C:\Visual Studio". дополнительная иерархия добавляет к вашему пределу, а сама установка VS создает множество каталогов внутреннего уровня, и в какой-то момент некоторые из них могут достичь предела.
Я переместил всю установку на свой диск c, и она сработала. У меня есть 500 ГБ свободного места на моем диске C
Похожие вопросы:
Я недавно обновился до Visual Studio 2013 (с установленным расширением установщика) с 2010 года, и теперь, когда я перестраиваю свой проект установщика Visual Studio, появляется окно установки.
У меня есть пользовательское действие, которое выполняется как установщик Visual Studio Projects deployment. Можно ли указать рабочий каталог этого пользовательского действия относительно каталога.
Есть 2 варианта установщика Visual Studio Code, пользователя и установщика системы. Я забыл, какую версию я установил. Как определить, какую версию я использую? Versión: 1.40.2 (system setup).
Я пытаюсь использовать TypeScript 2.8 в своем Visual Studio 2019 году, поскольку моя команда использует эту версию TS. Однако, когда я перехожу к свойствам проекта -> TypeScript Build, он.
Я хочу перейти с Visual Studio 2017 на Visual Studio 2019 года. Кто-нибудь знает способ не потерять мои проекты и настройки?
Я пытаюсь построить решение VS 2017, которое включает в себя проект установки Visual Studio с только что выпущенным Visual Studio Pro 2019. Конечно, когда я попытался открыть решение, я получил.
4 декабря 2018 года был выпущен Visual Studio 2019 Preview 1. 27 февраля 2019 года они выпустили Preview 4 и одновременно Visual Studio 2019 RC. Я бы предположил, что при выпуске RC они прекращают.
Мы используем “Visual Studio Offline Layout” для развертывания VS 16.6 как для разработчиков, так и для buildservers со смешанными интернет-соединениями (offline / proxy / direct). До недавнего.
Я не могу начать проект Blazor в Visual Studio году. Visual Studio версия: сообщество 2019 (16.6.4) Я уже пробовал: Узнайте, ограничены ли Шаблоны Blazor профессиональными или корпоративными.
Многим пользователям ПК под управлением ОС Windows, не говоря о разработчиках, знакомы проблемы при работе с длинными (более 260 символов, MAX_PATH) путями файлов или каталогов.
Приложения Win API
В приложениях, которые используют Win API для работы с файлами, рецепт избавления от ограничения MAX_PATH был известен с незапамятных времён – необходимо было использовать Unicode версию функции с окончанием «W» для работы с директорией или файлом и начинать путь с префикса \\?\. Это давало возможность использовать пути длинной до 32767 символов.
В Windows 10 (1607) поведение функций для работы с файлами изменилось: появилась возможность отключить проверку ограничений MAX_PATH на уровне системы.
Для работы с каталогами: CreateDirectoryW, CreateDirectoryExW, GetCurrentDirectoryW, RemoveDirectoryW, SetCurrentDirectoryW. И для работы с файлами: CopyFileW, CopyFile2, CopyFileExW, CreateFileW, CreateFile2, CreateHardLinkW, CreateSymbolicLinkW, DeleteFileW, FindFirstFileW, FindFirstFileExW, FindNextFileW, GetFileAttributesW, GetFileAttributesExW, SetFileAttributesW, GetFullPathNameW, GetLongPathNameW, MoveFileW, MoveFileExW, MoveFileWithProgressW, ReplaceFileW, SearchPathW, FindFirstFileNameW, FindNextFileNameW, FindFirstStreamW, FindNextStreamW, GetCompressedFileSizeW, GetFinalPathNameByHandleW.Это избавляет от необходимости использовать префикса \\?\ и потенциально даёт шанс приложениям, работающим напрямую или косвенно через Win API, получить поддержку длинных путей без необходимости их пересборки. Как активировать эту возможность описано в конце статьи.
Тут поддержку длинных путей анонсировали ещё в ноябре 2015 года. Видимо сказалось Open Source природа проекта и отсутствие строгой необходимости обеспечения обратной совместимости.
Вот тут можно посмотреть пример.
Как включить поддержку длинных путей в Windows 10 (1607)
Эта возможность по умолчанию отключена. Это объясняется тем, что данная функция является экспериментальной, и имеется необходимость дорабатывать различные подсистемы и приложения для полной поддержки.
Включить встроенную поддержку длинных путей можно создав или изменив следующий параметр системного реестра: HKLM\SYSTEM\CurrentControlSet\Control\FileSystem Параметр LongPathsEnabled (Тип: REG_DWORD) 1 – соответствует значению включено.
Или через групповые политики (Win+R\gpedit.msc) Computer Configuration > Administrative Templates > System > Filesystem > Enable NTFS long paths.Оно же в локализованном варианте: Конфигурация компьютера > Административные шаблоны > Система > Файловая система > Включить длинные пути Win32.
Далее источники расходятся во мнении относительно манифеста (или я неправильно понял, но на данный момент проверить не имею возможности). Например, в документации MSDN написано, что манифест можно использовать в качестве альтернативного способа активации поддержки длинных путей в отдельных приложениях, а в блоге MSDN указано, что это является вторым обязательным шагом после активации в политиках.
Но они сходятся в формате задания данной опции:
С CMD, к сожалению, это не сработает, на данный момент, из-за особенностей работы с путями, а в PowerShell должно всё заработать.
На этом мой небольшой пятничный пост заканчивается, оставив за рамками вопросы полноты реализации поддержки длинных путей в Windows 10 (1607), или работоспособность при использовании различных комбинаций редакций Windows, файловых систем и API. По мере поступления новых фактов и результатов экспериментов пост будет обновляться.
The text was updated successfully, but these errors were encountered:
ghost commented Jun 20, 2014
Какое поведение ты ожидаешь ?
Может пока укоротишь наименование тестов ?
artbear commented Jun 20, 2014
В описании задачи я описал свои предложения
- для макетов генерить файлы сразу в папке Макеты, без создания доп.вложенного каталога
- если оставляем вложенный каталог, тогда имя файла делать коротким, например, 1.mxl , т.к. все равно имя макета задано в имени каталога.
ИМХО сокращать наименования тестов = "прятать голову в песок", т.к. в этом случае мы просто маскируем проблему. В дальнейшем она также может выскочить по разным причинам у разных пользователей (например, репо развернут на длинном пути)
Мне нравится вариант 1, т.к. имя макета у нас всегда уникально.
Мне пока непонятно, почему Женя реализовал именно вариант дублей имен макетов.
pumbaEO commented Jun 20, 2014
Попробуй добавить настройку в git. Уменьшать нужно - это понятно, как
быстрый bugfix для 2008
|git config core.longpaths true
|
20.06.2014 18:01, artbear пишет:
- для макетов генерить файлы сразу в папке Макеты, без создания
доп.вложенного каталога - если оставляем вложенный каталог, тогда имя файла делать коротким,
например, |1.mxl|, т.к. все равно имя макета задано в имени каталога.
artbear commented Jun 20, 2014
Женя, настройка git config core.longpaths true что дает?
artbear commented Jun 20, 2014
Насколько я понимаю, эта настройка работает с 1.9.0 и выше
А как выяснили, народ каких только Гит не юзает :(
artbear commented Jun 20, 2014
Возможное исправление настройки Гит это возможное решение части проблем.
Но ведь еще и v8Reader, который выдает ошибку на длинных именах.
ИМХО это нужно решать сначала.
pumbaEO commented Jun 21, 2014
Более точна ссылка на git - commit пытающийся решить проблему.
msysgit/git@8439375
Для v83unpack я эмперическим путем определил, что название каталога не
должно быть больше 63 символов, тогда на win платформе git будет
переваривать репозитарий.
20.06.2014 18:21, artbear пишет:
Возможное исправление настройки Гит это возможное решение части проблем.
Но ведь еще и v8Reader, который выдает ошибку на длинных именах.
ИМХО это нужно решать сначала.—
Reply to this email directly or view it on GitHub.
artbear commented Jun 21, 2014
artbear commented Jun 21, 2014
Я уже как-то задавал вопрос - кто сейчас пилит v8Reader ? у кого последние правки?
У нас в сабже, у автора или еще кого?
artbear commented Jun 21, 2014
ghost commented Jun 21, 2014
По ссылке Жени, это не баг v8reader
as long paths are not supported by Windows Explorer
это мы нарываемся на баг, недочет Windows.
Ты слишком длинно называешь тесты. Даже если мы будем использовать обновлять всем GIT до максимальной версии. Тогда люди в Проводнике не увидят файлов по таким длинным путям. И в консоли не увидят.
Windows paths are typically limited to MAX_PATH = 260 character
Данный баг можно Windows можно только обойти. Остается решить вопрос как.
Очередной раз предложу тебе использовать другое правило именования тестов.
ghost commented Jun 21, 2014
должно быть больше 63 символов, тогда на win платформе git будет
переваривать репозитарий.
скорее всего это еще связанно с русскими символами в наименовании. английский путь был бы длинней. Видимо русские символы кодируются несколькими байтами (или чего там в внутри WinAPI)
Видимо использование русских символов сокращает этот размер.
У нас используется cmd для выгрузки, значит на нас действуют его правила.
Тогда опять же мы приходим к тому, что длинна названия обработки epf и erf в случае использования русских символов не должны быть большой или на английском
pumbaEO commented Jun 22, 2014
artbear commented Jun 22, 2014
- обнаружил, что на моем домашнем репозитарии не установлен precommit1C
- установил последнюю версию precommit1c 1.1
но при этом во время разбора в 1С:Предприятии была ошибка
ошибка была следующая:
: Ошибка при вызове метода контекста (КопироватьФайл) КопироватьФайл(ФайлМакетаИсходный.ПолноеИмя, ПутьНовый); по причине: Ошибка копирования файлов по причине: Ошибка копирования файлов из 'C:\Users\1\AppData\Local\Temp\ТестыГенератораДанных1CUnit.epf473.und\f519cbc0-1404-4ef3-9377-16955dc46254.0' в 'C:\Projects\GitHub\xUnitFor1C\src\Тесты\ТестыГенератораДанных1CUnit\Макеты\Тест_ДолженПолучитьИсключениеПриПопыткеСоздатьЭлементИЗаполнитьРеквизитПоНеверномуНаименованию\Тест_ДолженПолучитьИсключениеПриПопыткеСоздатьЭлементИЗаполнитьРеквизитПоНеверномуНаименованию.mxl' : Каталог не обнаружен
Сразу видно, что имя макета дублируется ДВАЖДЫ-ДВАЖДЫ
C:\Projects\GitHub\xUnitFor1C\src\Тесты\ТестыГенератораДанных1CUnit\Макеты
Тест_ДолженПолучитьИсключениеПриПопыткеСоздатьЭлементИЗаполнитьРеквизитПоНеверномуНаименованию
Тест_ДолженПолучитьИсключениеПриПопыткеСоздатьЭлементИЗаполнитьРеквизитПоНеверномуНаименованию.mxl
Напоминаю, что сабж вместе с xUnitFor1C мы юзаем довольно давно, подобных проблем не было ни разу !!
А вот после использования НОВОЙ-НОВОЙ версии появились проблемы.
Логично, что проблемы в новой-новой версии, а не только, и не столько в именах тестов.
ЗЫ я устал уже доказывать простейший баг. Что еще нужно написать, чтобы вы увидели проблему в целом и в частностях, а не только в длинных именах ?
Неизвестная ошибка сборки: 'Указанный путь, имя файла или оба они тоже длинный. Полноценное имя файла должно быть менее 260 символов, и имя каталога должно быть меньше 248 символов. '
Кто-нибудь может мне помочь? Я уже проверил все поля, и их пути расширения в порядке. Это может быть проблема с TortoiseSVN или что-то вроде этого? Я недавно добавил папку в мое решение, может быть что-то с этим?
Это хорошо известное ограничение в Windows win32 api. Каталог, в котором вы сохранили свой проект, находится слишком глубоко. Полное имя пути к файлу не может содержать более 259 символов. Помимо этого, много C-кода, использующего MAX_PATH, начинает сбой из-за переполнения буфера.
Переместите решение в другой каталог, который ближе к корню.
Не беспокойтесь. Эта ошибка возникает из-за длинного имени пути. Предположим, что ваше имя папки проекта "myproject".
Вы просто измените местоположение папки проекта. Поместите свой проект "myproject" в D:\myproject или или в файл F:\myproject. Затем вы опубликуете еще раз. Он работает.
Это проблема с созданием защитной рабочей области "Создание расположения папки агента" VS добавляет пример путей: $ (SourceDir) E:\Somedirectory\ProjectName \ Просто сохраните $(SourceDir) в файле
У меня была та же проблема. Мой путь проверки был короче пути, используемого на моем CI-сервере. Он построил ОК на сервере CI и всех моих коллегах. Наши пути имеют одинаковую длину, поскольку наша компания имеет фиксированные имена пользователей. Я был единственной машиной, которая не могла построить решение из-за длинных путей.
Если вы перейдете в эти папки:
C:\Users\[имя_пользователя]\AppData\Local\Temp
Найдите версию .NET, которую вы используете с вашим решением, а затем удалите папки "Временные файлы ASP.NET", из которых когда-либо использовались версии вашей сборки.
Вы можете удалить их все, ваша следующая сборка веб-проекта может занять немного больше времени, поскольку не будет предварительно скомпилированных сборок.
Поиск строки ошибки VS дает вам привести меня сюда, поэтому я решил, что это может помочь кому-то другому, если не Op с проблемой сборки WPF.
Если это не удастся - вы можете попробовать рекурсивно выполнить поиск корня решения для файлов/папок с путями, которые больше 260, выполнив следующее:
Читайте также: