I am having an issue with building a project, with SonarQube integrated, on TFS 2015.
When I build this project without SonarQube, it builds fine. However, when SonarQube runs alongside this build, one of the project files fails to compile (specifically, it's a unit test project). I get the following error:
D:\Builds\....\Project\.sonarqube\bin\targets\SonarQube.Integration.targets (235, 0)
Could not write lines to file "D:\Builds\.....\.sonarqube\out\\f_AnyCPU_Release_0213\FilesToAnalyze.txt".
The process cannot access the file 'D:\Builds\.....\Project\.sonarqube\out\f_AnyCPU_Release_0213\FilesToAnalyze.txt'`
because it is being used by another process.
[D:\Builds\.....\Project\\src\Apps\Solution\obj\Debug\Fakes\spi\f.csproj]
If anyone can offer some hints as to why this is happening, it'd be much appreciated. I've tried recreating this error with a few projects that I've written but it doesn't seem to happen. It might be specific to the project.
Related
For one of our build scripts (TFS 2013), when we run it manually or during Check-In (Continuous Integration trigger), the build script is not picking up the latest code changes. We looked in the logs and it does have the correct changeset number for the impacted files (in this case .vb files). We tried with several different .vb files. We also tried recreating the build script from scratch to no avail. We have several other build scripts for similar web applications that have no issues with the same build settings. This project builds fine. We set the Clean Build to True. Configurations is set to "Any CPU|Release". Output Location is set to SingleFolder. Build Template is set to TfvcTemplate.12.xaml. Any thoughts or suggestions would be appreciated.
So, after a bit of kicking the tires we figured it out. We had the actual compiled .dll in this case checked into TFS. Hence, the build server would grab the old version that was checked in versus compiling the project on the fly. We removed the .dll from source control to resolve the issue.
I am really new to TFS 2010 automated builds.
I am trying to setup an automated build for a project I am working on. Locally if I build the project it compiles as I expect it to without any errors.
If I trigger my build definition the build fails telling me that one of my .cs files is missing a namespace for a referenced project.
I have checked the reference and it's set to copy local, is there another reason why my build server doesn't think that the .dll is there?
Any pointers would be great!
My guess is that you are referencing a DLL that you have on your local machine, but that doesn't exist on the build server. My suggestion is looking at the build server build log and looking for any build warnings about unable to find references.
Chances are you need to add the DLL's to TFS and update the project references to reference the relative path in the source tree.
We've just set up our first Build Agent with TFS to run unit tests on a separate server from our main build. This will be great but we have an error that doesn't seem to have a good answer:
DLL has already loaded from a different location. It cannot be loaded from a new location within the same appdomain.
The DLL is of course a specific library within out project.
Anyone have experience with this issue?
Thanks!
It turns out we were using the wrong build configuration. It was defaulting to a release build and this build had a requirement to run unit tests that were not being compiled.
Once we changed to a dev build with all of the projects included it worked perfectly.
All is well.
We have a build running on a TFS2008 build server and one of the builds has started failing. It looks as if the aspnet_compile step of the Web Deployment project (wdproj) has stopped producing the App_Global.asax.compiled file.
After a few builds it starts to work again, until a few builds later, the problem is back. If I run the tools manually, it works fine.
It is occuring on all the branches with the module, and not code changes have been made that is common to all the modules. The problem exists on both build servers. I've compared the build directory structures for a successful and failing build, and they only differ by the file above (and the next step, which relies on the App_Global.asax.compiled file (this is the aspnet_merge step))
Any ideas?
Turns out the most likely culprit is NTFS compression… weird
I am attempting to use CI on a Branch of one of my TFS projects. MSBuild only fails when I try to use a Branch. I point the same Build at the "trunk" project it works fine.
The error I receive from the build log:
Task "Label"
Label TeamFoundationServerUrl="http://TFSServer:8080/"
BuildUri="vstfs:///Build/Build/6763"
Name="Test_SF_20090619.1"
Scope="$/MyProject" Recursive=True
Comments="Label created by Team Build"
Version="BuildServer3D143_66"
Child="Replace" Files="$/" C:\Program
Files\MSBuild\Microsoft\VisualStudio\TeamBuild\Microsoft.TeamFoundation.Build.targets(812,5,812,5):
error : No matching items found in $/
in your workspace.
Done executing task "Label" -- FAILED.
Done building target "CoreLabel" in project
"TFSBuild.proj" -- FAILED.
I believe this error is being caused by a lack of source files getting copied to the Build server.
Get task excerpt from build log:
Task "Get"
Get TeamFoundationServerUrl="http://TFSServer:8080/"
BuildUri="vstfs:///Build/Build/6768"
Force=True Overwrite=False
PopulateOutput=False Preview=False
Recursive=True Version="C204806"
Workspace="BuildServer3D143_66"
Done executing task "Get".
This is a full build. There should be about a thousand files listed in the GET.
General Information
TFS 2008
Visual Studio 2008
Established build server (been
running builds for the last year)
Project being branched is a ASP.NET
web stie (2.0 Framework).
Full Build Params
/p:SkipClean=false
/p:SkipInitializeWorkspace=false
/p:ForceGet=true
/p:IncrementalBuild=false
/p:IncrementalGet=false
note: I know IncrementalBuild is redundent but I just wanted to be sure.
Questions:
Are there restrictions on builds off a branch?
Any idea why MSBuild fails to pull files from the branch workspace?
If it's for CI then you're most likely doing an Incremental Get. TFS will only bother to get files it thinks have changed since its last get - e.g. if you delete any files from your server, it will still think you have those files so it won't get them again. In this case you'll need to run the build once with the incremental properties turned off so that it forces a full get of the source. You can do this by overriding the properties in the MSBuild command line box in the Queue Build dialog with:
/p:IncrementalGet=false;ForceGet=true
Another possibility that springs to mind is that the Label task is confused by your branch. It may be that your workspace is set up incorrectly, so check that you're mapping in everything it needs.
I had two issues in this case.
First, the branch security did not give rights to the build service account. I had restricted the branch to our team's Tech Leads and Release Engineers. The build service account needed access as well. What tipped me of was while searching the internet I stumbled upon a posting by someone who had made the same mistake.
The second issue was a little more involved. While cleaning up my build project file, I removed the following section.
<SolutionToBuild Include="$(BuildProjectFolderPath)/../../_stage/MyProject/MySolution.sln">
<Targets></Targets>
<Properties></Properties>
</SolutionToBuild>
Which worked fine on projects I had already built at least once, but if this was a new build, that had not copied source files to the build server, then there would be no files and the build would fail.
Some of you may wonder if my other builds were working either, after all wouldn’t they have old build files. Yes, but I had targets defined that did all the work I actually cared about. So the SolutionToBuild is a little frivalous.