dotnet / dotnet/project-system
Make Build Acceleration support symbolic/hard links
- Dominant language
- C#
- Stars
- 1k
- Forks
- 415
- PR merge metrics
- No merged PRs in 30d
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:
- `CreateSymbolicLinksForCopyFilesToOutputDirectoryIfPossible`
- `CreateSymbolicLinksForCopyAdditionalFilesIfPossible`
- `CreateSymbolicLinksForCopyLocalIfPossible`
- `CreateSymbolicLinksForAdditionalFilesIfPossible`
- `CreateSymbolicLinksForPublishFilesIfPossible`
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:
```
false
true
true
```
## 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](https://github.com/dotnet/msbuild/issues/8273#issuecomment-1534938767)
Contributor guide
Assessment
This issue has not been assessed yet.