IgnoreAttribute in WinRt

Dear NCrunch,

If you have the following code in a WinRT project it breaks NCrunch but not MSTest:

[AttributeUsage(AttributeTargets.Property)]
public class IgnoreAttribute : Attribute
{
}

The results read: "NCrunch was unable to retrieve a meaningful result from this test due to an unexpected error - was the execution process terminated?". Those are the results for every single unit test.

What's interesting is that the code above does not even need to be in a project that is being referenced from your tests. The attribute does not even need to be in use.

Furthermore the above code seems to poison the NCrunch session such that when NCrunch finds it it will continue to fail indefinitely until you close and reopen Visual Studio (making it all the more challenging to track down).

I have put together a sample project in a folder in Dropbox called "For Remco" in a project called NCrunchWin8Fail.sln.

There's an easy enough workaround for me (rename it), but it took me an hour and a half to track that down, so hopefully it helps someone else, somewhere.

Best,
Lee

Hi Lee -

Thanks for sharing this issue, and the project to reproduce it. I'll take a look and will see if I can arrange a fix for it. I'm sorry for the time this has cost you.


Cheers,

Remco

Hi Lee -

I haven't had any luck in getting NCrunch to bug out on the test solution you've provided. Does it fail for you consistently on this solution?

Well, it had been consistent. I just reopened the project and it passed. Then I hit "Resynchronize, rebuild, and and rerun all tests (Reset)" and it started failing again. I'm running NCrunch 2.5.0.7 in Visual Studio 2013 Ultimate Edition.

I've just tried many resets ... but still no luck here.

I'm not aware of anything in NCrunch that would struggle with an attribute like this. It's namespace is not under anywhere that the test runner would care about. This is very worrying because it suggests instability in the app container ... something that may be extremely difficult to track down. I hope that this is an isolated case for you.

If you see this happen again, can you submit a bug report and check your event viewer for any error information? Hopefully the log will provide something telling.

Ok, not terribly consistent. I reopened the project and it passed. I hit Resynchronize and it passed again. I hit Resynchronize a second time, and then it failed.

I've submitted a bug report. I needed to hit Resynchronize several times this morning to reproduce. It doesn't appear to be a multi-threading issue because I set Allow parallel test execution = false. Could the inconsistency be due to the order that NCrunch runs the test?

Anyway, I set verbosity to detailed. I'd include the whole log, but the max message length of this forum seems to be pretty small. The following line looked pretty interesting:

[09:12:50.5809-LocalTestExecutionTask-28] ERROR (Internal): System.Exception: error 0x8007000E: The Visual Elements extension failed while processing the Notification element.
at #=q6wmHmyjsRo5GYkm_ZunVW0a0z3aG_Qeq6RjtDffqcST6dDL1_l0KZbVRGEZ8tjR0.#=qFFwAgEpd$NCaQQyRFCWvEQ==(FilePath #=qUV7UBuDOOGGsNikud5BXQ4cPxxMKWAa1CwUWYIAgYbA=)
at #=q84RA0rhn9ltGGE52IL_Qog3PAc3RTfh_s49tpCxY$hH5bXmfYAkdV0EaQyMLtwET.#=q_vbx9FcAxpNjzuVhXasF16RbY_3BBjaNeELrZaX7$2Y=(DirectoryPath #=qFyVJTS45xQ82$5J0QDeRNR115N6n96QrlukMWlAqpIA=, BuildOutput #=q9OSCSi_V$uXcGeeQDbjl_Q==)
at #=q84RA0rhn9ltGGE52IL_Qog3PAc3RTfh_s49tpCxY$hH5bXmfYAkdV0EaQyMLtwET.PrepareProcessEnvironment(List`1 #=qmHkmQwDtDko2J4tDDC2mkw==, ProcessLoadParameters #=q1SnDhTxrdKY2imS$KLbKMw==, FilePath[] #=qlVWkyjcdRdQNogiHAr6XwOP4S6hcZCQu$$FY34u9tMU=, IList`1 #=qBCF$5E9BxReYRV19FU3RBJbMp0OC6MHbMSM4M2Xe84c=)
at nCrunch.Core.TestManagement.TestRunnerProcess.#=q8dYIxoyBsCfnXG9KlXT_Sw==(Boolean #=q1dmlg4UtEPB9BZPF_06$xQ==, FilePath #=qCe6byFqmR5dgUTi1XjrtH04Mza0m1UsdYPY6x$KDsLI=, GridClientId #=q_0dhjTvYhaC_umYBSzTPPA==)
at nCrunch.Core.TestManagement.TestRunnerProcess.LoadTestRunnerProcessForProject(SnapshotComponent snapshotComponent, IList`1 componentsInProcess, TestFrameworkDescription primaryTestingFramework, Boolean useNewProcess, FilePath solutionFilePath, GridClientId client)
at nCrunch.Core.Processing.TestExecutionTaskLogic.DoProcessTaskAndReturnSuccessFlag()
at nCrunch.Core.Processing.TaskLogic.ProcessTaskAndReturnSuccessFlag()
at nCrunch.Client.Processing.LocalProcessingTask.ProcessTaskAndReturnSuccessFlag()
at nCrunch.Client.Processing.ProcessingQueue.#=qV8zCw_0_8RIhYMDUJ7ClGg==(LocalProcessingTask #=q0VCxmak5yUC4CvhVFDnwnw==)

That does look like a VERY interesting exception. The good news is that the failure is happening long before the app container is initialised.. it seems to be in the package installer.

A quick google brought up something of interest - http://stackoverflow.com/questions/13955297/windows-8-blank-app-dep0700-error. Are you running the latest VS update? If not, can you try updating? It may also be worth checking whether your Windows updates are current.

Something else worth trying is setting the 'Process pool size' configuration setting to 0. This will prevent NCrunch from pooling processes between test runs .. which will kill your test execution performance, but will help to rule out whether the issue is caused by overlapping or locking of some kind.

No luck :(. I updated to VS 2013 Update 1. My Windows updates are current. I tried setting "Max number of processing threads" to 1. I'm assuming that's what you meant by "Process pool size" because I couldn't find that setting. I even tried running VS as admin like someone suggested in the thread.

However, killing explorer.exe and restarting it does seem to fix the error ... for now. I'll report back if I start seeing it again.

Interesting ... If the problem continues to be intermittent, I may be able to introduce a fix to counter this behaviour.

Something along the lines of 'keep trying to register the application over and over again until it works', up until a certain limit of course. Let me know how you get on. If it appears again, I'll try this out with a new build.

Will do. So far so good. Thanks again for your help.

Lee