CruiseControl.net, SVN, веб-сайт и зависимости - PullRequest
Новая
       3

CruiseControl.net, SVN, веб-сайт и зависимости

0 голосов
/ 03 августа 2011

У меня есть веб-сайт Asp.Net (нет файла .csproj).

Исходный код этого веб-сайта контролируется SVN.

Я исключил папку bin из источникаcontrol.

Все внешние сборки ссылаются из папки DLL, которая находится в корне моего SVN.

Я пытаюсь развернуть этот сайт с помощью cruisecontrol.net.

Проблема:

Круиз-контроль загружает все файлы из Subversion, он запускает msbuild.exe против файла .sln.Это приводит к ошибке: не удается найти внешние сборки (поскольку папка bin исключена).

Решение, которое я нашел до сих пор:

Перед выполнением задачи msbuild сделайте робокопиюDLL из моего управления исходным кодом в папку / bin.

Есть ли другое решение?(Я не хочу редактировать свою конфигурацию каждый раз, когда добавляю в свой проект внешнюю сборку.)используется для их создания 

 class Program
{
    private const string PATH_BIN = @"F:\WebSite\bin\";
    private const string PATH_REFERENCE = @"C:\DLL\";

    static void Main(string[] args)
    {
        foreach (string aFile in Directory.GetFiles(PATH_BIN))
        {
            if(!aFile.EndsWith(".dll"))
                continue;
            string pathRefreshFile = aFile + ".refresh";
            if(File.Exists(pathRefreshFile))
                continue;
            string referenceFilePath = PATH_REFERENCE+Path.GetFileName(aFile);
            if (!File.Exists(referenceFilePath))
                continue;
            using (StreamWriter sw = new StreamWriter(pathRefreshFile))
            {
                sw.Write(referenceFilePath);
            }
        }
    }
}

1 Ответ

1 голос
/ 03 августа 2011

Я предполагаю, что у вас есть файлы .dll сторонних производителей, а не созданные в проектах библиотек классов, которые можно просто включить в свое решение и добавить в качестве ссылки на проект. У нас похожий сценарий с такими элементами, как библиотека Microsoft Anti-Xss и другие распространенные сторонние DLL-файлы, на которые мы ссылаемся почти во всех наших веб-приложениях.

Вместо исключения каталога \ bin исключите * .dll. Таким образом, когда вы добавляете ссылку на .dll, Visual Studio добавит .dll в каталог \ bin И файл .dll.refresh в каталог \ bin.

Этот файл .Refresh сообщает Visual Studio, откуда взять файл .dll. Пока исходный .dll находится в этом месте, вы сможете собирать его на сервере сборки ИЛИ на совершенно новом компьютере разработчика.

Например, у нас есть каталог \ shared \ commonDlls в управлении исходным кодом, где DLL-файлы проверяются в управлении исходным кодом.

Все другие наши приложения ссылаются на них, когда это необходимо. До тех пор, пока они возвращаются, когда сервер сборки создает ваш проект, он будет знать, пойти ли ему в каталог \ shared \ commonDlls, чтобы скопировать эту библиотеку.

Это позволяет нам иметь один главный источник для файлов .dll, чтобы нам не приходилось копировать его в несколько десятков различных веб-приложений при обновлении. Мы помещаем его в наш каталог shared \ commonDlls (перезаписываем оригинал), регистрируем его, и все наши веб-приложения теперь используют последнюю версию.

edit - добавлено - ссылки на ответы по смежным темам, которые имеют отношение к этому ответу:

SVN и двоичные файлы

Как управлять ссылками в SVN / Visual Studio?

Лучшая практика: среда для совместной работы, Bin Directory, SVN

Редактировать - добавлено - раздел из нашего файла ccnet.config, указывающий на файл .sln

Это, вероятно, не нужно, но, поскольку я упомянул пометку файла .sln в своем комментарии ниже, я решил добавить его. 

<msbuild>
        <description>DonationRequests</description>
        <workingDirectory>D:\dev\svn\trunk\Intranet\DonationRequests</workingDirectory>
        <executable>C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe</executable>
        <projectFile>DonationRequests.sln</projectFile>
        <buildArgs>/p:Configuration=Debug /v:diag</buildArgs>
        <timeout>900</timeout>
        <logger>C:\Program Files\CruiseControl.NET\server\ThoughtWorks.CruiseControl.MsBuild.dll</logger>
</msbuild>
...