Develop Reference

Azure DevOps XML Transformation During Release Not Working

I want to configure our pipeline to allow one build to be used for multiple environments without having to create separate builds. According to the docs, it seems like it is possible, as it says:
You can use this technique to create a default package and deploy it to multiple stages.
I named my stage as my environment (preview), and I created a web.config file for that environment (web.preview.config) file. All my environment configuration files in the same path as Web.Config file.
The logs say transformation was complete:
2018-11-17T00:26:52.0383966Z [command]D:\a_tasks\AzureRmWebAppDeployment_497d490f-eea7-4f2b-ab94-48d9c1acdcb1\3.4.13\ctt\ctt.exe s:D:\a_temp\temp_web_package_06958915987488234\Content\D_C\a\1\s\Microsoft.Xbox.Mvp\Microsoft.Xbox.Mvp.Api\obj\Preview\Package\PackageTmp\bin\Web.config t:D:\a_temp\temp_web_package_06958915987488234\Content\D_C\a\1\s\Microsoft.Xbox.Mvp\Microsoft.Xbox.Mvp.Api\obj\Preview\Package\PackageTmp\bin\Web.Release.config d:D:\a_temp\temp_web_package_06958915987488234\Content\D_C\a\1\s\Microsoft.Xbox.Mvp\Microsoft.Xbox.Mvp.Api\obj\Preview\Package\PackageTmp\bin\Web.config pw i
2018-11-17T00:26:52.4335280Z [command]D:\a_tasks\AzureRmWebAppDeployment_497d490f-eea7-4f2b-ab94-48d9c1acdcb1\3.4.13\ctt\ctt.exe s:D:\a_temp\temp_web_package_06958915987488234\Content\D_C\a\1\s\Microsoft.Xbox.Mvp\Microsoft.Xbox.Mvp.Api\obj\Preview\Package\PackageTmp\bin\Web.config t:D:\a_temp\temp_web_package_06958915987488234\Content\D_C\a\1\s\Microsoft.Xbox.Mvp\Microsoft.Xbox.Mvp.Api\obj\Preview\Package\PackageTmp\bin\Web.Preview.config d:D:\a_temp\temp_web_package_06958915987488234\Content\D_C\a\1\s\Microsoft.Xbox.Mvp\Microsoft.Xbox.Mvp.Api\obj\Preview\Package\PackageTmp\bin\Web.config pw i
2018-11-17T00:26:52.5443873Z XML Transformations applied successfully
I can see that it first transformed to release and then it applied preview as the doc says (release then environment). However, although it says XML Transformations applied successfully, when I check the config variables, they are not changed. The only way I could make the transformation work was to define the buildConfiguration variable when I queue a new build, which blocks me from using the same build for different environments.
When I was researching, I found this from this link:
Web.config is transformed during the build process, if you generate the deployment package from "Build" and then deploy it in "Release", then you cannot transform it before deployment.
But the doc said I can use one default package for multiple stages...Does that still mean I have to create separate build for each environment? Is XML transformation not what I should be looking at for the scenario I wanna solve?
Thank you in advance!
++ Edit:
Release Settings:
Release steps (I think? I have a strong feeling that this is what you are looking for...):

1) Make sure you transform works. Test it
here.
2) Ensure in your VS project that you are including the transform file, Web.Preview.config, and copying to output dir.
3) Disable the config transform during the build, you just need to add argument /p:TransformWebConfigEnabled=False in MSBuild Arguments section of your Build task. You also need to add /p:AutoParameterizationWebConfigConnectionStrings=False if you want to update the connection string during the release. This will use the Web.Preview.config to "transform" the web.config.
4) Double check that in your release for the IIS Web App Deploy task under File Transforms & Variable Substitution Options you have XML transformation checked.

