0

I have noticed that when I run devenv on the command line it does background compilation before proceeding with the foreground one. I have a strong suspicion that something is terribly wrong with my environment.

Please, observe:

PS C:\work\a> dir


    Directory: C:\work\a


Mode                LastWriteTime     Length Name
----                -------------     ------ ----
d----        11/26/2014  12:40 AM            .hg
-a---        11/25/2014  11:48 PM         87 .hgignore
-a---        11/26/2014  12:39 AM        264 1.ps1
-a---        11/26/2014  12:38 AM       1594 a.csproj
-a---        11/26/2014  12:43 AM          2 in.txt


PS C:\work\a>

Where

1.ps1

param([switch]$msbuild)

$in="in.txt"
(dir $in).LastWriteTime = Get-Date
dir $in |% { $_.Name + " : " + $_.LastWriteTime.ToString("yyyy-MM-dd HH:mm:ss.ffffff") }
if ($msbuild)
{
  msbuild .\a.csproj /v:m
}
else
{
  devenv .\a.csproj /build Debug /SafeMode
}

This is a simple Powershell script that:

  1. Touches the input file
  2. Prints its timestamp
  3. Builds the project either using msbuild or command line devenv.

a.csproj

<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="4.0">
  <PropertyGroup>
    <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
    <Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
    <ProjectGuid>{EB5EB1C9-DC39-4E48-875B-094CBC0F468A}</ProjectGuid>
    <ProjectTypeGuids>{fae04ec0-301f-11d3-bf4b-00c04f79efbc}</ProjectTypeGuids>
    <OutputType>Library</OutputType>
    <AppDesignerFolder>Properties</AppDesignerFolder>
    <RootNamespace>a</RootNamespace>
    <AssemblyName>a</AssemblyName>
    <TargetFrameworkVersion>v4.5.2</TargetFrameworkVersion>
    <FileAlignment>512</FileAlignment>
    <TargetFrameworkProfile />
    <OldToolsVersion>2.0</OldToolsVersion>
    <OutputPath>bin\$(Configuration)</OutputPath>
  </PropertyGroup>
  <ItemGroup>
    <None Include="in.txt" />
  </ItemGroup>
  <Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
  <PropertyGroup>
    <CompileDependsOn>$(CompileDependsOn);MyTarget</CompileDependsOn>
  </PropertyGroup>
  <Target Name="A" BeforeTargets="_CheckForInvalidConfigurationAndPlatform" Condition="Exists('out.txt')">
    <ItemGroup>
      <Out Include="out.txt"/>
    </ItemGroup>
    <Message Text="%(Out.Identity) : %(Out.ModifiedTime)" Importance="High" />
  </Target>
  <Target Name="MyTarget" Inputs="in.txt" Outputs="out.txt">
    <Message Text="Touching now ..." Importance="High" />
    <Touch Files="out.txt" AlwaysCreate="true" />
  </Target>
</Project>

As you can see this is a trivial C# project without any source code at all. It:

  • Injects the MyTarget target into the CompileDependsOn list.
  • Outputs the timestamp of the input file (in.txt) before running any build related targets.
  • If the input file is newer than the output file (out.txt), then MyTarget is run and it prints a message and touches the output file

Now here is what happens when I run the script demanding devenv command line build:

PS C:\work\a> .\1.ps1
in.txt : 2014-11-26 00:44:09.078676

Microsoft (R) Microsoft Visual Studio 2012 Version 11.0.61030.0.
Copyright (C) Microsoft Corp. All rights reserved.
1>------ Build started: Project: a, Configuration: Debug Any CPU ------
1>  out.txt : 2014-11-26 00:44:09.7744589
1>  a -> C:\work\a\bin\Debug\a.dll
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========
PS C:\work\a>

Notice that no "Touching now ..." message is displayed, yet the timestamp of the output file (2014-11-26 00:44:09.7744589) is already newer than that of the input file (2014-11-26 00:44:09.078676) and this is BEFORE the very first build target is run! Indeed, when I build in the diagnostic verbosity level, it says to me that the outputs are up-to-date with respect to the inputs!

Now look what happens when I build with msbuild:

PS C:\work\a> .\1.ps1 -msbuild
in.txt : 2014-11-26 00:44:15.854564
Microsoft (R) Build Engine version 4.0.30319.34209
[Microsoft .NET Framework, version 4.0.30319.34209]
Copyright (C) Microsoft Corporation. All rights reserved.

  out.txt : 2014-11-26 00:44:09.7744589
  Touching now ...
  a -> C:\work\a\bin\Debug\a.dll
PS C:\work\a>

Everything is as expected - the output file timestamp (2014-11-26 00:44:09.7744589) is older than that of the input file (2014-11-26 00:44:15.854564). So, the "Touching now ..." message is printed.

Note, that I run devenv in the safe mode. I am using VS2012.

Edit 1

Hooking into CoreBuildDependsOn yields the expected results:

<CoreBuildDependsOn>$(CoreBuildDependsOn);MyTarget</CoreBuildDependsOn>

And the result is:

PS C:\work\a> .\1.ps1
in.txt : 2014-11-26 12:55:56.787793

Microsoft (R) Microsoft Visual Studio 2012 Version 11.0.61030.0.
Copyright (C) Microsoft Corp. All rights reserved.
1>------ Build started: Project: a, Configuration: Debug Any CPU ------
1>  out.txt : 2014-11-26 12:54:29.8173007
1>  a -> C:\work\a\bin\Debug\a.dll
1>  Touching now ...
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========
PS C:\work\a>

Note the "Touching now ..." message and the out.txt timestamp before the build is older than that of in.txt - as expected.

Conclusion: the Compile target is invoked silently by devenv in the background, but not the CoreBuild. Why is this so?

halfer
  • 19,824
  • 17
  • 99
  • 186
mark
  • 59,016
  • 79
  • 296
  • 580
  • Maybe VS needs to do a background compile to get Intellisense information? You could try inserting a = false directive in your .csproj files and see if that results in characteristics that you like better. http://stackoverflow.com/a/646153/253938 – RenniePet Nov 26 '14 at 07:46
  • Tried it. No effect whatsoever. – mark Nov 26 '14 at 17:11

1 Answers1

1

Found this - https://social.msdn.microsoft.com/Forums/en-US/bf86d834-0e48-42ff-b2e4-5f930597bef0/background-compilation-in-visual-c?forum=csharpide

So, the answer is we cannot prevent background compilation, but our custom Compile targets can be written defensively by testing the BuildingProject property. Or so it seems, because I did not actually test it, moving the logic into the CoreBuild dependency seems good enough for me.

mark
  • 59,016
  • 79
  • 296
  • 580