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.
Related
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.
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 have a long-time-to-build (setup) project in a Visual Studio 2010 Solution. It is set not to build in the Solution configuration. That way, when a developer builds locally they are not burdened with waiting for the setup to compile in Visual Studio.
However, I am looking for a way to change the configuration in tfsbuild or msbuild files so whenever things are built on the server, the setup project is always built, regardless of what the setting might be when a developer checks in their solution. TFS 2008 is the source control system but just a plain Server 2008 (with devenv fully installed) is the build server.
All clues appreciated.
Thanks.
I would suggest creating a new configuration in your solution, named e.g. Release_Setup, that way you have seperate configurations for developer and setup build (note that developers can choose that config and build everything locally if they so choose, which is quite nice when all Build agents are busy and you want to check that everything's fine).
In Solution Properties->Configuration Properties->Configuration you can even tell it to build the normal Release Configuration and still choose which projects to build and which to exclude.
Hope this helps. I haven't actually tested this, so please try it and comment back if there are any problems or this doesn't solve your specific question.
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 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