Develop Reference

Preventing VS 2019 from rebuilding a solution though no source has changed

I am trying to track down a VS 2019 build issue for a few weeks which drives me crazy. I have a C# project (targeting .Net Framework 4.8) which VS rebuilds regularly even when nothing has changed. The project is not very complex and has no specific dependencies, but a postbuild event which must always be executed. Hence I used the approach described in this answer, which forces msbuild to do the "up-to-date" check instead of the VS IDE. This has worked well for years, but started to make trouble a few weeks ago.
To create a minimal reproducible example:
use the VS project wizard to create a trivial "hello world" console app, .Net Fw 4.8, AnyCpu
add the following lines to the csproj file:
<PropertyGroup>
<RunPostBuildEvent>Always</RunPostBuildEvent>
<PostBuildEvent>
</PostBuildEvent>
<DisableFastUpToDateCheck>true</DisableFastUpToDateCheck>
</PropertyGroup>
change the "Run Post Build" setting in the IDE's project settings to "On Build Success" (or back to "Always", this does not really matter), save the settings
The Postbuild action is intentionally left empty, one can add arbitrary actions here, but even an empty action will produce the issue.
When I choose to rebuild the solution in the IDE (using Ctrl-Shift-B), without touching anything the source code, the executable is recreated. This effect occurs when the time between two consecutive builds is approx. 10 seconds or more, when I rebuild the solution quicker, the exe file stays untouched.
To make the effect more visible, I set "AssemblyVersion("1.0.0.*"), stripped the "AssemblyInformationalVersion" attribute from AssemblyInfo.cs, so the build system assigns a new build number to the exe file with each new creation, which allows to observe the effect in the Windows Explorer more easily (by activating the "File Version" column in the Explorer view).
Note this effect does not seem to occur when I comment out either the post build event, or the DisableFastUpToDateCheck setting.
I observed this with VS 2019 V16.11.9 and V16.11.10 (currently the latest versions in the "2019" product line).
In my real project, this happens for a central DLL inside a solution where more then 70 other projects depend on, including a large C++/CLI dll, resulting in a build time of ~2 minutes - every time I only want to start the debugger, since this causes a new build! And yes, I also tried to set the "project build output" settings to "Diagnostic", but could not find anything suspicious in the large amount of messages.

PostBuildEvent is problematic and 'old style' since it doesn't define its inputs and outputs. Because of that msbuild can't calculate whether it caused any files to change and thus forces a rebuild.
By replacing the postbuildevent with a custom target and by correctly specifying the inputs and outputs of the target, MSBuild can check whether any of the inpu ts have changed and whether the outputs are up to date to properly decide to skip the build altogether.
See:
https://learn.microsoft.com/en-us/visualstudio/msbuild/incremental-builds?view=vs-2022
PostBuildEvent is also no longer supported in new style SDK projects. Visual Studio will now automatically generate a new target when you setup a postbuild event in the UI.

Starting with jesshouwing's answer, and using this information from Microsoft how to extend the VS build process, I implemented this workaround: in the csproj, I added the following section the end:
<Target Name="CustomAfterBuild" AfterTargets="Build"
Inputs="... input for postbuild step ..."
Outputs=" ... output of postbuild step ..">
<Message Text="... some message here ..." />
<!-- here are the post build actions -->
</Target>
This seems to work well for now without the nasty effects. The only drawback here is that this custom build step does not show up in the Visual Studio project editor, but I can work with that.

Multidex Xamarin Maps android issues

After adding the Xamarin maps nuget package to my app, I was getting the Java.exe has exited with code 2 error. I enabled multi-dex in the android options and I am now getting the following error:
Expecting class path separator ';' before '\Android\android-sdk\build-tools\26.0.0-preview\lib\shrinkedAndroid.jar'
I re-installed the Android SDK and made sure that I had the latest version, however I am still getting the error. I've spent a good while googling this issue and trying different solutions, however I have not found one to work

There are some issues with multi-dex at the current build. Updating to Visual Studio 2017 13.2 may fix the issue you mentioned. If it doesn´t, you can try two things:
To fix the class path separator error, put your Android SDK in a path without spaces. i.e: C:\android-sdk\ and change the path in Tools>Options>Xamarin>Android SDK Location.
If you don´t want to move the SDK you can create a link with a command line:
mklink /D "C:\android-sdk" "C:\Program Files (x86)\Android\android-sdk"
If even with Multi-dex enabled, it doesn´t run:
When you tick "Enable Multi-Dex" option in the Android project properties, you´ll see the change reflected in the csproj as you would expect
<AndroidEnableMultipleDex>true</AndroidEnableMultipleDex>
But if you take a closer look, there is another similar xml node that keeps its value to false:
<AndroidEnableMultiDex>false</AndroidEnableMultiDex>
Notice the difference between "MultiDex" and "MultipleDex"
Changing the second one to true will make the trick.

