Недавно я попал на новый проект, с задачей создать небольшое приложение с нуля. Разговариваю с тестером:
— А как тебе новые версии поставлять?
— Можешь как все остальные на проекте, через SVN.
— То-есть ты сама билдить будешь?
— Да нет… Бинарники оттуда беру.

Оказывается, очень много программистов, даже имеющих в подписях слова вроде Senior или Superior никогда в жизни не стыкались с понятием CI, или слабо себе представляют что это такое. Не найдя отдельных публикаций на Хабре на эту тему, решил восполнить пробел, а заодно и по возможности заработать желанный инвайт.

Добрый день!

Я попробовал описать здесь свой опыт автоматизации сборки приложений .NET (в основном, речь идет о web-приложениях).

Т.к. получилось много букв пришлось разбить статью две на части. Сейчас выкладываю первую часть, если это будет нужно кому-то, выложу остальное. Не пинайте сильно.

UPD: Метод, аналогичный использованному здесь включен в поставку NuGet 1.6. Соответственно статья устарела.

Вот что мне всегда нравилось в джаве, так это Maven. Один файл со списком всего нужного, и никаких бинарников в репозитории. Когда появился NuPack, я решил — ура, вот оно, счастье пришло на нашу улицу. Но не тут то было. NuPack представлял удобный интерфейс для работы с пакетами… но без возможности нормально вкрутится в процесс сборки.

Поковырял я его тогда, посмотрел, но так реальной пользы и не увидел. Не больно большая помощь — качать ручными powershell-командами пакеты поименно. Ну да, удобнее, чем скачивать фиг знает откуда, да еще руками references добавлять, но ведь мне это далеко не каждый день нужно. В общем, игра не стоит свеч.

Но в один прекрасный день я понял, что с папкой Shared\Bin в моем сорц-контроле нужно что-то делать, ибо распухла она уже неимоверно. Решил глянуть я, не изменилось ли что-нибудь с NuPack-ом, который уже NuGet-ом стал именоваться? Нет, воз и дальше там.

Но у nuget.exe появилась интересная фича…

