Comments 13
Я использую appveyor так как он бесплатен для open source проектов.
Слабое утверждение. Travis CI тоже бесплатен, но собирается в линуксе, соответственно там Mono. А вот appveyor под Windows заточен.
В принципе советы актуальны для любых проектов, не только .NET. За исключением может быть второго, да и то пакеты есть не только под .NET (npm).
0
По первому пункту согласен с вами. Travis CI как-то прошел мимо меня. Статью написал применительно к .net, т.к. количество и качество open source проектов на этой платформе сильно уступает тому же js. Хочу что бы в будущем эта ситуация поменялась.
0
В этом и прелесть appveyor, что он собирает под Windows т.к. как это позволяет строить сборки PCL и конкретно сборки для Universal Windows Apps используя образ Visual Studio. К тому же, процесс сборки можно настроить до мельчайших деталей.
Хотя лично я еще не разобрался, как настроить автоматическую публикацию NuGet пакетов в appveyor. В документации очень неясно описан этот процесс.
Ну, а так использую Travis для JS проектов, а AppVeyor для .Net проектов.
Хотя лично я еще не разобрался, как настроить автоматическую публикацию NuGet пакетов в appveyor. В документации очень неясно описан этот процесс.
Ну, а так использую Travis для JS проектов, а AppVeyor для .Net проектов.
+2
Почти для каждой среды есть свой пакетный менеджер. Так что втором пункте нужно только название менять.
0
Мне кажется эти советы актуальны для любых проектов. Только вместо NuGet можно сказать чтобы люди делали инсталлятор.
+9
Для меня еще важен такой аспект, как документация самого кода т.е. методов, свойств и т.д.
Иногда подключаешь стороннею библиотеку, вызываешь метод, который принимает три параметра типа object, и начинается «шоу интуиция». Или когда метод имеет несколько перегрузок. Это не менее важно, чем общая документация по проекту.
Иногда подключаешь стороннею библиотеку, вызываешь метод, который принимает три параметра типа object, и начинается «шоу интуиция». Или когда метод имеет несколько перегрузок. Это не менее важно, чем общая документация по проекту.
0
> Публикуя любой проект в open source — вы автоматически берете на себя ответственность за его поддержку.
А если я его публикую как раз для того, что бы кто-то другой занялся его поддержкой? Что бы результат труда не пропал даром, когда бросаешь проект
А если я его публикую как раз для того, что бы кто-то другой занялся его поддержкой? Что бы результат труда не пропал даром, когда бросаешь проект
+2
Тогда надо прямо указать — нужен человек, который этим займется.
0
Спасибо за статью! У меня такой вопрос: а есть ли рекомендуемая или общепризнанная структура проектов на .NET? Структура каталогов, расположение тестов и т.д.?
0
Sign up to leave a comment.
Пять советов тому кто публикует свой .Net проект на GitHub