Как я могу запретить Visual Studio 2005 «Очистить» команду удалить сторонние двоичные файлы?

У меня есть проекты Sitecore/ASP.NET, которые я разрабатываю. Сегодня в какой-то момент я непреднамеренно попал в «Чистый» вариант в контекстном меню решения. Мне потребовалось некоторое время, чтобы выяснить, почему мой сайт был безнадежно сломан. Оказывается, Visual Studio пошла дальше и удалила несколько необходимых сборок из каталога \ bin, которые не являются частью моего проекта.Как я могу запретить Visual Studio 2005 «Очистить» команду удалить сторонние двоичные файлы?

Как я могу предотвратить это снова?

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

Sitecore.Analytics.dll
Sitecore.Client.XML
Stimulsoft.Base.dll
Stimulsoft.Report.dll
Stimulsoft.Report.Web .dll
Stimulsoft.Report.WebDesign.dll
Telerik.Web.UI.dll

UPDATE: Вы знаете, что ... Я думаю, что я на самом деле больше интересует здесь WH Y Visual Studio оставляет большинство файлов и удаляет только те из них.

источник

2010-02-23 Bryan

Разве он не удаляет все в папке с bin? –

Это определенно не так. Большинство бинарных файлов Sitecore (размещенных установщиком) остаются в такте. – Bryan

Из удаляемых файлов все они либо выводятся из проектов, либо ссылаются на зависимость проекта? –

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

bin и obj папки, сгенерированные проектом, являются наилучшими считанными «выходными» папками; эти папки должны содержать только файлы, создаваемые сборкой проекта.

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

Вам должно быть удобно, что это происходит.

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

Предпочтительным способом ссылки на скомпилированные сборки является их размещение где-то внутри исходных папок. Оттуда они могут быть добавлены в систему управления версиями так же легко, как и любой другой файл, и их можно ссылаться/копировать по проектам, которые зависят от них. В моей работе у нас есть папка «Библиотеки», которая содержит множество сторонних сборок, на которые ссылаются несколько проектов в нашей иерархии решений.

Попробуйте использовать дерево исходного кода, как это и увидеть, если он работает для вас:

/Проекты/Мое решение/
/Проекты/Мое решение/Библиотеки/
/Проекты/Мое решение/Проект A/
/Проекты/Мое решение/Проект Б/

источник

2010-02-23 11:42:37

Герой ... ваш ответ имеет смысл на поверхности ... по крайней мере, возможно, что Visual Studio * должна вести себя. Но это явно не так, поскольку clean/rebuild оставляет много других DLL в каталоге bin, которые не построены или не ссылаются на мой проект. Мой проект настроен так, как рекомендует Sitecore. – Bryan

Если вы вручную удалите каталог 'bin' и выполните команду Rebuild, каков результат? –

Бедствие. Sitecore рекомендует, чтобы корень вашего проекта был корнем веб-сайта ... где он установил много DLL в каталог \ bin. Удаление bin dir приведет к удалению всех этих файлов и уничтожению вашего веб-приложения. – Bryan

Я считаю, что если вы поместите эти файлы в подкаталог, отличный от bin, Visual Studio не удалит их. Вы все равно можете сделать новый подкаталог частью развертывания.

источник

2010-02-23 02:52:47

Поместите DLL в другой каталог. Вы, вероятно, не захотите, чтобы они были частью проекта. Ссылка на dll из нового каталога. При компиляции библиотеки dll будут скопированы в каталог bin.

Я работаю с большим количеством проектов и держу каталог bin в корне своих проектов, чтобы хранить сторонние DLL именно по этой причине.

Пример структуры каталогов:

 
MyProjects 
- bin 
    - 3rdParty.dll 
- Project1 
- Project2 
- ProjectN

Это позволяет все проекты имеют хорошо известное местоположение ссылки на 3-й партии библиотеки DLL без необходимости копировать DLL в каждый проект.

Если вы работаете в команде, вы все должны согласиться с стандартной структурой каталогов для вашего кода. Это избавит вас от многих головных болей за пределами этого.

источник

2010-02-23 03:43:01 Brian

Да, это было бы здорово, если бы эти DLL-файлы действительно ссылались на мой проект, и я не работал над приложением ASP.NET. – Bryan

В случае Sitecore просто убедитесь, что задано свойство ссылки (Sitecore.Kernel, Sitecore.Client и т. Д.): «Копировать локальное» = false.

источник

2010-02-23 09:00:19

Этот хороший сэр - ваш ответ, Sitecore docs и training вызывают это. – techphoria414

Мы всегда добавить событие AfterBuild в файл проекта, содержащий Sitecore.

<Target Name="AfterBuild"> 
    <CreateItem Include="$(SolutionDir)\Third Party\Sitecore\*.*"> 
     <Output TaskParameter="Include" ItemName="FilesToArchive" /> 
    </CreateItem> 
    <Copy SourceFiles="@(FilesToArchive)" DestinationFolder="$(TargetDir)\%(FilesToArchive.RecursiveDir)" /> 
    </Target>

Где объект CreateItem Include - это путь к тому месту, где вы разместили свои бинарные файлы Sitecore.

источник

2010-02-23 11:44:39 pbering

+1 Для разумного использования msbuild. Возможно, вы захотите добавить некоторые детали о том, где разместить эту конфигурацию, хотя :) –

Ну, я собираюсь идти дальше и отвечать на свой вопрос, так как кажется, что это самый простой ответ. Я отметил эти сборки как «Только для чтения». Теперь их не очищают.

По-прежнему интересно, почему большинство других не удаляются.

источник

2010-02-24 00:37:39 Bryan

Как я могу запретить Visual Studio 2005 «Очистить» команду удалить сторонние двоичные файлы?

ответ

Смежные вопросы