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.
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.
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 couple of build definitions for continuous integration running on VSO using an on-premises server. The thing is that sometimes they fail because Microsoft.WindowsAzure.targets was not able to copy some files when building the Azure projects (while building locally, both using VS or MSBuild, works always).
The basic structure of my solution is as follows:
Solution
|_Azure.Web.App
| |_Roles
| |_Web.App
|_Web.App
|_Controllers
|_Models
|_Resources
| |_File1.csv
| |_File2.csv
|_Startup
| |_File3.cmd
| |_File4.xml
| |_File5.msi
|_Views
And the problem is that files from Resources and Startup folders are not copied to the output directory when building Azure.Web.App, showing this error:
[error]C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\Windows Azure Tools\2.7\Microsoft.WindowsAzure.targets(2787,5): Error MSB3030: Could not copy the file "Resources\File1.csv" because it was not found.
All files are set to always copy to output directory and the build actions are as follows:
Content for CSV and XML files.
None for CMD and MSI files.
I haven't been able to pinpoint the circumstances when this happens, and they seem pretty random to me. Generally triggering again the build manually and/or deleting the source files at the agent directory before building again solve the issue, which is not ideal, as continuous integration is unreliable at the moment.
Have had a good look at all existing topics but haven't found one that fits my situation. Sorry if the question has already been asked, and thanks in advance.
EDIT: Forgot to mention I'm talking about new build definitions based on vNext (not XML-based builds).
I've found that in some cases where this particular error occurs, you can stop it from happening by passing a /m:1 option in the "MSBuild arguments" setting for the MSBuild step.
This prevents concurrent builds, forcing MSBuild to process things one project at a time. Sadly, this seems to be a workaround for quite a lot of build problems.
I have a project where there are files in a particular non-standard textual format. When these files are touched/modified, I want to run a certain custom compiler on them to generate XML, which is part of the output of the whole solution.
I'm considering creating a MSBuild task to do this. It will take as input the non-stadard file names and output the requisite XML files. The task will then be used in the other projects in the solution.
I want new developers on this project to have minimal setup. That means, I want to be able to take a clean copy of my solution directly from source control and have the build first build the custom task, then apply it as necessary to the other projects in the class.
I'm concerned that the build output of the project that builds the custom task needs to copy its output assembly to some known location so that the other projects can refer to it. What is the proper way of going about doing this?
You're about to walk into a mess here, because Visual Studio is going to lock the custom task Assembly when it's first used, thereby causing any further builds in Visual Studio (i.e. Build > Solution) to fail.
As #stijn commented, you should override the Build target and use another method of building the assembly with the custom task, e.g. using the Csc task or spawning another MSBuild.exe process (see answer to linked question).
The way I decided to go though was to create a separate solution, e.g. "Build Tools", containing the custom task assembly (among other tools), and required that it be built before anything else. I personally find the notion of checking-in prebuilt binaries of this source very unpalatable. If developers didn't want to build the Build Tools solution, they would copy the output from some nightly build.
Unfortunately there isn't an easy way of getting around "hardcoding" a known (relative) location. Using $(SolutionDir) usually works - just not if you try to run MSBuild on the project directly, instead of the solution (VS is a bit more intelligent when you open a project by itself).
I have a build process (let's call it the "engine") that has been using a command line call to Visual Studio's devenv.exe to build a project. I have known for some time that VS is just building with MSBuild, so I finally got around to updating the engine to use MSBuild directly. However, I'm finding a strange anomaly with MSBuild.
For the sake of discussion, there's projects A, B, C, and D. Project A is the main project I'm building, a web app, that depends (through project references) on the other 3 projects. When built manually in VS, A\bin is populated with assemblies. When built in the engine with devenv.exe A\bin is again populated with the expected binaries. When built in the engine use MSBuild, A\bin contains nothing. However, B\Release\bin, C\Release\bin and D\Release\bin contain their binaries as they did using the former 2 build methods.
This happens with just a single project as well. The problem doesn't appear to be related to dependent projects.
I have attempted to explicitly set the MSBuild OutDir property, but it doesn't appear to have any affect.
I have run builds with diagnostic output on and can't see anything obvious (granted, there is a LOT there so it's possible I have yet to find something significant).
I've also been trying to figure out how to see the command line call to MSBuild that VS is making when run from devenv.exe but I can't seem to find it.
I have looked at several other SO posts (here and here) but they aren't the same problem.
Anyone have an idea of what this could be or where else I could look for an answer or more diagnostic information?
EDIT 1: The arguments pattern used for the call to MSBuild looks like this:
/nologo /target:Compile /property:Configuration=%%BUILDCONFIG%% /maxcpucount
/property:OutDir=%%OUTDIR%%\bin\ /verbosity:diag /detailedsummary "%%PROJPATH%%"
The lower half of that shows my attempt to force the output directory as well as the enhanced output to show more details of the process. Build engine code replaces with "%%TOKEN%%" items with the appropriate replacement values for the project being built.
EDIT 2: After more research and looking into suggested provided, I've decided to abandon the effort to use msbuild instead of devenv. It seems there is a lot more going on under the hood of devenv in preparation its own call to msbuild and I could likely break something else going on if I don't fully understand the entrance in msbuild. I did try to see if the call to msbuild from devenv is logged, but it doesn't seem to be. I've considered building a dummy msbuild app to just dump the command going into it and temporarily swap out the actual msbuild to generate this diagnostic information, but that's more effort than it's worth at this point. The performance gain isn't so great that it's worth pursuing further for now.
I would look at the Output path on the build tab of your project properties. There are more than few differences when using MSBuild and when using Visual Studio (Even from the command line). It could be you have A configured differently than B,C,D and synching A to the rest will make it work. Also, if you plan to build the projects individually, not as a solution make sure you don't use Solution Level macros that won't be available to the project file on it own.
You are supposed to set OutputPath instead of OutputDir.
Since you already used /verbosity:diag, why not redirect the output to a text file and carefully analyze where csc.exe (or another compiler in use) stores the binaries? That's quite simple and informative for you to learn how MSBuild works under the hood.