None of the answers I found on the internet worked for me on their own for my build and release pipeline. The web.config I got from the release pipeline was always pointing to the non transformed values.
After a few hours pulling my hair I got it to work though.
Some short info about my setup
I want to be able to deploy on all environments with just one build and one release pipeline.
My setup:
One build pipeline that builds all of our standard branches (test,
release, master).
One release pipeline that has different stages
depending on branch that started the release.
Our test stage releases the test branch on our test server.
Stage/Production comes from the same release branch but have their own transform files.
Solution
I followed some of the guide from Microsoft and set up my web.<environment_name>.config to match the release stage names.
I did not need to remove the <Dependent Upon> rows from my .csproj for each transform. Instead all I did was set the property Build Action of each transform to Content as shown by the image bellow.
I then added these commands to the build pipeline's Build Solution -> MSBuild Arguments:
/p:MarkWebConfigAssistFilesAsExclude=false
/p:TransformWebConfigEnabled=false
/p:AutoParameterizationWebConfigConnectionStrings=False
The build now does not try to transform the .config on it's own and also does not exclude the transform files from the artifact, allowing the release pipeline to do the transformation instead. Also, keeping the <Dependent On> for the transform files lets us have a "cleaner" look inside our code editors.

I just got this working so I could have one build with deployment to multiple environments. This is what I did.
In the code, I set each Web.<Environment>.config property to Build Action = "Content". I also set all mine to Copy to Output Directory = "Copy Always". I also unloaded the project and edit the csproj file, then removed the <DependendUpon>Web.config</DependentUpon> lines. This dumps all your web.configs to the root (no file nesting).
In the build, I set pipeline variable BuildConfiguration = "Release". I don't have a Web.Release.config in my project.
In the release, I named the deployment stage after the environment (in my case, Development, Staging, and Production). In all stages, on the Azure deployment task, I checked the XML transform checkbox.
In Azure, I set the ASPNETCORE_ENVIRONMENT to the naming of the staging environment, in my case, Development, Staging, and Production).

I just got this working as well. My issue was actually at the Visual Studio Solution level. I had the MVC project pointed to a different Configuration than the others. So always double check the configs!

Visual Studio Long wait before Starting to build

We have a moderately sized solution, with about 20 projects. In one of them I have my business entities. On compiling any project, visual studio waits and hangs about one and a half minutes on this BusinessEntities project.
I tried our solution in SharpDevelop and it compiles our complete solution, in 18 seconds. Similar timing with MSBuild.
My guess is that VS is trying to find out if the project needs a compile, but this process is about 15 times slower than actually performing the compile!!
I can't switch to the great sharpdevelop, it lacks some small, but essential requirements for our debugging scenarios.
Can I prevent VS from checking this project, And have it compile the projects without such a check, just like sharpdevelop?
I already know about unchecking projects in configuration management to prevent building some projects, but my developers will forget they need to compile this project after updating to latest sources and they face problems that seem strange to them.
Edit: Interesting results of an investigation: The delay happens to one of the projects only. In configuration manager I unchecked all projects, then compiled each of them individually. All projects compile in a few seconds!! The point is this: if that special project is built directly, compiles in a few seconds, if it is being built (or skipped, because it is up-to-date) as a result of building another project that depends on it, VS hangs for about a minute and half, and then decides to compile it (or skip it). My conclusion: Visual studio is checking to know if any files are changed, but for some reasons, for this special project it is extremely inefficient!!

I'd go to Tools -> Options -> Projects and Solutions -> Build and Run and then change the "MSBuild project build [output|build log] verbosity" to Diagnostic. At that level it will include timings which should help you track down the issue.

We had the same problem with an ASP.NET MVC web project running in Visual Studio 2013. We build the project and nothing happens for about a minute or so and then the output window shows that we are compiling.
Here's what fixed it... open the .csproj file in a text editor and set MvcBuildViews to false:
<MvcBuildViews>false</MvcBuildViews>
I had to use sysinternals process monitor to figure this out but it's clearly the cause for my situation. The site compiles in less than 5 seconds now and previously took over a minute. During that minute the Asp.net compilation process was putting files and directories into the Temporary Asp.net Files folder.
Warning: If you set this, you'll no longer precompile your views so you will lose the ability to see syntax errors in your views at build time.

