Welcome Guest! To enable all features please Login or Register.

Notification

Icon
Error
NCrunch continually failing with "process cannot access the file"
Options
Previous Topic Next Topic
bdukes
#1 Posted : Thursday, December 1, 2011 10:14:43 PM(UTC)
Rank: Member

Groups: Registered
Joined: 6/15/2011(UTC)
Posts: 10
Location: St. Louis

Was thanked: 2 time(s) in 2 post(s)
Every time I make a change to my main project, I lose code coverage in the project, because the NCrunch build fails with the following error:

Quote:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets (3238): Unable to copy file "obj\Release\MyProject.dll" to "..\..\..\bin\MyProject.dll". The process cannot access the file '..\..\..\bin\MyProject.dll' because it is being used by another process.


Making changes in the test project don't seem to cause an issue. I'm working in a web application project, which builds into the website's bin folder (the project doesn't contain the entire website, just one part of it).

If I click the Resynchronize button it'll work again, but as soon as I make a change, NCrunch is gone until I resynch again.

I'm using 1.35b
Back to top
WWW
Remco
#2 Posted : Thursday, December 1, 2011 10:50:35 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,140

Thanks: 959 times
Was thanked: 1290 time(s) in 1196 post(s)
Are you running any interesting integration tests in your solution that run code across multiple processes? Or are you using any custom/specialised build frameworks or build steps that launch background processes?

Also, are any of your projects making use of the CopyReferencedAssembliesToWorkspace setting? (i.e. have it turned on).
Back to top
bdukes
#3 Posted : Thursday, December 1, 2011 10:55:57 PM(UTC)
Rank: Member

Groups: Registered
Joined: 6/15/2011(UTC)
Posts: 10
Location: St. Louis

Was thanked: 2 time(s) in 2 post(s)
Both projects have CopyReferencedAssembliesToWorkspace set to false.

We do run Style Cop when we build the project
Quote:
<Import Project="$(ProgramFiles)\MSBuild\StyleCop\v4.6\StyleCop.Targets" Condition="Exists('$(ProgramFiles)\MSBuild\StyleCop\v4.6\StyleCop.Targets')" />


The only other thing that would even begin to be interesting is Code Analysis, which I had some issue with (don't remember exact details now), and so switched to using Release build for NCrunch to avoid that (but just verified that I still see the issue above when I switch back to Debug).
Back to top
WWW
Remco
#4 Posted : Friday, December 2, 2011 12:28:05 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,140

Thanks: 959 times
Was thanked: 1290 time(s) in 1196 post(s)
Ok - I think this might be an internal problem with the engine then ... it's possible that the engine incorrectly thinks that the workspace for your main project isn't being used. I thought that these issues were resolved in 1.35, but it may be that something to do with your solution is surfacing an edge case. Would you be able to submit a bug report using the NCrunch menu? This will help me trace through the engine workings to figure out why it's behaving strangely.

Thanks!

Remco
Back to top
bdukes
#5 Posted : Friday, December 2, 2011 3:47:36 PM(UTC)
Rank: Member

Groups: Registered
Joined: 6/15/2011(UTC)
Posts: 10
Location: St. Louis

Was thanked: 2 time(s) in 2 post(s)
Bug report submitted, thanks!
Back to top
WWW
Remco
#6 Posted : Friday, December 2, 2011 10:41:26 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,140

Thanks: 959 times
Was thanked: 1290 time(s) in 1196 post(s)
Thanks! I'll take a look at it and get back to you.
Back to top
Remco
#7 Posted : Monday, December 5, 2011 8:08:35 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,140

Thanks: 959 times
Was thanked: 1290 time(s) in 1196 post(s)
Ok - according to the bug report, NCrunch is building on top of the locked file because it isn't aware of anything that's using the process. I think the next step would be to establish whether NCrunch is responsible for holding the lock, or if it's something else doing this. Would you be able to try the following?

1. Modify your project in such a way that it consistently gives you the error
2. Open task manager or process explorer
3. Terminate all nCrunch.TaskRunner executables
4. Right click the affected component in the NCrunch tests window, then click 'Rebuild'

Does the rebuild action work?
Back to top
bdukes
#8 Posted : Thursday, December 8, 2011 8:19:00 PM(UTC)
Rank: Member

Groups: Registered
Joined: 6/15/2011(UTC)
Posts: 10
Location: St. Louis

Was thanked: 2 time(s) in 2 post(s)
Yes, the rebuild works after terminating the three nCrunch.TaskRunner processes.

Hope that helps!
Back to top
WWW
Remco
#9 Posted : Thursday, December 8, 2011 9:08:07 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,140

Thanks: 959 times
Was thanked: 1290 time(s) in 1196 post(s)
Ok - that confirms that this is a dependency problem inside NCrunch. These problems can often be quite tough to analyse/reproduce because of the number of moving parts, so I apologise in advance if I need to barrage you with questions :)

Are you able to give me a short summary explaining the dependencies between your components? Something like 'Single test project depends on Web project, which depends on 3 other projects, which all depend on one common project' would be great. I can then test for a similar project with the same structure to try and recreate the issue.

What is the running time of your longest test in the solution? Does this test cover the main web project?

If you set turn on the LogToOutputWindow and leave it set to summary as soon as you start working, do you see anything interesting appear in the log file in the lead up to the problem occuring?
Back to top
bdukes
#10 Posted : Thursday, December 8, 2011 10:07:07 PM(UTC)
Rank: Member

Groups: Registered
Joined: 6/15/2011(UTC)
Posts: 10
Location: St. Louis

Was thanked: 2 time(s) in 2 post(s)
No problem, I'm happy to answer whatever I can.

