Используя внешний инструмент для C# создает в Visual Studio

Under 'Tools' > 'External Tools' you should be able to define an outside tool to do activities for you. The Command should be the path to the executible for your external tool.

Hope this helps some.

Вам не нужно поддерживать разные файлы проекта для сборки с помощью внешнего инструмента. MSBuild разработан для сборки с использованием тех же файлов проекта, что и Visual Studio.

Вот статья, описывающая его.

Настройте свои сборки в Visual Studio с помощью автономного инструмента MSBuild

Это для VS2005, но должно применяться к VS2008 тоже.

Я нашел вопрос в том же направлении здесь , где предлагается править реестр. Я почти уверен, что нет другого способа изменить компилятор, используемый Visual Studio, потому что нет никаких следов csc.exe ни в каком решении, конфигурации, файле csproj или чем-либо еще, ни в папке / подпапках Visual Studio 9.0 в программных файлах dir.

Местоположение реестра можно найти в:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Components\74ACAA9F1F0087E4882A06A5E18D7D32
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Components\9055DA7481CC1024CB23A6109FD8FC9B

, но эти ключи могут отличаться в зависимости от вашей установки. Заключение: изменение компилятора, используемого VS, кажется почти невозможным.

Дополнение: следующая статья MSDN рассматривает тот же вопрос для пользовательского компилятора C ++ и Эд Дора '

Вы можете построить свое решение из командной строки следующим образом:

C:\WINDOWS\Microsoft.NET\Framework\v3.5>msbuild.exe "C:\path\Your Solution.sln"

С учетом всех остальных ответов, что делает MSBuild, когда VS или MSBuild выполняет сборку, можно найти в файлах Targets, поставляемых с .Net. Их можно найти в каталоге FrameWork вашей системы. В моем случае:

C:\Windows\Microsoft.NET\Framework64\v3.5

Содержит Microsoft.Common.targets среди других. Этот файл содержит следующий фрагмент:

<!--
============================================================
                                    Build

The main build entry point.
============================================================
-->
<PropertyGroup>
    <BuildDependsOn>
        BeforeBuild;
        CoreBuild;
        AfterBuild
    </BuildDependsOn>
</PropertyGroup>
<Target
    Name="Build"
    Condition=" '$(_InvalidConfigurationWarning)' != 'true' "
    DependsOnTargets="$(BuildDependsOn)"
    Outputs="$(TargetPath)"/>

Это означает, что переопределив эту цель, вы можете заставить MSBuild VS делать все, что захотите. Вверху упомянутого файла содержится важное сообщение:

Microsoft.Common.targets

WARNING:  DO NOT MODIFY this file unless you are knowledgeable about MSBuild and have
          created a backup copy.  Incorrect changes to this file will make it
          impossible to load or build your projects from the command-line or the IDE.

This file defines the steps in the standard build process for .NET projects.  It
contains all the steps that are common among the different .NET languages, such as
Visual Basic, C#, and Visual J#.

Я предлагаю прочитать все, что можно, о MSBuild и его синтаксисе файла сборки, и попробовать заново определить цель сборки в вашем проекте (проектах). У меня сложилось впечатление, что, прочитав MSBuild, вы, вероятно, найдете более простой способ удовлетворить свои требования. Переопределение - это, по сути, определение той же цели «после» ее определения. Так, например, в ваших файлах. * Proj определите задачу Build после , которая импортирует все целевые объекты, необходимые в данном случае для построения проекта C # . Примером может быть

<Target
    Name="Build"
    Condition=" '$(_InvalidConfigurationWarning)' != 'true' "
    DependsOnTargets="BeforeBuild"
    Outputs="$(TargetPath)">
    <Exec Command="nmake" />
</Target>

Просматривая ответы, мне кажется очевидным, что интеграции scons в Visual Studio способом, совместимым с отладчиком и т. Д., Не произойдет ...

вариант, который вы могли бы рассмотреть, и я понимаю, что вы не хотите менять системы сборки, но потерпите меня, это использовать систему мета-сборки, то есть cmake. http://www.cmake.org/

Создатели на самом деле не собирают проект. Он создает файлы сборки для вас, которые вы можете использовать для сборки проекта, а в Windows файлы сборки, которые он создает для вас: файлы проекта Visual Studio. Вы можете просто загрузить их прямо в свою среду IDE, скомпилировать и использовать в обычном режиме!

CMake, как мне кажется, очень прост в использовании и обеспечивает высокий уровень прозрачности и ремонтопригодности.

Точно такие же CMakeLists. txt в linux вызывает создание make-файлов linux.

В mingw они могут генерировать make-файлы mingw.

В cmake доступно множество генераторов. Список здесь:

http://www.cmake.org/cmake/help/cmake-2-8-docs.html#section_Generators

http://springrts.com - это огромный открытый исходный код. rts, которая раньше использовала scons в качестве кроссплатформенной системы сборки, а теперь использует cmake.

Я понимаю, что вы действительно не хотите менять системы сборки, поэтому это среднесрочное и долгосрочное решение.

] Cmake в любом случае - это еще один вариант, добавленный к использованию специального инструмента сборки, или использования msbuild, или запуска сборки scons из командной строки вручную.

Отредактируйте файл проекта и обновите ключи CscToolPath, чтобы они указывали на каталог, содержащий ваш инструмент, и добавьте ключи CscToolExe, содержащие имя каталога:

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|.NET 3.5' ">
   .
   .
   .
   <CscToolPath>path\to\custom\tool\directory</CscToolPath>
   <CscToolExe>exe name</CscToolExe>
   .
   .
   .
</PropertyGroup>

Я не тестировал это, и Клавиша CscToolExe может вызвать проблемы, и в этом случае я просто переименую исполняемый файл внешнего инструмента в «csc.exe».