There is the possibility that you are suffering from VS inspecting other freshly built assemblies for the benefit of the currently compiling project.
When an assembly is built, VS will inspect the references of the target assembly, which if they are feshly built or new versions, may include actually loading them in a .Net domain, which bears all the burdens of loading an assembly as though you were going to run it. The build can get progressively slower as it rebuilds more and more projects. When one assembly becomes newer the others do a lot more work. This is one possible explanation for why building by itself, versus already built, versus building clean, all have seemingly relevantly differing results. Its really tht the others changed and not about the one being compiled.
VS will 'mark down' the last 'internal' build number of the referenced assembly and look to see if the referenced assembly actually changed as it rolls through its build process. If its not differnt, a ton of work gets skipped. And yes, there are internal assembly build numbers that you dont control. This is probalby not in any way due to the actual c# compiler or its work or anything post-compile, but pre-compile steps necessary for the most general cases.
There are several reference oriented settings you can play with, and depending on your dev, test, or deployments needs, the functional differences may be irrelevant, however may profoundly impact how VS behaves and how long it takes during build.
Go to the references of one of the projects in Solution Explorer:
1) click on a reference
2) open the properties pane if its not (not the Property Pages or the Property Manager)
3) look at 'Copy Local', 'Embed Interop Types', 'Reference Output Assembly'; those may be very applicable and probably something good to know about regardless. I strongly suggest looking up what they do on MSDN. 'Reference Output Assembly' may or may not show in the list.
4) unload the project, and edit the .proj file in VS as text. look for the assembly reference in the XML and look for 'Private'. This means whether the assembly referenced is to be treated as though its going to be a private assembly from the referencing assemblies perspective, vs a shared one. Which is sort of a wordy way of saying, will that assembly be deployed as a unit with the other assemblies together. This is very important toward unburdening things. Background: http://msdn.microsoft.com/en-us/magazine/cc164080.aspx
So the basic idea here is that you want to configure all of these to be the least expensive, both during build and after deployment. If you are building them together, then for example you probably really don't need 'Copy Local'. Id hate to say more about how you should configure them without knowing more about your needs, but its a very fine thing to go read a few good paragraphs about each. This gets very tricky however, because you also influence whether VS will use the the stale old one when resolving before the referenced one is rebuilt. As a further example explaiing that its good to go read about these, Copy Local can use the local copy, even though its stale, so having this set can be double bad. Just remember the goal at the moment is to lower the burden of VS loading newly built assemblies jsut to compile the others.
Lastly, for now, I can easily say that hanging for only 1.5 mins is getting off very lucky. There are people with much much worse build times due to things like this ;)

Some troubleshooting idea's that have not been mentioned:
Clean solution?
Delete Obj and Bin folders plus the .suo file? FYI, neither Clean nor Rebuild will delete non-build files, eg files copied during a pre-build command.
Turn off VS scanning outside files. Options > tools > environment > document > detect when file is changed outside the environment?
Rollback SVN history to confirm when it started to occur? What changed? If the project file on day 1 takes the same time, recreate the project, add all the files and build.
Otherwise could you please run Process Monitor and let us know what Visual Studio is doing in the prep-build stage?

Sounds silly, but remove all breakpoints first. It sped up my pre-build checks massively - still don't know why though.

Based on the (limited) information provided one possibility is that there could be a pre-build action specified in the project file that is slow to compile.

Try disabling platform verification task as described here.

If your individual projects are compiling correctly then all you can do is change order of compilation by setting dependent projects explicitly in configuration.
Try to visualize your project dependency hierarchy and set dependent projects. For example, if your business entities project is referenced in each project, then in configuration of each project, this project must be selected as dependent.
When an explicit build order is not set, visual studio is analyzing projects to create an order of building project. Setting explicit dependent projects wiki make visual studio skip this step and use the order provided by you.

With such an extreme delay on a single project and no other avenue seeming to provide a reason I would attempt to build that specific project while running procmon from sysinternals and filter out all the success messages. You could probably also narrow it down to just the file system actions as well. From your description I might guess that the files are being locked by an external source like the event collection or workflow management process services.
Other things to consider would be whether or not this is a totally clean build machine or if it has been used to perhaps test the builds as well? If so, is there a chance that someone mapped an IIS application path to the project directly or registered it as a service location?
If you run procmon and see no obvious locks or conflicts I would create a totally new solution and project and copy the files over to see if that project also has the same delay. If it does have the same delay I would create a sample project of the same type but generic data (essentially empty) and see if that too is slow. If the new project with the same files builds fine you can then diff the directories to see what the variance is that causes the problem (perhaps a config or project setting).

