Build/Test Issues

File not copying

Started by strike2867 on 15,449 views

File doesn't seem to copy correctly during build. When using the Visual Studio Test Explorer the test passes and the file is copied correctly, but NCrunch doesn't copy it and the unit test fails. In the test project file is declared as

<ItemGroup>
<Content Include="..\SECFillingsTool\Scripts\citationinfo.js">
<Link>citationinfo.js</Link>
<CopyToOutputDirectory>Always</CopyToOutputDirectory>
</Content>

SECFilingsTool is the project being tested.

I understand I can place it elsewhere or compile it as part of the assembly, but would be nice if this worked like Visual Studio's unit test runner.
Hi, thanks for reporting this issue.

Can I just confirm a few things about your setup? This will help me to reproduce and hopefully solve the issue:

- Is this .js file included in your test project, or a project that is referenced by your test project?
- Does your code expect to find the file inside the bin\debug directory of the test project, or is it looking underneath the bin directory of a project under test?
- Are you making use of the Copy referenced assemblies to workspace setting for any/all of your projects?


Thanks!

Remco
Remco wrote:Hi, thanks for reporting this issue.

Can I just confirm a few things about your setup? This will help me to reproduce and hopefully solve the issue:

- Is this .js file included in your test project, or a project that is referenced by your test project?
- Does your code expect to find the file inside the bin\debug directory of the test project, or is it looking underneath the bin directory of a project under test?
- Are you making use of the Copy referenced assemblies to workspace setting for any/all of your projects?


Thanks!

Remco


The actual file is included in the project I'm referencing. The code I pasted was how it is included in the test project. If you create a project with a sample file, then create a test project and modify the test project file with the code I posted earlier you should be able to get the exact way I'm referencing this file.

I wasn't familiar with that copy referenced assemblies to workspace, I have whatever the default setting is
I've built a small test environment making use of a file in the same way as above, but strangely, it seems to work without problems for me when attempting to find the file in the same directory as the test assembly. Would you be able to show me how you are looking for this file? I'm wondering if there may be another dimension to this.

Can you also confirm which version of Visual Studio you're running?

Also note that you can inspect the workspace being used by NCrunch by right clicking on the project or test, then going to Advanced->Browse to workspace. This can be useful when trying to determine if the issue is in the way the workspace is constructed, or if its related to the way the workspace is being used.
Remco wrote:I've built a small test environment making use of a file in the same way as above, but strangely, it seems to work without problems for me when attempting to find the file in the same directory as the test assembly. Would you be able to show me how you are looking for this file? I'm wondering if there may be another dimension to this.

Can you also confirm which version of Visual Studio you're running?

Also note that you can inspect the workspace being used by NCrunch by right clicking on the project or test, then going to Advanced->Browse to workspace. This can be useful when trying to determine if the issue is in the way the workspace is constructed, or if its related to the way the workspace is being used.



The call to load the file is

if (File.Exists(path))
{
using (FileStream fs = new FileStream(path, FileMode.Open, FileAccess.Read, FileShare.ReadWrite))
{
using (StreamReader rdr = new StreamReader(fs))
{
json = rdr.ReadToEnd();
}
}
}

VS 2012 with all the updates

I can confirm the file is not in the workspace, but it is in the debug bin directory of the project.

When I check what directory ncrunch is looking it comes back with \AppData\Local\NCrunch\5820\19\SECFillingsTool\bin\ (current assembly location) but when running from visual studio it's coming back with \TestResults\Deploy_yuriy.faktorovich 2013-12-22 10_41_03\Out\.

My guess is the step you're missing is that it is in a subdirectory of the project being tested, but inside the project directory of the test project.
Right. I think we're getting closer here.

MSTest in VS2012 has a legacy mode that it activates when making use of a testsettings file. The testsettings file allows the test adapter to perform its own shadow copying, creating the 'Deploy_***** DATE\Out\' directories that are used to run tests. The big drawback of this approach (and one of the likely reasons MS are moving away from it) is that every file used by a test needs to be specifically marked out so that it can be copied to this directory.

These files need to be marked out using either the DeploymentItem attribute, or they need to be marked specifically inside the testsettings file.