I have same problem while adding map with nuget package to my app.
just change the latest proguard.jar file from link
and replce from your android sdk-> tools->proguard->lib->progaurd.jar
and
right click on your android project->select option->build->android build-> enable proguard and enable multidex as well go to Advance ->java heap size put 1G.

I had this same issue running Visual Studio 2017 v 15.2.
As has been mentioned before, this results when you've added enough nugets and packages to your solution that you exceed the 65k method limit in a standard dex file, requiring you to enable multi-dex.
Like others have noted, enabling multi-dex doesn't always fix the problem, because it turns on a flag called "AndroidEnableMutipleDex" in the .csproj file. So, as suggested above, I added the node
<AndroidEnableMultiDex>true</AndroidEnableMultiDex>
but, since I wasn't too familiar with the format of the .csproj file, I forgot to add it under both
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
...
<AndroidEnableMultipleDex>true</AndroidEnableMultipleDex>
<AndroidEnableMultiDex>true</AndroidEnableMultiDex>
</PropertyGroup>
and
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
...
<AndroidEnableMultipleDex>true</AndroidEnableMultipleDex>
<AndroidEnableMultiDex>true</AndroidEnableMultiDex>
</PropertyGroup>
Yes, this a a basic mistake, but it can be easy to make if you're not used to manually editing your .csproj file, especially if you're just wading into this for the first time and not even sure where exactly the bug is coming from.
Also, as others have noted, you will need to move the location of your Android sdk to a path with no spaces.

How to add/update references without Visual Studio using a custom script?

I am trying to build a previously created .NET application (VS2015 Community), but before building I have to solve several issues manually. One of these issues is to add/update reference to System.Web.Mvc.dll which is located in local project folder.
In Visual Studio 2015, this is fairly easy. Just click References and then proceed to Add reference, where you Browse the correct reference. However, I want to perform this step without using Visual Studio with my custom script, which performs this automatically.
Is this even possible to do without Visual Studio? If it is, what other requirements should be taken into account in general?
I am new with Visual Studio programming (mainly programmed with GNU/Linux), so I am not aware of all limitations or possibilities regarding to VS and Microsoft BuildTools.
Thank you.

The references are listed in the project file.
I've never been able to find proper documentation for those (but see here: http://msdn.microsoft.com/en-us/library/5dy88c2e.aspx and here: https://msdn.microsoft.com/en-us/library/dd576348.aspx, but when you inspect it it should become clear. You'll need to add to the ItemGroup which includes the references. It'll look something like this:
<ItemGroup>
<Reference Include="System" />
...
</ItemGroup>
How you want to update the file is up to you, but an XSLT transformation seems a reasonable way, or your script could just do raw xpath stuff

$(ProjectName) and $(TargetName) MSBuild macros not working

I am using Visual Stduio 2015 Community Edition. I have loaded a C# project and want to configure it to use shadow building, so that source files are not messed up with any binaries or intermediate build files. Tried to set the [output]/[intermediate output] directory paths of the C# project using the VS UI - the only UI-editable output path is the "bin" one and it doesn't accept MSBuild macros. Then I've unloaded the project and manually edited it. Also set the IntermediateOutputPath which is not available in the VS UI when using C# project, but when using C++ one all such kind of directories are editable.
Currently, the OutputPath is set to:
<OutputPath>$(SolutionDir)..\build_$(SolutionName)_$(Configuration)_$(Platform)\$(ProjectName)</OutputPath>
$(ProjectName) is empty for some reason. Tried $(TargetName) (it is not correct to use it but just for the test) but it is empty, too. Any suggestions?

Do not try to import Microsoft.CSharp.targets - like suggested in another answer.
First of all - it will lead to additional warning like
Warning MSB4011: "Microsoft.CSharp.targets" cannot be imported again. ...
But additionally to that if you try to edit pre-/post- build Visual studio will crash.
(Observed in Visual studio 2019, 16.7.7 version)
Better to use $(MSBuildProjectName) macro instead of $(ProjectName) - works identically.

The problem is that some of the MSBuild properties like ProjectName are set after the following line in your .csproj file.
<Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />
After this line you can access all variables.

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"