For me, thoroughly disabling code analyzers helped per instructions here:
https://learn.microsoft.com/en-us/visualstudio/code-quality/disable-code-analysis?view=vs-2019#net-framework-projects.
I thought my code analyzers were already off, but adding the extra xml helped.
Thanks Kaleb's for the suggestion to set "MSBuild project build [output|build log] verbosity" to Diagnostic. The first message took more than 10 seconds to display:
Property reassignment: $(Features)=";flow-analysis;flow-analysis" (previous value: ";flow-analysis") at C:\myProjectDirectory\packages\Microsoft.NetFramework.Analyzers.2.9.3\build\Microsoft.NetFramework.Analyzers.props (32,5)
Which led me to the code analyzers.

Just in case someone else trips into this issue:
In my case the delay was being caused by an invalid path entry in "additional include directories" that referred to a non accessible UNC location.
Once this was corrected, the delay disappeared.

MSBuild copy web project references without building

I'd like to have a web project in a solution that is set to "not build" in the solution configuration, however I would still like the project's references (and their dependencies) to be copied into that project's bin folder. There are class library projects in the sln that are actually built, and the web project references those.
Our current "build" just calls devenv, which does exactly this. For obvious reasons, I'd rather use MSBuild.
I am not looking for methods to do manual file copying (either individually or *.dll). There are many ways to do this. I am looking specifically for a way to replicate the behaviour that devenv.exe gives us - automatically copy references (and their dependencies) based on what is in the project section in the solution file (below).
These references come from the solution in this section:
Project("{E24C65DC-7377-472B-9ABA-BC803B73C61A}")="TheWebProjectName",
"Web\Project\Folder",
"{1CBD1906-0C2E-4C92-A81D-63C2AD816EA1}"
ProjectSection(WebsiteProperties) = preProject
TargetFrameworkMoniker = ".NETFramework,Version%3Dv4.0"
ProjectReferences = "{B125568E-E80C-4080-B8D3-5602B604734C}|Some.Reference.dll;
{117E8B0A-F0D6-47D0-BB51-71099969566D}|Some.OtherRef.dll;"
...
EndProjectSection
EndProject

MSBuild uses target files to determine it's build steps. Take a look at the relevant target files and determine how MSBuild copies those files, create your own target file and modify your build configuration to use the new target.
Relevant target files:
Location: C:\Windows\Microsoft.NET\Framework\v$(version)
Microsoft.CSharp.targets
Microsoft.Common.targets
Relevant documentation:
MSBuild
Specifying Targets

You can do build operations such as this using MSBuild Tasks: http://msdn.microsoft.com/en-us/library/ms171466(v=vs.80).aspx
In your specific case you'll probably be interested in the built in Copy Task: http://msdn.microsoft.com/en-us/library/3e54c37h(v=vs.80).aspx

Try using powershell instead of msbuild!! Ria services also relies strongly on powershell commandlets.
Cheers..

Call devenv.exe using an Exec task - we do it all the time for BizTalk solutions because old versions of MSBuild do not support the BizTalk project files...

How to automatically change which files are built depending on configuration - visual studio

I have a solution which is built for several customers, and I need to be able to specify different xml files for each customer. How can I do this automatically. I was thinking it might be done with different configurations, but can't seem to figure out how.
Any suggestions?
EDIT:
This is the code used for declaring the xml file right now:
protected readonly static string XML_PATH = #"Resources/xml/Description.xml";
And the way it is solved now is to manually copy the correct file to the Description.xml before building. This is of course error prone, and I would like to automate it, preferentially based on the configuration. I'm looking for a quick fix right now, as we unfortunately haven't got the time to refactor the code.

Build Configuration dependent config files are a tricky issue and there are multiple ways to solve it.
If you want to down the road you outlined, you would need to manually edit the *.csproj File and add a Conditional ItemGroup to include the correct xml file. The syntax below hasn't been checked, but something like this should do
<ItemGroup Condition="'${Configuration}' == 'DEBUG'">
<Content Include="blablabl.xml"/>
</ItemGroup>
I don't remember if Content was the right ItemGroup, but simply check what ItemGroup your current .xmls are in and use that.

