I am developing a custom MSBuild task following the guidance outlined in the Microsoft Example. The development workflow is not good because whenever I change my task and I want to test it, to do that I need to restart VS (I'm testing the task by referencing it in another project using <UsingTask>).
I replicated the suggested code snippet into my MSBuildConsoleExample.csproj file, and the file was generated successfully.
However, upon making modifications to the task implementation in AppSettingStronglyTyped project, I encounter an error during the build process. The specific error message is as follows:
Severity Code Description Project File Line Suppression StateWarning MSB3026 Could not copy "obj\Debug\netstandard2.0\AppSettingStronglyTyped.dll" to "bin\Debug\netstandard2.0\AppSettingStronglyTyped.dll". Beginning retry 1 in 1000ms. The process cannot access the file 'bin\Debug\netstandard2.0\AppSettingStronglyTyped.dll' because it is being used by another process. The file is locked by: "MSBuild.exe (760)" AppSettingStronglyTyped D:\Program Files\Microsoft Visual Studio\2022\Professional\MSBuild\Current\Bin\amd64\Microsoft.Common.CurrentVersion.targets 4734This issue significantly impedes local testing and development, requiring a restart of Visual Studio each time changes are made. I am seeking guidance or potential solutions to overcome this file locking problem in order to facilitate smoother local development.
For reference, the relevant code snippet can be accessed here
Current workaround
Currently, to address the file locking issue, I follow a workaround by restarting Visual Studio, rebuilding the AppSettingStronglyTyped, and then rebuilding the MSBuildConsoleExample.
Ideally, the expected behavior would allow seamless updates to the generated files within AppSettingStronglyTyped without necessitating a restart of Visual Studio. This way, changes made in AppSettingStronglyTyped would reflect in MSBuildConsoleExample without the need for a full restart of the development environment.
Attempt with Local Nuget Package
In an attempt to mitigate the issue, I experimented with using a local NuGet feed and generating a new NuGet package with each build iteration. However, this approach exposed a Visual Studio caching problem. It required a waiting period of approximately 3 minutes to update the NuGet cache or, again, necessitated the reopening of Visual Studio to resolve the caching issue.