NCrunch will detect the existence of DeploymentItem and will enter a compatibility mode wherein it will emulate MSTest's sandboxing and will copy the files in a fairly similar manner.

Unfortunately, NCrunch does not make use of the testsettings file and therefore cannot detect any files that are marked in it.

Is it possible you have this file listed in your testsettings file?
Remco wrote:Right. I think we're getting closer here.

MSTest in VS2012 has a legacy mode that it activates when making use of a testsettings file. The testsettings file allows the test adapter to perform its own shadow copying, creating the 'Deploy_***** DATE\Out\' directories that are used to run tests. The big drawback of this approach (and one of the likely reasons MS are moving away from it) is that every file used by a test needs to be specifically marked out so that it can be copied to this directory.

These files need to be marked out using either the DeploymentItem attribute, or they need to be marked specifically inside the testsettings file.

NCrunch will detect the existence of DeploymentItem and will enter a compatibility mode wherein it will emulate MSTest's sandboxing and will copy the files in a fairly similar manner.

Unfortunately, NCrunch does not make use of the testsettings file and therefore cannot detect any files that are marked in it.

Is it possible you have this file listed in your testsettings file?


While there is a runsettings file, it isn't declared there. But I have found there is a [DeploymentItem(@"SECFilingsTool.Tests\citationinfo.js")] over the test class using the file. Sorry I didn't know about it, I didn't write this test.
Is the path SECFilingsTool.Tests\citationinfo.js valid when applied relative to the directory of your .sln file? I'm just checking this now with my test solution and it still seems to work with NCrunch... hopefully we can narrow down the point of difference.

Do you have many tests that are relying on the legacy MSTest deployment logic? If you have an opportunity to migrate away from it, I think this will save you much trouble both now and in future.
Sorry - I thought I'd also just confirm where the DeploymentItem attribute is declared in your code. You say that this is in the fixture itself - in this do you mean the class declared with [TestClass]? Is there any inheritance involved?
Remco wrote:Sorry - I thought I'd also just confirm where the DeploymentItem attribute is declared in your code. You say that this is in the fixture itself - in this do you mean the class declared with [TestClass]? Is there any inheritance involved?


The full declaration for the test class is

[TestClass]
[DeploymentItem(@"SECFilingsTool.Tests\citationinfo.js")]
public class CitationViewModelTest

no inheritance.
Ok, so somehow, NCrunch isn't detecting this attribute. Can you confirm whether the namespace for the attribute is Microsoft.VisualStudio.TestTools.UnitTesting.DeploymentItemAttribute? Also, is there any chance you could submit a bug report right after you've run the test? Perhaps the log file will contain a clue here.
Remco wrote:Ok, so somehow, NCrunch isn't detecting this attribute. Can you confirm whether the namespace for the attribute is Microsoft.VisualStudio.TestTools.UnitTesting.DeploymentItemAttribute? Also, is there any chance you could submit a bug report right after you've run the test? Perhaps the log file will contain a clue here.


I messed around with that attribute and now can't get the test to fail. I've even rolled back to the version in TFS before I made any changes whatsoever. If it helps, I was using the intuitively run tests based on code I've modified. I've tried closing the solution and opening it again. I can't reproduce the error. Do you have any suggestions to reproduce this? Otherwise I guess close the issue.
Argh! Worst possible scenario. I suspect this is sequence related then. It is probably dependent upon other tests that have been executed before it in the NCrunch pipeline.

I suggest parking the issue until it happens again. There is a high probability that it will come back. If it does, please send through a bug report immediately.

It may also be worth checking to see if you have any other tests that manipulate the file in question in any way. For example, if you have a test that is unexpectedly deleting the file before the failing test executes, this could create a bit of a mess.
Remco wrote:Argh! Worst possible scenario. I suspect this is sequence related then. It is probably dependent upon other tests that have been executed before it in the NCrunch pipeline.

I suggest parking the issue until it happens again. There is a high probability that it will come back. If it does, please send through a bug report immediately.

It may also be worth checking to see if you have any other tests that manipulate the file in question in any way. For example, if you have a test that is unexpectedly deleting the file before the failing test executes, this could create a bit of a mess.


There aren't any lines deleting the file, but if it does come up, I'll try to get you the bug report.

Post a reply

Log in to reply.