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.
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'm evaluating TFS Build 2013 for use in a corporate environment.
TFs itself has been running fine for ages, and today I setup the Build components. No problem so far.
I grabbed a fairly simple project from source and created a manually triggered build definition, using the standard defaults.
I ran a test build and hit an issue straight away with a primary reference. The error in the logs is:
C:\Program Files (x86)\MSBuild\12.0\bin\amd64\Microsoft.Common.CurrentVersion.targets(1697,5): warning MSB3245: Could not resolve this reference. Could not locate the assembly "XYZ.dll".
So a bit of back of background on how we store and use references:
We create a root folder for the solution, inside this goes the .sln file and sub directories for the projects as normal. We then add a "References" folder at this level, which holds all of the DLLs required for the project. These are generally DLLs from other in house code libraries, but also certain 3rd party ones (such as the old Enterprise Library DLLs, and anything else we don't get from NuGet).
Each of the projects that require these DLLs reference this folder (and from inspecting the .proj files I can see the link is stored as "..\References\XYZ.dll" etc. This works fine for local builds and nobody has ever had an issue. The reference folder gets checked into TFS and everybody gets a copy. From what I've read through trying to diagnose our issue, this is a fairly common and accepted way to manage references.
So, the build error that I receive is as above. Basically saying the build target can't find the DLL from the References folder. The log goes on to list all of the places it's tried to find it.
Crucially (it would seem) the first line reads:
For SearchPath "{HintPathFromItem}".
Considered "..\References\XYZ.dll", but it didn't exist.
Furthermore it looks in the Framework folder, various default assembly folders, the GAC and so on, none of which (of course) contains it.
So I'm wondering where I've gone wrong. Have I misconfigured one of the build/drop locations? Is there some other convention for referencing required DLLs (bearing in mind our entire company uses the "..\References" folder setup, or is there something else?
I'm fairly new to TFS Build, but I'm by no means new to TFS or Visual Studio
itself. I've spent about an hour or so Googling without finding anyone experiencing the same issue as me, so any help would be greatly appreciated.
Thanks
UPDATE:
The build agent is configured as follows:
Build Agent- working directory:
D:\BuildAgent\$(BuildAgentId)\$(BuildDefinitionPath)
The build definition "Source Settings" have the (I assume) default values of:
Status: Active | Source Control Folder: $/ProjectRoot | Build Agent Folder: $(SourceDir)
Status: Cloaked | Source Control Folder: $/ProjectRoot/Drops | Build Agent Folder:
The references folder is not explicitly configured here, but when I look in the Build Agent's working directory I can see it:
D:\BuildAgent\1\ClientName\SolutionName\src\Dev\Evolution\Source\SolutionName.Solution\References
If I open VS2013 Command Prompt, navigate to the folder that contains the .sln file (and also the References folder) and run "msbuild d:\path\to\Solution.sln" then it builds successfully with no warnings or errors.
Well it turns out this wasn't a fault with TFS at all...
The problematic DLL, although present in the References folder, was not actually checked into TFS.
Right clicking the References folder in VS (added as a "Solution Folder") and selecting to Add Existing Item, then a check in fixed the issue.
So the References folder was being used as you would expect, in the same way that VS uses it. MSBuild worked locally because I had the file in my local folder, but because it wasn't part of the solution it wasn't with the rest of the source.
In the main project of my VS Solution I have a Resources folder with some required external tools. When building and publishing the solution, I get a .\Resources* with all required files there.
So far so good.
However I have to move some files to the parent directory.
My first attempt was do so with the Post Build Events. It works and does move them the correct folder.
Nevertheless in the publish output they still appear in the Resources folder and I need them in the parent one :/
Is there any way to setup the target output path for resources in Visual Studio?
After some research and experimental, I solved my problem.
Still, here's what I learned in the process.
The first attempt was adding the file to the project root and mark it as a resource. After publishing it worked. But having those files in the project root its lame.
Since I needed some *.exe files compiled in another VS solution, added them as a project reference. Gave it a try and it passed the "Publish" test. But still.. not the best way to do it.
After that, with some scripting and a post-build event, I copied the required files to the correct folder. Works.. but after publishing, they don't appear in the package.
However, there is still a possibility with the Mage tool:
http://msdn.microsoft.com/en-us/library/acz3y3te.aspx
This lead to some promissing experiments, however they ended up helping me realize how limited the MS ClickOnce is, so I decided to try other tools.
Here's a good start to follow:
What alternatives are there to ClickOnce?
I had a similar situation once. I found it became more trouble than it was worth to customize output paths and such in Visual Studio, to the extent that I wanted.
I ended up letting Visual Studio do its own thing with regards to file/project structure, and wrote a post-build script to copy everything that was needed into a final, 'publish-ready' directory.
I then set the execution target in Visual Studio to the new location, so I could run/debug as normal, but with the new folder that was organized how I needed it. Careful, I think this is a user project setting; so other developers will need to do this on their machines too, if they so desire.
I do recall changing some output paths and such to make the post-build script more simple. But changing things like that can lead to annoyances when you add new projects to the solution; you might need to configure them to match. It's all a trade-off :)
Two ideas:
Maybe you could move your resources into another project - a project just for resources - and then set their Build Action to Content and Copy To Output to true. Then reference this new project and build the solution. (This may not work as you want, just an idea).
Why not make your resources embedded resources instead. Keep them all within the Resources\ directory and access them programatically?
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.