Make Build Acceleration support symbolic/hard links #9548
Description
Visual Studio Version
Version 17.11.4
Summary
Is it possible to make FUTDC (Fast Up-to-Date Check) work properly with symbolic links?
In my large project, I’m using MSBuild properties for symbolic links, such as:
CreateSymbolicLinksForCopyFilesToOutputDirectoryIfPossibleCreateSymbolicLinksForCopyAdditionalFilesIfPossibleCreateSymbolicLinksForCopyLocalIfPossibleCreateSymbolicLinksForAdditionalFilesIfPossibleCreateSymbolicLinksForPublishFilesIfPossible
This helps save disk space and avoids unnecessary copying of files.
By default, this doesn't work in Visual Studio, so have a couple of hacks to make it work, like next:
<Target Name="RestoreSymlinksInsideVisualStudio_FilesToOutputDirectory"
BeforeTargets="CopyFilesToOutputDirectory"
Condition="'$(EnableSymbolicLinks)' == 'true' and '$(BuildingInsideVisualStudio)' == 'true'">
<PropertyGroup>
<BuildingInsideVisualStudio>false</BuildingInsideVisualStudio>
<WasBuildingInsideVisualStudio>true</WasBuildingInsideVisualStudio>
</PropertyGroup>
</Target>
<Target Name="Rollback_RestoreSymlinksInsideVisualStudio_FilesToOutputDirectory"
AfterTargets="CopyFilesToOutputDirectory"
Condition="'$(EnableSymbolicLinks)' == 'true' and '$(WasBuildingInsideVisualStudio)' == 'true'">
<PropertyGroup>
<BuildingInsideVisualStudio>true</BuildingInsideVisualStudio>
</PropertyGroup>
</Target>
Actual Behavior
When I build the project, it seems that file copying related to the up-to-date check fails, likely due to the symbolic link. Here's an excerpt from the log:
13>FastUpToDate: Copying 4 files to accelerate build (https://aka.ms/vs-build-acceleration): (MyPrefix.ProjectA)
13>FastUpToDate: From 'C:\src\MyPrefix.ProjectA\bin\MyPrefix.ProjectADependency.dll' to 'C:\src\MyPrefix.ProjectA\bin\MyPrefix.ProjectADependency.dll'. (MyPrefix.ProjectA)
13>FastUpToDate: Exception copying file, scheduling MSBuild: System.IO.IOException: The process cannot access the file 'C:\src\MyPrefix.ProjectA\bin\MyPrefix.ProjectADependency.dll' because it is being used by another process.
13> at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
13> at System.IO.File.InternalCopy(String sourceFileName, String destFileName, Boolean overwrite, Boolean checkHost)
13> at Microsoft.VisualStudio.IO.Win32FileSystem.CopyFile(String source, String destination, Boolean overwrite, Boolean clearReadOnly)
13> at Microsoft.VisualStudio.ProjectSystem.VS.UpToDate.BuildUpToDateCheck.FileSystemOperationAggregator.TryApplyFileSystemOperations() (MyPrefix.ProjectA)
13>FastUpToDate: Up-to-date check completed in 5.7 ms (MyPrefix.ProjectA)
13>------ Build started: Project: MyPrefix.ProjectA, Configuration: Debug Any CPU ------
Where C:\src\MyPrefix.ProjectA\bin\MyPrefix.ProjectADependency.dll is a symbol link in the project output dir from previous builds.
Expected Behavior
It's unclear to me what the ideal expected behavior should be in this case, but it would be great if this error could be avoided and the MSBuild call skipped because in general it can be accelarated to my mind.
Steps To Reproduce
Since the sln is quite complicated I don't provide the exact steps at that time, but if you will say that it makes sense, I can try to provide repo which reproduces behavior.
User Impact
In my case, this issue triggers the build of subsequent projects because of the failure to copy files during the up-to-date check.
MSBuild in past i think worked on a similar problem here