I currently have one workspace for our 'Mainline' code, and 1 workspace for each branch that we create at the end of each iteration. I am using STS and grails 1.3.6, with no added plugins and a couple of java jar files. It seems like whenever I create a new workspace for a new branch, the branch workspace ends up getting corrupted. I start getting build errors locally revolving around missing hibernate classes such as AbstractEntityPersister. I am working in a Windows 7 environment.
My question is two-fold.
One-Is this problem likely related to a caching issue? Theoretically the build grails dependency jars should be the same between the workspaces, so I don't know why one workspace would have problems and one wouldn't
Two-What is the best way to debug said problem? Currently the only thing I'm going on is the Problems view and then comparing the two workspaces as best I can.
By default, grails uses "$USER_HOME/.grails/grailsVersion/projectName" as a working directory, so having two projects with the same name and same grails version will cause you several headaches.
Take a look at the docs below, you'll want to set 'projectWorkDir' in each project BuildConfig to prevent interferences.
http://grails.org/doc/latest/guide/commandLine.html#buildCustomising
Do your project working directories have the exact same name?
Grails creates a project cache folder in $USER_HOME/.grails/<grailsVersion>/projects/<basedirname> which contains compiled plugins and scripts. Even running grails clean does not wipe out these directories.
It's likely that the two projects that have the same name are updating files in this folder simultaneously. In theory this shouldn't mess anything up because you're probably not working on the two projects simultaneously, but if you have both open in STS it might be auto building and messing with the automatic reloading mechanism that Grails uses.
I would try to set the working directory in BuildConfig.groovy or override the folder using grails -Dgrails.project.work.dir=work as documented.
Failing this, I would suggest disabling any auto build in STS as Grails itself will compile/reload classes when run-app is running. Also I would try editing your application using a text editor (Sublime Text 2 is fantastic) instead of STS to see if you have the same problems.
I’m using TFS 2012 Build and running into an error
Access to the path is denied
The solution being built contains about 15 projects of which a number are using the Castle.Components.Validator.2.5.0 assembly. I have seen other posts that talk about the TFS Build Access Denied errors, but they generally refer to having simultaneous builds running. In this case only one build runs at a time. Also, the error occurs when the server is restarted or the build has not run for some time.Once a build is run and fails, the next one succeeds and each one after that succeeds again until the build hasn’t been run for a while or the server is restarted. Although we can get around this, it is a manual headache. Here is the error:
C:\WINDOWS\Microsoft.NET\Framework64\v4.0.30319\Microsoft.Common.targets (3513): Unable to copy file "D:\Builds\12\Foo\Check-In Build\Sources\packages\Castle.Components.Validator.2.5.0\lib\NET40\Castle.Components.Validator.dll" to "D:\Builds\12\Foo\Check-In Build\Binaries\Castle.Components.Validator.dll". Access to the path 'D:\Builds\12\Foo\Check-In Build\Binaries\Castle.Components.Validator.dll' is denied.
When looking at the log file you can see that the build is trying to copy the file twice. Because the first one has a lock on the file, the second one fails and thus the build fails. Here is a snippet of the log file that shows what is happening:
2>_CopyFilesMarkedCopyLocal:
Copying file from "D:\Builds\12\Foo\Check-In Build\Sources\packages\Castle.Components.Validator.2.5.0\lib\NET40\Castle.Components.Validator.dll" to "D:\Builds\12\Foo\Check-In Build\Binaries\Castle.Components.Validator.dll".
5>_CopyFilesMarkedCopyLocal:
Copying file from "D:\Builds\12\Foo\Check-In Build\Sources\packages\Castle.Components.Validator.2.5.0\lib\NET40\Castle.Components.Validator.dll" to "D:\Builds\12\Foo\Check-In Build\Binaries\Castle.Components.Validator.dll".
2>_CopyFilesMarkedCopyLocal:
Copying file from "D:\Builds\12\Foo\Check-In Build\Sources\packages\MvcContrib.Mvc3.FluentHtml-ci.3.0.96.0\lib\MvcContrib.FluentHtml.dll" to "D:\Builds\12\Foo\Check-In Build\Binaries\MvcContrib.FluentHtml.dll".
Copying file from "D:\Builds\12\Foo\Check-In Build\Sources\packages\RhinoMocks.3.6\lib\Rhino.Mocks.dll" to "D:\Builds\12\Foo\Check-In Build\Binaries\Rhino.Mocks.dll".
Any help on how to fix this would be greatly appreciated.
As others mentioned, this happens when performing multithreaded builds with a common destination directory and the file copy task happens to encounter a simultaneous conflict with a copy task running for a different project.
Normally this should result in a "file used by another process" exception (which is handled and retried by the file copy task) but sometimes the file operation results in an "Access is denied" exception instead. (I'm still not sure why)
Some suggest that you should "solve the duplication", but I don't see that as being feasible for cases where all the projects need to directly reference a library like log4net.
Obviously one way to prevent the issue is to explicitly run msbuild with /p:BuildInParallel=false or /m:1 or /maxcpucount:1 (or omit the argument entirely) to force single-threaded mode.
However, in TFS 2013, the default build template automatically always passes /m (use all cores) to msbuild, which silently overrides any single-thread setting you can manually pass in. (Determined by my own experimentation and examining diagnostic logs)
Another workaround I attempted was to manually pass /p:AllowedReferenceRelatedFileExtensions=none to msbuild, which prevents all pdb and xml files from being copied from referenced libraries. (Since for a while I only ever saw xml files having this issue.) But then I kept having problems with log4net.dll.
The ultimate workaround that I used was one I discovered by decompiling the source code for Microsoft.Build.Tasks.Copy:
if (hrForException == -2147024891)
{
if (!Copy.alwaysRetryCopy)
throw;
else
this.LogDiagnostic("Retrying on ERROR_ACCESS_DENIED because MSBUILDALWAYSRETRY = 1", new object[0]);
}
If error -2147024891 (0x80070005 access is denied) occurs, the Copy task will check a special variable to see if it should retry. That value is set via an environment variable:
Copy.alwaysRetryCopy = Environment.GetEnvironmentVariable("MSBUILDALWAYSRETRY") != null;
After setting the environment variable MSBUILDALWAYSRETRY = 1 (and restarting the build server), the problem went away. And I also periodically started seeing "Retrying on ERROR_ACCESS_DENIED..." as warnings in the build logs, proving that the setting was taking effect, (instead of the builds merely coincidentally succeeding).
(Note that this environment variable is not well documented, use as appropriate.)
Update: Apparently TFS 2015 no longer overrides your /m:1 with /m (even on legacy/XAML build definitions), which should make /m:1 a valid fix again.
It looks like there are two projects copying the same file. Depending on the timing, they sometimes happen at the same time, resulting in the failure. You have to trace the node id back to find the source project. See http://blogs.msdn.com/b/buckh/archive/2012/01/21/a-tool-to-find-duplicate-copies-in-a-build.aspx for more details and code that may track it down for you.
As Buck Hodges and Nimblejoe have rightly said, this is mostly due to TFS running multiple MSBuild processes by default to build your projects.
You can override it in the build definition in Process -> 3. Advanced -> MSBuild Arguments by adding the MSBuild argument /p:BuildInParallel=false
This can also happen if you have a build agent's folder open.
I also had same problem. I got error messages that related to cannot copy since access to path denied. In my case all my dll's and xml files and so on are place at
D:\TFS\Example\Bin\Debug folder.
I right clicked on Bin folder and clicked Properties and saw that Read-only check box is checked under Attributes.
I un-checked Read only check box and cliked Apply and clicked OK on the new popup that is shown.
I went back to Visual Studio and build my solution which was giving me error messages.
Voilaa.. This time it build successfully without errors.
I donot know whether this is perfect but I did this to solve my issue.
To work around this problem I had to remove the "ReadOnly" flag on the source directory
Then in the build definition set Clean Workspace
to None
Like Ziggler, I solved this problem with building a project by removing the 'read only' property of the bin folder in my project. It is only happening to XML files stored in a /packages/ directory that is common to the solution that contains this project. The 'bin' folder is not checked into source control. I am still stumped as to the root cause of the problem.
I found the same problem which occurred after the build tried to overwrite files in the "Working Directory" it had created in a previous attempt to build. (set in the Agent)
I resolved this by manually deleting the output folder it created (in my case [Working Directory]\Binaries) before attempting the build.
This can be done automatically by changing the Build Definition. Under Process---2.Basic---Clean Workspace set this to the Outputs option
Here's a variation of this problem which I had to deal with:
I couldn't figure out why my build kept failing on an "Access to the path is denied" error, even though I had added things like /p:BuildInParallel=false and /p:OverwriteReadOnlyFiles=true to the MSBuild Arguments of my XAML build. The cause turned out to be a "Post-build event command line" in my Project's properties.
After changing
%WinDir%\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe[SNIP]
/P:Configuration=$(ConfigurationName);[SNIP]
;AutoParameterizationWebConfigConnectionStrings=false
to
%WinDir%\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe[SNIP]
/P:Configuration=$(ConfigurationName);[SNIP]
;AutoParameterizationWebConfigConnectionStrings=false;OverwriteReadOnlyFiles=true
the error went away.
One possible cause is if you have the bin or obj folders for class libraries checked-in into TFS. Deleting the bin or obj folders of the projects from TFS will resolve this issue if that is the case.
I was having this problem and chose to ignore it because I didn't want to sacrifice build performance for the sake of getting rid of some benign error messages by NuGet. However, I seem to have stumbled across a solution while trying to solve another problem, and I think it is related. I think the order of fetching of NuGet packages is related to the build order of projects in the solution. So if this has somehow become disjointed, then NuGet may be the first casualty before you run into build errors where you start getting "Metadata file 'XXX.dll' could not be found" errors which annoyingly require you to build again until the build succeeds (as described here).
So, I believe the solution is to follow the steps described in the accepted answer to the aforementioned question. Or, follow the more comprehensive steps in one of the alternative answers. In other words, disable building of all projects, restart VS, then re-enable building of all projects. This will (normally) resolve build order. And that should hopefully resolve the NuGet issue. Please let me know if this fixes it for anyone.
I had this issue, with TFS 2015.
It turned out to be because the build Agent was running under the default (NETWORK SERVICE) credentials, which didn't have write permissions on the target folder.
Once I'd removed the Agent and reinstalled it with credentials it worked.
It did have me trawling through the logs for a while, checking and unchecking the multi-proc box and even restarting the build server in my hunt.
Check the obvious stuff first...
For me, it was that the build agent wasn't started in an administrator powershell.
MSBuild arguments:- /tv:14.0 /t:Rebuild /m:1 /p:RunCodeAnalysis=false /p:TreatWarningsAsErrors=false /p:OverwriteReadOnlyFiles=true /p:BuildInParallel=false /p:AllowedReferenceRelatedFileExtensions=none
strong text
Set false to Clean workspace
Go to build agent and remove read only from mapped folder.
as a lot of people have already stated before, this happens when building projects in parallel. Project A and B both referencing 3rd Party Library C (Copy Local) will cause this when they are build at the same Time - side by side.
The real problem is, that TFS Build 2012 and below are configured that when building a solution, the whole output of the solution is copied to a single folder. Thats where the pains of parallel builds are having their origins.
Since TFS 2013 you can easily solve this by setting the "Output location" in the build definition to "PerProject". This forces the build services to behave like a local msbuild run where the setings regarding the output locations are read from the corresponding project files. So the output is written to the bin folders under each project.
For TFS 2012 and below this article (+linked articles) will help you getting the same result as with TFS 2013:
http://blog.stangroome.com/2012/05/10/override-the-tfs-team-build-outdir-property-net-4-5/
I resolved a very similar issue by closing all open instances of Visual Studio, re-opening the solution and building it again.
When I open a solution for the first time after it has been downloaded from TFS, it (Vs2010) is unable to find the NuGet.targets file.
I've checked TFS and it's marked as downloaded, and it exists on the file system.
If I try to open the solution directly from TFS again, it suddenly works.
I feel this is the reason why my automated builds are also failing.
Has anyone come across this issue before?
Ran into this Friday and on another machine today.
For the machine on Friday I copied the .nuget directory, since I didn't have one.
For the machine today it had the .nuget directory and copying it from another machine didn't resolve the issue. Opening it from TFS's Source Control Explorer didn't work either.
We then followed the steps on Opening project in Visual Studio fails due to nuget.targets not found error (enable Package Restore on the solution) and it worked without issue.
Hadn't run into this before last week, and it's just one project of many, with none of the others having this problem.
When Visual Studio downloads solutions from TFS (double click sln file in solution explorer) it appears to download files one by one and load them up. Unfortunately it seems to try opening project files before it downloads the .nuget directory, which is why it can't find the file. The last thing it appears to do is download that file, which explains why it is on disk but gave the error. If you reopen the solution it's already there and works fine.
When TFS Build server downloads a solution to build, it does so on the solution directory instead. Which means it will get the .nuget directory before it tries to build so it shouldn't cause issues on the build server.
I believe this is a bug in Visual Studio, it really should download all the solution items first. Although it would be nice if it had the same behaviour as TFS Builds.
A work around for this issue is to get latest on the solution folder before you open the solution for the first time. Not ideal but it works.
I'd also suggest logging a bug with either the nuget or visual studio team, however I suspect they're probably already aware of it.
I had this problem trying to run through the tutorial at http://www.windowsazure.com/en-us/develop/net/tutorials/multi-tier-web-site/2-download-and-run/
Turns out the zip file the source code was in extracts into a folder containing commas, which I don't think msbuild liked. Moving it into a more safely named directory helped.
Try these steps
Install Nuget.
Right click on the solution and select "Enable NuGet Package
Restore".
Click Ok on the warning.
Close and re-open the solution.
I'm using ant as my primary builder for a flex project in IntelliJ. Every time I build, IntelliJ runs the code analysis tool and finds a bunch of errors in my build file, which pops up the "Messages" window every time. Actually, the errors that it finds are complaining mostly about properties which are defined in a separate file, which it doesn't actually parse when running the analysis.
Edit: Additionally, I am making use of ant tasks which generate properties on the fly, which IntelliJ is unaware of.
Is there any way to turn off file inspection for ant build files during the build process?
That sounds weird. IDEA on the fly inspections which you get while editing the build.xml file should not pop-up when you actually build the project unless they are really errors and are reported by Ant to IDEA while the build file is executed.
IDEA can perform additional validation and report errors on Make for certain components (see Settings | Compiler | Validation), but it doesn't include Ant build files and is not triggered when you just run the Ant target.
If you don't want to see warnings from the Ant Messages Window, you need to toggle off the "Show All Messages" button.
If you don't want IDEA to analyze your build.xml file for errors, click the Hector icon in the status bar and disable the inspections per file by changing the highlighting level from the Inspections to Syntax.
Clarify the problem if it's not the case (knowing IDEA version would be also useful).
Does the .properties file exist, and is it in your CLASSPATH? IntelliJ is very smart about figuring that stuff out. When IntelliJ complains, I usually assume that I'm making a mistake. That posture usually gets me to a solution pretty quickly.
You can disable Ant plugin altogether. IDEA becomes quite slow on large Ant builds, so found this to be of help:
Crtl+Alt+S (for settings) -> Plugins -> Ant Support (uncheck)
I'm noticing some solutions in Team Foundation Server 2008 won't build completely. As in, some number of the projects in the solution succeed but then one fails. The particular failing project says I’m missing an assembly reference. But I'm not - the project has the reference. It builds fine on my PC. I'm looking at the .csproj file that the build agent pulled down and it has the reference, too (it's line-for-line identical to the project I'm building).
The reference in question is to another project in the solution. At first I thought it wasn't building projects in the right order but the build log is telling me that it did (i.e., the project which the reference is in reference to built successfully). So my guess is that somehow on this project (and I’d say about 10-20% of the projects I’m having it build are failing) it’s looking at the wrong folder for assemblies, but I have no idea.
Has anyone ever seen this before?
I did have one Solution which was building things in the wrong order and some Googling seemed to indicate that this was an occasional side-effect of converting a VS2003 SLN file to a VS2008 SLN file (and it was happening in Visual Studio as well), so in that case I made a new SLN from scratch, checked that in "on top" of the problematic one, and it worked fine. But I tried that in the problem above and it didn’t make a difference.
I've seen it on multicore machines where the project dependencies haven't been setup correctly, meaning that tfs starts a project compiling before it's dependencies are finished compiling.
At first I thought it wasn't building projects in the right order but the build log is telling me that it did (i.e., the project which the reference is in reference to built successfully).
Define "built successfully." In particular, make sure the CoreCompile target was invoked and ran to completion. I've seen cases where a different target on the referenced project was built, but that target was insufficient to generate the output the dependent project needed. For example, a web project that includes a Silverlight control will call the GetXapOutputFile target on the Silverlight project -- which is fine & dandy, but it's no replacement for CoreCompile.
If this clue isn't enough to resolve your issue, you should probably post a link to the log and/or the msbuild makefiles.