I have a Visual Studio solution with x projects. Each project has (post) build events consisting of two or more lines.
When the build events are executed, a locking problem occurs:
The specified task executable "cmd.exe" could not be run. The process cannot access the file 'D:\Users\<user>\AppData\Local\Temp\tmpff905f7a0bf94226b86296693df6861c.exec.cmd' because it is being used by another process.
I suspect that Visual Studio writes the multiple lines to the unique temporary file which should be executed by cmd.exe. I first suspected there was a conflict between parallel builds, but since each build seems to create a unique file, that cannot be the cause.
Anohter nice detail is that the file in question, is not deleted after the error. When I open it, it is empty.
So...
Why is there a conflict?
Why is it empty?
Related
We have a large solution (~200 projects) that is being built on an on-premise build agent (TFS 2015) and are seeing some random build failures at the msbuild step with an error like this:
C:\Program Files (x86)\Microsoft Visual
Studio\2019\BuildTools\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets
(4384, 5) Unable to copy file
"C:\Work\100\s\Code\packages\MSTest.TestFramework.2.1.1\lib\net45\Microsoft.VisualStudio.TestPlatform.TestFramework.Extensions.xml"
to
"..\bin\Debug\Microsoft.VisualStudio.TestPlatform.TestFramework.Extensions.xml".
Access to the path
'..\bin\Debug\Microsoft.VisualStudio.TestPlatform.TestFramework.Extensions.xml'
is denied.
The error seems to occur randomly and typically if we run the build again it completes without error. As this is a continuous integration build we'd like to resolve the problem so it only fails for legitimate reasons. Developers on the team are getting too used to seeing build failures and are starting to miss legitimate failures with tests not passing!
The file itself is not being held open by any other process before the build starts (we are performing a clean get so it does not exist prior to the build starting) or after the build completes (have logged on to the server after a failed build and confirmed it is not held open by anything) so it appears to be the build process itself that is transiently holding the file open. My assumption is that, as we have multiple test projects in the solution referencing the test framework and all projects are set to use a common output folder, when they are being built in parallel there is a race condition and one project being built is holding open/writing to the file at the same time another wants to copy the file over.
We don't want to disable parallel builds if possible as this will add a significant amount of time to the build process, which is already a lot longer than I'd like.
I had considered turning off the copy local option on all but one of the projects but the error is related to an XML file rather then the DLL file that is being referenced.
So my questions would be:
Is my assumption correct that this would be caused by parallel builds or is there another reason it might be happening?
Why are the XML files being copied to the output folder in the first place?
Can the copying of the XML files be suppressed in any way as I don't think we actually need them there?
If we are unable to suppress copying the XML files are there any alternative ways that we could stop the error from occurring?
Thanks in advance for any help/advice.
Is there a way to continue a solution build process on error?
My problem is this: robocopy returns code 3 ("(2+1) Some files were copied. Additional files were present. No failure was encountered.") in one of my projects. Even though the code is not problematic, this stops the build process. Is there a way to prevent it?
We noticed that on a certain dev machine a Visual Studio (2015 update 3) debug build of a C# solution was generating a $RANDOM_SEED$ file alongside every built DLL.
The content of the file is just a single number e.g.
1443972318
Deleting the file(s) then rebuilding resulted in the file being regenerated, with a different number.
This behaviour was also observed when rebuilding a single project in the solution (one which has only the standard C# project refs/dependencies + System.Management).
Note that running a command line build e.g.
msbuild <sln-file>
did not regenerate the file (for build of complete solution or single project).
After a restart of VS, the file is no longer regenerated.
As far as we know this file name is not used in any of our source code, post build steps or internal dependencies.
There are quite a few dependencies on .NET framework classes, including Random and RNGCryptoServiceProvider, and also external dependencies. We don't have complete source code for all these so it's not possible to check exhaustively which if any of the dependencies are responsible.
This is a bit of a shot in the dark but the question is has anyone seen anything similar to this?
EDIT
I'm not surprised this has been downvoted - I appreciate it is pretty open ended, but as I'm currently not able to reproduce this and as it could have potentially serious consequences (random number generator attack?) I have posted it anyway. If I am able to repro I will of course update here.
I have the same file.
After a short investigation I found guilty:
this file is created by NUnit 3.x test adapter.
(You can check it in AdapterSettings.cs from NUnit adapter source code).
The file is used by NUnit to ensure that we use the same random seed value for generating random test cases in both the discovery and execution processes. This is required because the IDE uses two different processes to execute the adapter. It's not actually required (or created) when running the adapter under vstest.console.exe.
I have a solution with several projects in it that executes many custom build steps. Some projects depend on other projects, but most of the build steps are independent of each other.
When building inside the VS 2010 IDE, I am getting errors like this:
error MSB6003: The specified task executable "cmd.exe" could not be run. The process cannot access the file 'C:\full\path\Debug\custombuild.write.1.tlog' because it is being used by another process
However, when I build the solution with MSBuild from the command line, all is well, and the log file writing does not seem to cause the same error.
Is this a known issue? Google has not been much help today...
The answer was hinted at in an MSBuild forum thread.
The custom build rule logs are written into the containing project's $(IntDir). We had multiple projects (with no real output being sent to IntDir) that all inadvertently shared the same IntDir value. Giving each project its own IntDir value eliminated the problem.
I've created a custom build step in Visual Studio 2010 that produces multiple files by running a command-line tool. The step creates these files as it should when invoking a build, but on a clean, it only cleans the first file I listed as an output of the step in the "Outputs" field of the custom build step. I've separated individual files with a semicolon and also tried the multi-line editor for the field and put each file on a separate line (VS inserts the semicolons when closing the multi-line editor). In any case, it doesn't seem to be the format of the field that's the issue - whatever file is first gets cleaned, the rest don't.
From reading the documentation, it seems that you should be able to have multiple files listed as output so that the step can properly clean any artifacts it produces. Does anything special need to be done to clean multiple files or is this a bug?
If the temporary output file extension filter doesn't work (which seems to be your case), try making a script that checks if any files were generated from a previous build; if so, delete them, if not do nothing, then carry on with the script you normally use. Set this as a prebuild step.
I had a custom VS shell and I couldn't select the temporary file extensions in that shell and this was the only solution I could use at the time. (obviously, if you're in a hurry, you can just call rm or del and not worry about checking first).
If you're good at perl, try using that, if not just use a normal batch file.
If it is a bug that happens to a lot of people, maybe they'll fix it someday. Personally I use VS2008 just cos I don't trust VS2010.