Home → Support →

Build problem

• Edit

mjmoore

Mar 14, 2015 @ 10:08 PM

When building my app at Appharbor I am now getting a build error that I don't understand. The application in question is FiddleFlightsBackground and one of the specific commits that is getting the build error is "05bd9e170c9cbac267d466753dc07cb781683369".

The error message that the build log shows is:

C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\WebApplications\Microsoft.WebApplication.targets(182,5): error MSB3030: Could not copy the file "bin\Debug\Log.txt" because it was not found.

The missing file "bin\Debug\Log.txt" is included in my project as content, but not specified to copy to output. On my local machine, when I do the build in both debug and release mode there is no mention of "Log.txt" anywhere in the build output. When deleted the log.txt file from my system and re ran the builds locally under debug and release and they both completed successfully.

So, I don't understand why the build at AppHarbor thinks it needs to copy this file.

1. 1 Posted by mjmoore on Mar 14, 2015 @ 10:58 PM

   

   Ok, I changed the build action for "log.txt" to none and the build now works at AppHarbor.

   I am still confused as to why there was a discrepancy between the local builds and the Appharbor builds before changing the build action value.

   • Edit

2. Support Staff 2 Posted by rune on Mar 15, 2015 @ 03:15 PM

   

   Hi,

   Files that are referenced in your project with the Build Action property set to Content will be copied to your output directory - so if the file isn't found it'll cause an error like this.

   The problem in this case likely is that the log file isn't committed to your repository, so the file isn't found in the input directory when your app is built. You probably have that file locally though, so MsBuild can copy/use it without any issues when you build it yourself.

   The shouldn't really be any reason to reference log files from your projects though. Any reason you don't just remove the reference to the file?

   Best,
   Rune

   • Edit

3. 3 Posted by mjmoore on Mar 15, 2015 @ 04:28 PM

   

   Rune,

   Thanks for your response. As I mentioned in my previous post, I have resolved the issue, so at this point this is just a mental exercise to try and understand what changed to cause this problem to manifest itself. The log.txt file has never been committed to the repository. However, this app had been building fine for many months with the Log.txt file included in the project as "content" with "Copy to Output Directory" set to "Do not copy".

   I have attached the AppHarbor build log and the "FiddleMon.Background.csproj" files associated with commit "66b96819ef467dabf5946be2f9259f0c5a0a780b" which built correctly at AppHarbor. There is no mention of attempting to copy log.txt in the build output even though the project file contains:

   <ItemGroup>
       <Content Include="bin\Debug\Log.txt" />
       <Content Include="SqlScripts\CreateAllTables.sql">
         <CopyToOutputDirectory>Always</CopyToOutputDirectory>
       </Content>
   </ItemGroup
   

   The reason that log.txt is included in the project is that when debugging in Visual Studio it is sometimes convenient to have the log file open for viewing. When the log file is included in the project it makes it very easy for Resharper to find the project to open it for viewing.

   • Edit

4. Support Staff 4 Posted by rune on Mar 15, 2015 @ 06:58 PM

   

   Got it, I think I know what the issue is then. The Content element only copies files to the output directory when MsBuild processes a web application project type (as part of the _CopyWebApplicationLegacy target).

   Your background worker project is a console project, so usually you won't get errors like this when building locally or on AppHarbor, even when the content file is missing. However when inspecting the failing builds I can see that you've configured Azure Webjobs in the background worker project - this essentially transforms your console application to a web project and is built like that. So the reason simply is that the default behavior is modified by the WebJobs specific targets.

   Best,
   Rune

   • Edit

5. 5 Posted by mjmoore on Mar 15, 2015 @ 07:08 PM

   

   Ah, that makes sense. Thanks for solving this mystery. I appreciate your taking the time to look into it. 

   Sent from Outlook

   • Edit

6. Support Staff 6 Posted by rune on Mar 16, 2015 @ 07:58 PM

   

   Great, happy to help!

   Best,
   Rune

   • Edit

7. rune closed this discussion on Mar 16, 2015 @ 07:58 PM.