Based on your reformulated question:
You could use conditional compilation (caveat: It's messy and not the right way to manage config files!):
protected readonly static string XML_PATH =
#if DEBUG
#"Resources/xml/Description.xml";
#else
#"Resources/xml/Description2.xml";
#endif
If you want to read up on better techniques for managing config files, this is worth a read.

Now, I now self-promotion is frowned upon, but in this case I hope it's ok as it sounds relevant to the question, and I don't gain anything from this.
Recently I wrote a couple of blog posts on how to target multiple environments/machines:
Targeting multiple environments and machines - part 1/2
Targeting multiple environments and machines – part 2/2
As I understand it, the problem in this case, is how do you automatically build the correct set of files without having to manually figure out which files belong to which customer/environment. The solution I propose in the blog posts, suggests the use of nAnt along with some extensions built on top. nAnt is the .NET versions of Ant, a build tool, which lets you generate e.g. xml files given a specific set of input files, allowing you for example to generate a customer specific web.config file.
In the following appSetting section of the web.config file, say you want to specify a different value for the CustomerName key for each customer:
<appSettings>
<add key="CustomerName" value="${CustomerName}"/>
</appSettings>
Instead of specifying a value for the CustomerName key, you define a property called CustomerName. Now, assuming we are using nAnt, you create another customer specific file with the following content:
<?xml version="1.0" encoding="utf-8"?>
<target xmlns="http://nant.sf.net/release/0.86-beta1/nant.xsd">
<property name="CustomerName" value="Acme Incorporated"/>
</target>
nAnt can then merge these two files and automatically build customer/environment specific files for you.
The solution I go through, allow you to automatically build environment and machine specific files, such as the web.config file, but also allow you to output static files such as license files or libraries, all depending on which environment/machine you are targeting. I also supply a sample Visual Studio 2010 solution that shows a very basic example on how to do it, which you can download here.
You can of course just go ahead and take a look at nAnt, but I thought I'd provide you with the option to use my solution.

Using an external tool for C# builds in Visual Studio

When using Visual Stdio 2008, you can make a C++ project build with an internal tool rather than having the IDE invoke MSVC directly. This improves the consistency of builds across platforms if a cross-platform build system is used.
However, I cannot figure out how to do the same as a C# project. It would be possible to simply register it as a native project with C# sources, however, you lose some of the advantages gained through having a C# project. More importantly, it will mean that allowing a project to build both directly and with an external tool (which is sadly necessary) will require two separate projects, rather than merely creating an alternate build configuration to invoke the external tool.
Does anyone know if it's possible to prevent Visual Studio from invoking csc by itself and instead call an external tool?
EDIT: Apparently there has some misunderstanding. The goal here is not to compile anything outside of Visual Studio. Instead, it's to allow Visual Studio to serve as the IDE but not the build system. There is already a (Scons-based) build system capable of compiling the C# and C++ sources, and Visual Studio has been configured to invoke Scons for compilation of C++ projects. I'm trying to configure it so that when you hit the 'Build' button, it will invoke Scons for the C# projects as well as the C++ ones.

Edit: Your question is still answered using MSBuild(if you are simply looking to compile outside the IDE). The IDE(Visual Studios) is simply a "fancy" way of constructing the build files that are built by MSBuild. Visual Studios isn't building the files, it simply is invoking MSBuild which ships with the .NET Framework 2.0 and up which compiles your code based on the project file that you create. If Scons can read and process an MSBuild file then I'm sure you can invoke it to build your project. But considering the fact that C# is a Microsoft language, I think you will be hard-pressed to find a value-add in not using MSBuild since I'd assume both the language and build tool are very tuned to work together. - End Edit
You can use MSBuild to compile your C# project. If you open your .csproj file in a text editor you will see that it is a MSBuild file. If you want to write some C# outside of the IDE you can construct a build file using the .csproj file as a starting point and invoke MSBuild to compile your apps. The IDE is just a way of abstracting the editing of the MSBuild file away for you.
If you are really industrious you can create a set of custom tasks to do things in your custom build process like move files around and versioning. MSBuild Community Tasks are a great example of using custom code to do task for you during MSBuild.

Given all the other answers, what MSBuild does when either VS or MSBuild perform a build can be found in the Targets files that ship with .Net. These can be be found in the FrameWork directory on your system. In my case:
C:\Windows\Microsoft.NET\Framework64\v3.5
Contains Microsoft.Common.targets among others. This file contains the following snippit:
<!--
============================================================
Build
The main build entry point.
============================================================
-->
<PropertyGroup>
<BuildDependsOn>
BeforeBuild;
CoreBuild;
AfterBuild
</BuildDependsOn>
</PropertyGroup>
<Target
Name="Build"
Condition=" '$(_InvalidConfigurationWarning)' != 'true' "
DependsOnTargets="$(BuildDependsOn)"
Outputs="$(TargetPath)"/>
This means that redifining this Target you can make MSBuild an VS do anything you want. The top of the mentioned file contains an important messagge:
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#.
My suggestion would be to read all you can about MSBuild and it's build file syntax and try redifining the Build target in your project(s). My impression is that after reading up on MSBuild you'll probably find an easier way to meet your requierements. You can find an example of redifining a Target like this in one of the answers of this so question .
Edit:
How to redefine a target?
Redefining is essentially defining the same target 'after' it has been defined. So for instance in your .*proj file(s) define a Build Task after the <Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" /> line that imports all targets needed to in this case build a C# project. An example could be
<Target
Name="Build"
Condition=" '$(_InvalidConfigurationWarning)' != 'true' "
DependsOnTargets="BeforeBuild"
Outputs="$(TargetPath)">
<Exec Command="nmake" />
</Target>

I found a question in the same direction here, where it is suggested to edit the registry. I am pretty sure there is no other way to change the compiler used by Visual Studio because there is no trace of csc.exe in any solution, config, csproj file or whatsoever, nor in the Visual Studio 9.0 folder / subfolders within the Program Files dir.
Registry locations can be found in:
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
but those keys may differ dependng on your installation. Conclusion: changing the compiler used by VS seems next to impossible.
Addition: The following MSDN article deals with the same question for an custom C++ compiler, and Ed Dore's answer seems to confirm my theory that there's no way to choose an custom compiler for use within VS.

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.

You don't have to maintain different project files to build using an external tool. MSBuild is designed to build using the same project files that Visual Studio uses.
Here's an article that describes it.
Customize Your Builds in Visual Studio Using the Standalone MSBuild Tool
It's for VS2005, but should apply to VS2008 as well.

Looking through the answers, it seems clear to me that integrating scons into Visual Studio in a way that is compatible with the debugger and so on is not going to happen...
An option you might to consider, and I understand you don't want to change build systems, but bear with me, is to use a meta-build system, ie 'cmake'. http://www.cmake.org/
Cmake doeesn't actually build the project. What it does is to create build files for you, that you can use to build the project, and on Windows, the build files it creates for you are: Visual Studio project files. You can simply load those directly into your IDE, and compile, and use normally!
CMake is I feel very easy to use, and provides a high level of transparence and maintainability.
The exact same CMakeLists.txt files on linux will causes linux makefiles to be generated.
On mingw, they can generate mingw makefiles.
There are numerous generators available within cmake. The list is here:
http://www.cmake.org/cmake/help/cmake-2-8-docs.html#section_Generators
http://springrts.com is a huge opensource rts game that used to use scons as its cross-platform build system and now uses cmake.
I understand that you don't really want to have to change build systems, so it is a medium to long term solution.
Cmake is in any case one more option, to add to those of using a custom build tool, or using msbuild, or running the scons build from the commandline by hand.

Edit your project file and update the CscToolPath keys to point to the directory containing your tool and add CscToolExe keys that holds the name of the directory:
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|.NET 3.5' ">
.
.
.
<CscToolPath>path\to\custom\tool\directory</CscToolPath>
<CscToolExe>exe name</CscToolExe>
.
.
.
</PropertyGroup>
I have not tested this, and the CscToolExe key may cause problems, in which case I would simply rename the external tool executable to "csc.exe".

You can build your solution from the command line like this:
C:\WINDOWS\Microsoft.NET\Framework\v3.5>msbuild.exe "C:\path\Your Solution.sln"