Быстрый вопрос о TFS - Ребята, вы регистрируете папки bin / debug в TFS? (если так, почему?) Поскольку содержимое этих папок генерируется динамически, лучше не указывать их, чтобы у программиста не возникало проблем, связанных только с чтением?
Ответы:
Как правило, управление исходным кодом лучше всего использовать только для источника, а сгенерированные файлы не являются источником.
Есть исключения. Иногда (используя Visual Studio) вы можете захотеть сохранить файл .pdb для чтения мини-дампов. Иногда вы не можете продублировать цепочку инструментов, чтобы вы не могли точно воссоздать сгенерированные файлы. В этих случаях вы в первую очередь заинтересованы делать это для выпущенного программного обеспечения, а не для каждого изменения VCS, и в любом случае они могут легко находиться в версионных папках. (Во всяком случае, это, как правило, двоичные файлы, и они не имеют понятных изменений от одной версии к другой, и не очень-то выигрывают от того, что находятся в VCS.)
Простой ответ? Нет, не делай этого! Я не могу придумать много причин, чтобы этого не делать, но нет причин, по которым вы бы этого хотели.
Единственный раз, когда я могу подумать, что вы проверяете dll, это если вы работаете со сторонней библиотекой, которую, по вашему мнению, не должен устанавливать каждый разработчик. Но даже в этом случае, это не находится в папке мусорного ведра.
Тем не менее, я работал в одной компании, которая требовала, чтобы каждый пакет развертывания был помещен в систему контроля версий, но это было так, что мы могли отслеживать различные сборки, которые мы давали нашему клиенту, и могли легко откатываться, если бы это было необходимо.
Мы не проверяем в папке bin в TFS. Как вы, наверное, заметили, если вы сделаете это, каждый раз, когда любой разработчик создает решение, он будет проверять папку bin. Нехорошо. Однако существуют библиотеки, которые необходимы проекту для компиляции и запуска, и наше правило состоит в том, что любой проект должен открываться из системы контроля версий, а также должен компилироваться и запускаться. Поэтому мы создаем папку «BinRef» для любых библиотек DLL, на которые должен ссылаться проект, и создаем ссылки проекта на копию в папке BinRef. Папка BinRef это проверяется на TFS.
Другое преимущество этого подхода заключается в том, что BinRef всегда находится на корневом уровне веб-проекта. Если мой проект живет, C:\Projects\Marcie\SomeProjectCategory\ProjectAи я создаю ссылку на библиотеку DLL, которая находится внутри C:\DLLsThatILike, ссылка в конечном итоге будет выглядеть примерно так:
\..\..\..\NiceThing.dll
, Вы можете хранить файлы своего проекта, C:\ProjectAчто означает, что ссылка на проект NiceThing будет взорвана на вашем компьютере. Надеюсь, люди не делают ссылки таким образом, но я видел, как это произошло.
Мы регистрируем содержимое каталогов bin как часть нашего процесса запроса на изменение. Чтобы избежать проблем только для чтения, мы копируем содержимое в отдельную папку и регистрируем их оттуда. Наша корпоративная политика требует, чтобы все двоичные файлы, отправляемые в производство, регистрировались отдельно от исходного кода. Это не лучшее решение, но оно работает, и оно дает нам точные файлы, которые находятся в производстве.
Я не решаюсь проверить любой нетекстовый файл в системе контроля версий. Особенно те, которые должны быть сгенерированы разработчиком. Мне также нравится сохранять другие двоичные файлы, такие как изображения и PDF-файлы, в архиве и храниться в другом месте для каждого тега / выпуска.
Нет, но наш внутренний инструмент управления проектами делает это автоматически, что раздражает меня.
Мое решение состоит в том, чтобы пометить все файлы в выпуске и отладке как доступные для записи, и когда TFS жалуется, я говорю об этом, чтобы игнорировать файлы, чтобы у меня никогда не возникало проблем при сбое сборки.
Я сохраняю некоторые сгенерированные двоичные файлы, такие как .NET-взаимодействия из другого проекта. Поэтому, если у меня есть проект A, который создает COM-объект, а затем вы используете этот COM-объект в очень слабо связанном проекте B, который использует его через взаимодействие .NET, я отмечаю это взаимодействие, сгенерированное из проекта A, в проект B. не очень хорошая идея, но она должна куда-то идти, потому что AFAIK Visual Studio не будет автоматически создавать взаимодействие для вас во время сборки.
На мой взгляд, не хранение двоичных файлов в системе контроля версий является одной из самых распространенных ошибок. Они должны храниться, иметь версии, исходные данные / маркироваться вместе с источниками, а также средствами сборки. Соберите себя, создав не отслеживаемое программное обеспечение ...