Ресурсы для настройки среды разработки Visual Studio / C ++ - PullRequest
1 голос
/ 11 июня 2010

Я почти не занимался разработкой фронт-энда около 15 лет с тех пор, как перешел на разработку баз данных. Я планирую начать работу над личным проектом с использованием C ++, и, поскольку у меня уже есть MSDN, я, вероятно, в конечном итоге сделаю это в Visual Studio 2010. В конце концов я подумываю об использовании Subversion в качестве системы контроля версий. Конечно, я хотел бы начать работу так быстро, как только смогу, но я также хотел бы избежать каких-либо ошибок из-за плохо организованной среды проекта.

Итак, мой вопрос: есть ли хорошие ресурсы с общими рекомендациями по настройке среды разработки? Я думаю о том, где разбить решение на несколько проектов, если необходимо, как настроить процесс модульного тестирования, организовать ресурсы, каталоги и т. Д.

Есть ли какие-нибудь замечательные дополнения, которые я должен убедиться, что я настроил их с самого начала?

У большинства руководств просто есть один простой проект, введите свой код и нажмите на сборку, чтобы увидеть, что ваше новое приложение говорит: "Hello World!".

Это будет также приложение для Windows с несколькими библиотеками DLL (без веб-разработки), поэтому не требуется процесс развертывания на веб-сервере.

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

Спасибо!

1 Ответ

0 голосов
/ 11 июня 2010

Мне также хотелось бы получить хороший ответ на этот вопрос. Я настроил его так, чтобы каждое решение ссылалось на каталог $ (SolutionDir) \ build для включений и библиотек. Таким образом, каждый проект, имеющий зависимости от других проектов, может получить к ним доступ, и версии не будут конкурировать. Затем есть команды после сборки для упаковки заголовков и файлов .lib в папку «дистрибутива». Я использую CC.net для сборки каждого пакета при регистрации. Когда мы решаем обновить проект зависимостей, мы «выпускаем» его для себя, что требует ручной пометки, ручного копирования current.zip в область релизов и присвоения ему номера версии, а также копирования его в / build проектов, которые зависят от обновление.

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

Если я использую «переходы» в файловой системе Windows, я могу связать «распространить» с «сборкой», а затем создать вторичное решение, которое включает все проекты, которые зависят от друг друга для создания продукта. Когда я сделал это, он поощрял разработчиков использовать его для активной разработки, что препятствовало TDD и правильному выпуску.

...