Creating the same solution using msbuild and devenv interchangeably

Question

It so often happens that I start by creating some solution on the command line using msbuild, run it for a while, but then find that I need to change it and debug it. So, I open it in Visual Studio and eventually create it inside Visual Studio.

What happens is that VS restores many parts of the solution, even when I am not changing anything!

Falling into it, you will see the following:

Creating inside Visual Studio generates empty cs files and inserts them into a group of Compile elements. . Naturally, they are newer than already created binaries, and therefore devenv.exe restores a lot of projects. Thanks to TemporaryGeneratedFile_ [guid] in / obj / debug break build

This is a real bummer. I disabled this behavior by renaming the Microsoft.WorkflowBuildExtensions.targets file - I am not running a workflow.

Suppose I could hack CoreCompileDependsOn and somehow neutralize the target of Microsoft.WorkflowBuildExtensions.targets GenerateCompiledExpressionsTempFile , but this needs to be done in 190 projects! This is a major change.

devenv.exe seems to take care that some files are always copied to the output directory , even if msbuild does not consider this to be a problem.

Indeed, here is a line from the devenv.exe build log:

 Project 'HRCore.Tests' is not up to date. Project item 'C:\abc\UI\HRCore.Tests\HRImport\Import_missing_state_county.xml' has 'Copy to Output Directory' attribute set to 'Copy always'. 

So what? msbuild does not care about this, but devenv does. These files are not dependent on HRCore.Tests , and msbuild is correct.

In the meantime, I changed it from Always to PreserveNewest .

In any case, I am interested to know how I can eliminate these differences.

For example, is it worth setting BuildingInsideVisualStudio to true even when creating with msbuild?

Any ideas?

PS

We create .NET and Silverlight. Console applications, dll and web applications.

Answer 1

This .targets file .targets indeed cause different behavior between Visual Studio and the MsBuild command line due to an explicit check for $(BuildingInsideVisualStudio) :

  <PropertyGroup> <PrepareResourcesDependsOn> ValidationExtension; ExpressionBuildExtension; $(PrepareResourcesDependsOn) </PrepareResourcesDependsOn> </PropertyGroup> <PropertyGroup> <!-- Explicit check for Visual Studio here --> <CoreCompileDependsOn Condition="'$(BuildingInsideVisualStudio)' == 'true'"> GenerateCompiledExpressionsTempFile; $(CoreCompileDependsOn) </CoreCompileDependsOn> </PropertyGroup> 

This explicit check makes creating a temp file only in Visual Studio in my configuration. These files are created so that you can enter and debug them when working inside Visual Studio.

You can disable the behavior by overriding <GenerateCompiledExpressionsTempFilePathForEditing /> to empty in the project file so that it explicitly clears it on the command line.

 /p:GenerateCompiledExpressionsTempFilePathForEditing='' 

This condition protects this behavior:

  <Target Name ="GenerateCompiledExpressionsTempFile" Condition = "'$(GenerateCompiledExpressionsTempFilePathForEditing)' != ''"> 

Looking at the MsBuild path, you should completely disable compiled expression generation by passing /p:DisableWorkflowCompiledExpression=true on the command line.

You can also override CoreCompileDependsOn and remove the GenerateCompiledExpressionsTempFile; element from it GenerateCompiledExpressionsTempFile; .

This is really useless when there is a “special behavior” when creating inside the editor. In the end, I am always mistaken in forcing Visual Studio to behave like MsBuild, and not vice versa. Many other purposes will use special services or host compiler availability, if BuildingInsideVisualStudio true, it seems like a very bad idea to make MsBuild in Visual Studio, although this is actually not the case.