Pull to refresh

Comments 13

Я использую appveyor так как он бесплатен для open source проектов.

Слабое утверждение. Travis CI тоже бесплатен, но собирается в линуксе, соответственно там Mono. А вот appveyor под Windows заточен.


В принципе советы актуальны для любых проектов, не только .NET. За исключением может быть второго, да и то пакеты есть не только под .NET (npm).

По первому пункту согласен с вами. Travis CI как-то прошел мимо меня. Статью написал применительно к .net, т.к. количество и качество open source проектов на этой платформе сильно уступает тому же js. Хочу что бы в будущем эта ситуация поменялась.
В этом и прелесть appveyor, что он собирает под Windows т.к. как это позволяет строить сборки PCL и конкретно сборки для Universal Windows Apps используя образ Visual Studio. К тому же, процесс сборки можно настроить до мельчайших деталей.

Хотя лично я еще не разобрался, как настроить автоматическую публикацию NuGet пакетов в appveyor. В документации очень неясно описан этот процесс.

Ну, а так использую Travis для JS проектов, а AppVeyor для .Net проектов.

Вот appveyor.yml с настроенной публикацией в NuGet. Если будут еще вопросы приглашаю в ЛС для обсуждения.

Почти для каждой среды есть свой пакетный менеджер. Так что втором пункте нужно только название менять.
Мне кажется эти советы актуальны для любых проектов. Только вместо NuGet можно сказать чтобы люди делали инсталлятор.
Только вместо NuGet можно сказать чтобы люди делали инсталлятор.
… или выкладывали пакет на pypi/rubygems/npm/etc.
Для меня еще важен такой аспект, как документация самого кода т.е. методов, свойств и т.д.
Иногда подключаешь стороннею библиотеку, вызываешь метод, который принимает три параметра типа object, и начинается «шоу интуиция». Или когда метод имеет несколько перегрузок. Это не менее важно, чем общая документация по проекту.
Примеры работы с вашим проектом. Подойдут unit-тесты с подробными комментариями.

Я предлагаю описывать это в примерах работы с проектом
> Публикуя любой проект в open source — вы автоматически берете на себя ответственность за его поддержку. 
А если я его публикую как раз для того, что бы кто-то другой занялся его поддержкой? Что бы результат труда не пропал даром, когда бросаешь проект
Тогда надо прямо указать — нужен человек, который этим займется.
Спасибо за статью! У меня такой вопрос: а есть ли рекомендуемая или общепризнанная структура проектов на .NET? Структура каталогов, расположение тестов и т.д.?

Я использую расположение папок, которое предлагает Visual Studio: каждый проект и его proj файл в собственной папке, а sln файл лежит в корне.

Sign up to leave a comment.

Articles