Наверное, каждому программисту, знакомому с системой построения проектов MsBuild, приходила в голову идея не заниматься расширением существующего процесса построения, а придумать его «с нуля». Иными словами, добавить в существующим типам проектов .csproj (проект на C#) и .vbproj (проект на VB.NET) еще один тип (например, .myproj или просто .proj). А кто-то, может быть, даже пытался эту идею реализовать.

По этой теме, казалось бы, полно информации, есть даже пошаговое руководство на MSDN. Но, после создания файла проекта по любому подобному руководству, становится понятно, что нас жестоко обманули — созданные таким образом проекты живут «сами по себе» и не могут быть ни включены в решение, ни открыты в Visual Studio.

В этой статье я представляю вам собственное исследование на эту тему.

В силу всё большего и большего усложнения веб-приложений на стороне клиента, хочется иметь шаблонизаторы, которые работали бы прямо на клиенте. И таких средств, надо сказать, появилось не мало. Но так как я легких путей не ищу все они мне не нравятся, я решил сделать свой с блэкджеком и дамами лёгкого поведения (я так понял, на Хабре жестко карают и банят, если этой фразы нет в посте).

И вот я решил создать строготипизированный шаблонизатор на Razor.

Введение

Сегодня (Monday, April 26th, 2010 at 8:54 am? Прим. перев.) в очередной раз я твитнул о том, что не являюсь фанатом систем сборки проектов, основанных на XML. Да, я понимаю для чего они нужны. Да, они были хороши в свое время. И да, я до сих пор использую их каждый день. Но несмотря на все это я считаю, что есть более удобные способы решить эту задачу. Наиболее частым ответом на мой твит были слова: «Ну а альтернатива-то какая?» Одна из важнейших вещей, которым научила меня жизнь, это то, что не стоит жаловаться на что-либо до тех пор пока тебе нечего предложить взамен. Так что я здесь и сейчас предложу альтернативное решение…

Суть вопроса

В большинстве случаев .NET-приложения являются платформонезависимыми. Мы ожидаем, что наше приложение будет одинаково выполняться как в 32-хразрядной ОС, так и 64-хразрядной.

Так обычно и происходит до тех пор, пока нам не понадобится использовать внешние платформозависимые библиотеки, например неуправляемые. Если такая библиотека существует в вариантах и для x86, и для x64, то это может принести нам определенную головную боль. Будем исходить из того, что ограничивать наше приложение, например, только 32-хразрядным процессом не в наших правилах.

Возможно, нам придется поддерживать вдвое больше конфигураций проекта. В этом случае при отладке придется переключать конфигурации, ведь разработческий веб-сервер Cassini существует только в x86 варианте, а ReSharper может запускать тесты и в 64-хразрядном процессе. Кроме того, придется выпускать два дистрибутива и предоставлять пользователю при скачивании с сайта ох какой нелегкий выбор. Поэтому разумным решением выглядит выбор подходящей для работы библиотеки уже в runtime в зависимости от того, в каком процессе (32-х или 64-хразрядном) код выполняется. При этом сами проекты остаются AnyCPU.

В нашем приложении необходимо подключаться к к Oracle Database, для чего используются библиотеки Oracle Instant Client и Oracle Data Provider for .NET.

Вы все еще публикуете проект вручную? Тогда мы идем к вам

Под катом гайдлайн по внедрению CI для .NET проектов «с нуля», включающий:

1. Автоматические ежедневные сборки
2. Уведомления о проблемах
3. Интеграцию с баг-трекером и системой контроля версий
4. Версионирование продукта
5. Версионирование базы данных
6. Автоматизированные выкладки и бекапы

Привет всем читателям Хабра!

Не так давно я начал использовать для сборки сервером непрерывной интеграции некоторых проектов NAnt наряду с уже освоенным MSBuild. Как всегда, в процессе работы обнаруживаются бонусы с разными знаками (как плюс, так и минус). Тех, кому интересны детали сборки разными движками (MSBuild, NAnt) в контексте сервера CI, с удовольствием приглашаю под кат.

Эта статья в первую очередь пригодится тем, кто использует тот же стек технологий, что и наша команда, а именно: ASP.NET, C#, NUnit, Selenium 2, git, MSBuild. Будут рассмотрены такие задачи, как интеграция с git, сборка C#-проектов, NUnit-тесты (как модульные, так и тесты UI), а также деплой на сервер. Впрочем, наверняка найдётся интересное и для других пользователей, кроме разве что съевших на этом вопросе собаку. Но они опять же смогут обратить внимание на ошибки в статье или что-то посоветовать: например, как оптимизировать фазу деплоя.

Привет, хабр.

Я разрабатываю плагин под Java приложения для запуска кода на .Net. Проект открытый, выложен на GitHub. И в какое-то время я решил, что хорошо бы найти Continious Build & Test такой, чтобы я смог в нем собирать продукт.

После небольших поисков мне попалось на глаза довольно интересное и простое решение.

Disclaimer: я не имею никакого отношения к разработке этого продукта, не знаю автора и т.д. Мне просто понравился этот сервис, и я решил написать пост.

Привет Хабр, в этих статьях я попытаюсь осветить тему расширений Microsoft Visual Studio(а попутно ещё и MSBuild), т.к. эта сфера является крайне плохо документированной и вообще покрыта пеленой какой-то загадочности.

Сегодня мы особенно рады сообщить что MSBuild (наверное, самая часто используемая и самая таинственная по документированности — прим. перев.) — теперь доступен на github и мы вносим его в список .NET Foundation! The Microsoft Build Engine (MSBuild) — это платформа для построения приложений. Вызывая msbuild на вашем проекте или решении, вы можете организовывать и строить свои продукты в окружениях, где нет установленной MS Visual Studio. Например, MSBuild используется чтобы строить такие Open Source проекты, как .NET Core Libraries и .NET Core Runtime.

Сегодня мы особенно рады сообщить что MSBuild (наверное, самая часто используемая и самая таинственная по документированности — прим. перев.) — теперь доступен на github и мы вносим его в список .NET Foundation! The Microsoft Build Engine (MSBuild) — это платформа для построения приложений. Вызывая msbuild на вашем проекте или решении, вы можете организовывать и собирать свои продукты в окружениях, где нет установленной MS Visual Studio. Например, MSBuild используется чтобы собирать такие Open Source проекты, как .NET Core Libraries и .NET Core Runtime.



Ядро, библиотеки, миграция на Mac/Linux, msbuild… Еще немного и я поверю в выход на github MS Visual Studio.

Эта небольшая статья поможет:

• Ознакомиться с событийной моделью построения проектов и решений MS Visual Studio;
• Понять, как получить поддержку Command-Line режима devenv.exe для VSPackage (где он изначально не предусмотрен);
• Понять, как эмулировать схожую модель событий от MSBuild Tools и транслировать на главный плагин;
• Узнать, как работать по приоритетной подписке;
• Узнать варианты получения контекста построения при обработке событий Visual Studio / MSBuild Tools;
• Узнать об оценке MSBuild Property & MSBuild Property Functions;
• Получить общие сведения межмодульного взаимодействия на слое абстракции для разнородных компонентов системы.

Синопсис

Мне довольно часто приходиться заниматься автоматизацией тех или иных процессов, поэтому не мудрено, что часть решений рано или поздно коснулись и Visual Studio.

На самом деле, эта статья, или даже заметка — результат рабочего и уже давно написанного плагина, который еще года 2 назад являлся лишь побочным продуктом при работе над одним проектом на C++. Однако мой дебют на Хабрахабре будет, пожалуй, с этого.

Добрый день! Одним прекрасным днем мы обнаружили, что наш MSBuild деплой проект не хочет работать в новой среде: для создания и управления сайтами и пулами он использовал MSBuild.ExtensionPack. Падали ошибки, связанные с недоступностью DCOM. Среду менять было нельзя, поэтому кстати пришлась возможность написания собственных задач для MSBuild: msdn.microsoft.com/en-us/library/t9883dzc.aspx, было принято решения написать свои, которые работали бы через WMI (доступный на среде) Кому интересно, что получилось, прошу под кат.

Всё чаще возникают задачи автоматизации разных процессов в рамках CI. Поковырявшись с MSBuild, я всё больше убеждаюсь, что это довольно мощный инструмент. При желании, им много чего можно сделать. Однако ни в рунете вцелом, ни конкретно на хабре я не нашёл статей по нему и решил позаполнять этот пробел по мере сил и наличия свободного времени.
Итак, сегодня мы будем готовить

StyleCop

Задача: реализовать тотальную принудительную проверку кода (C#) на соответствие правилам оформления.

Условие: тотально, принудительно. Т.е. весь код, попадающий на сборку, должен быть проверен в обязательном порядке. В случае обнаружения нарушений — build error и вперёд, рефакторить.

Инструменты: StyleCop, MSBuild (TFS или TeamCity — неважно).

Недавно прошла конференция //BUILD, на которой Майкрософт традиционно представляет новые технологии для разработчиков. В ключевом докладе первого дня была высказана одна очень важная мысль – по мере того, как общение с компьютерами становится всё более естественным, возрастает роль диалогового общения на естественном языке. Речь здесь не только о том, что мы сможем просить голосовой помощник Cortana просить поставить нам будильник, но и что множество других задач (заказать пиццу, забронировать гостиницу, купить билеты и т.д.) может быть решено с помощью диалога. Более того, это может быть не только диалог между пользователем и компьютером: в более сложном случае человек может попросить Cortana спланировать путешествие, и затем Cortana будет сама общаться с другими ботами, совершая заказ гостиницы и билетов.



Здесь интересно то, что само “общение” может происходить а различных местах: на десктопе с помощью клиента Cortana, но также и в других традиционно используемых для чата каналах: в Skype, Telegram, Slack и т.д. Личность и память нашего персонального ассистента не зависит от канала общения, а располагается где-то в облаке, готовая пообщаться с нами на любом из так называемых “conversational canvases”.

Для создания ботов была представлена предварительная версия Microsoft Bot Framework и соответствующие API, о которых мы поговорим ниже. Мы также покажем, как можно создать своего простейшего бота, поддерживающего беседу с пользователем на английском языке.

Не так давно прошла наша самая крупная конференция для разработчиков: //BUILD, на которой было сделано много важных анонсов (про Xamarin, про облако, про Bot Framework). Однако помимо анонсов интересно почитать и про то, как проходила сама конференция, какая на ней была атмосфера, что интересного было доступно участникам. Чтобы вы могли немного окунуться в атмосферу конференции, мы попросили наших студентов-партнёров, которые были на ней, поделиться своими впечатлениями. Статья ниже подготовлена Евгением Григоренко и Ильей Рябухиным.

В этом году нам, трем студенческим партнерам Майкрософт, посчастливилось побывать на конференции //BUILD/ 2016. И в данной статье, говоря о //BUILD/, мы бы хотели осветить не столько анонсы и обновления существующих технологий, сколько рассказать о таких сторонних вещах, как процесс регистрации, организационные вопросы, технологическая выставка и совпавший с самой конференцией американский финал Imagine Cup.

Здравствуйте, дорогие читатели!

В этом году на конференции Microsoft //Build представлено не только много технологических анонсов и нововведений, но и не мало интересных возможностей на самом мероприятии.


HoloLens и Holographic Academy, Xbox One Developer Mode и подробности интересных технологических проектов с финала Imagine Cup США — об этом я хочу рассказать вам в данной статье.