Single test project depends on a single web application project, which has no other direct dependencies. Web application project lives inside of an IIS web site, and the project output goes into that website's bin folder. This is a module for a DotNetNuke site, so the website is at c:\web\project.dev, and the web application project is in c:\web\project.dev\DesktopModules\Company\MyProject, with assemblies building to c:\web\project.dev\bin.

Longest running test takes over 3 seconds (and is over the web project).

The only thing that is logged is the error itself:
Quote:
[15:54:30.6972-BuildTask-121] ERROR (Compilation): Papers Archive: C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets (3238): Unable to copy file "obj\Release\MyProject.dll" to "..\..\..\bin\MyProject.dll". The process cannot access the file '..\..\..\bin\MyProject.dll' because it is being used by another process.
Back to top
WWW
Remco
#11 Posted : Thursday, December 8, 2011 11:18:31 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,140

Thanks: 959 times
Was thanked: 1290 time(s) in 1196 post(s)
Thanks - is the web project itself set to output files using an absolute path? Would you be able to show me the msbuild XML where the output path is specified?
Back to top
bdukes
#12 Posted : Thursday, December 8, 2011 11:24:41 PM(UTC)
Rank: Member

Groups: Registered
Joined: 6/15/2011(UTC)
Posts: 10
Location: St. Louis

Was thanked: 2 time(s) in 2 post(s)
The output path (and all paths so far as I can tell) are relative in the project file. Here are the configurations with the OutputPath elements:
Quote:
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
<DebugSymbols>true</DebugSymbols>
<DebugType>full</DebugType>
<Optimize>false</Optimize>
<OutputPath>..\..\..\bin\</OutputPath>
<DefineConstants>DEBUG;TRACE</DefineConstants>
<ErrorReport>prompt</ErrorReport>
<WarningLevel>4</WarningLevel>
<RunCodeAnalysis>true</RunCodeAnalysis>
<CodeAnalysisRules>
</CodeAnalysisRules>
<CodeAnalysisRuleSet>Correctness, Design, Globalization, Security, and WebForms MVP.ruleset</CodeAnalysisRuleSet>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
<DebugType>pdbonly</DebugType>
<Optimize>true</Optimize>
<OutputPath>..\..\..\bin\</OutputPath>
<DefineConstants>TRACE</DefineConstants>
<ErrorReport>prompt</ErrorReport>
<WarningLevel>4</WarningLevel>
<RunCodeAnalysis>false</RunCodeAnalysis>
<CodeAnalysisRuleSet>Correctness, Design, Globalization, Security, and WebForms MVP.ruleset</CodeAnalysisRuleSet>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Trial|AnyCPU' ">
<DebugType>pdbonly</DebugType>
<Optimize>true</Optimize>
<OutputPath>..\..\..\bin\</OutputPath>
<DefineConstants>TRACE;TRIAL</DefineConstants>
<ErrorReport>prompt</ErrorReport>
<WarningLevel>4</WarningLevel>
<RunCodeAnalysis>false</RunCodeAnalysis>
<CodeAnalysisRuleSet>Correctness, Design, Globalization, Security, and WebForms MVP.ruleset</CodeAnalysisRuleSet>
</PropertyGroup>
Back to top
WWW
Remco
#13 Posted : Friday, December 9, 2011 12:54:39 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,140

Thanks: 959 times
Was thanked: 1290 time(s) in 1196 post(s)
Ok - I think I may have this figured out.

It looks as though NCrunch isn't properly considering the extent of the upwards referencing for your output path when it creates a workspace for your web project. Because the output path is 3 levels up from the workspace root, it's trying to reuse the same output directory between multiple workspaces (thus it trips over with access denied).

I'll see what I can do about getting a fix introduced. Meanwhile, you should be able to work around this issue by specifying an alternative output path for NCrunch builds. In your .proj file, replace all instances of the XML:

<OutputPath>..\..\..\bin\</OutputPath>

With:

<OutputPath Condition="$(NCrunch) != '1'">..\..\..\bin\</OutputPath>
<OutputPath Condition="$(NCrunch) == '1'">bin\</OutputPath>

I'm keen to hear if this does the trick!
Back to top
bdukes
#14 Posted : Friday, December 9, 2011 3:03:02 PM(UTC)
Rank: Member

Groups: Registered
Joined: 6/15/2011(UTC)
Posts: 10
Location: St. Louis

Was thanked: 2 time(s) in 2 post(s)
That seems to have fixed the issue, thanks!
Back to top
WWW
Remco
#15 Posted : Friday, December 9, 2011 7:32:07 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,140

Thanks: 959 times
Was thanked: 1290 time(s) in 1196 post(s)
Good to hear! Thanks for reporting it.
Back to top
Remco
#16 Posted : Monday, December 19, 2011 8:08:29 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,140

Thanks: 959 times
Was thanked: 1290 time(s) in 1196 post(s)
I've implemented a proper fix for this in 1.36b, which has just been released. Hopefully we won't see this one again!
Back to top
bdukes
#17 Posted : Monday, December 19, 2011 8:30:37 PM(UTC)
Rank: Member

Groups: Registered
Joined: 6/15/2011(UTC)
Posts: 10
Location: St. Louis

Was thanked: 2 time(s) in 2 post(s)
Looks like that's fixed it for me, thanks!
Back to top
WWW
1 user thanked bdukes for this useful post.
Remco on 12/19/2011(UTC)
Users browsing this topic
Guest
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.

YAF | YAF © 2003-2011, Yet Another Forum.NET
This page was generated in 0.099 seconds.
Trial NCrunch
Take NCrunch for a spin
Do your fingers a favour and supercharge your testing workflow
Free Download