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

Notification

Icon
Error
2 Pages12>
.NET Core support for NCrunch (first public build)
Options
Previous Topic Next Topic
Remco
#1 Posted : Wednesday, March 1, 2017 7:24:50 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 6,974

Thanks: 929 times
Was thanked: 1256 time(s) in 1169 post(s)
I'm happy to announce the first public test build for .NET Core support in NCrunch. This build of NCrunch is able to load .NET Core projects, build them, instrument their assemblies, construct test environments and run xUnit/MSTest/NUnit tests end-to-end. Distributed processing has also been implemented for .NET Core.

This build does still have several limitations:

- Debugging is not yet working correctly. The debugger is able to trace source lines and hit breakpoints, but cannot evaluate any data at runtime.

- MSpec is not yet supported under .NET Core.

- There are some synchronisation issues around shared projects. If you are using shared projects and you make project changes, telling NCrunch to reload and rebuild affected projects (or hitting reset) should resolve this.

- Test projects compiled to the x86 platform cannot be executed on a 64-bit O/S. This is because of a bug in .NET core itself that doesn't handle CPU architectures correctly for console applications.

- Background exceptions thrown in the test process will cause it to immediately terminate with an ugly windows exception popup window. Currently there is no way to set a global trap for background exceptions under .NET core. MS are expecting to add this with the .NET core 2.0 release expected in Q3, so it may be some time before this can be fixed.

I'm certain there will be more problems that I haven't yet identified. If you encounter any issues, please free to post them in this forum thread and I'll try to address them as best I can. This is a very large new platform and I expect it will be a while before everything is 100%.

http://downloads.ncrunch.net/NCrunch_Console_3.4.0.11.msi
http://downloads.ncrunch.net/NCrunch_Console_3.4.0.11.zip
http://downloads.ncrunch.net/NCrunch_GridNodeServer_3.4.0.11.msi
http://downloads.ncrunch.net/NCrunch_GridNodeServer_3.4.0.11.zip
http://downloads.ncrunch.net/NCrunch_LicenseServer_3.4.0.11.zip
http://downloads.ncrunch.net/NCrunch_VS2017_3.4.0.11.msi
http://downloads.ncrunch.net/NCrunch_VS2017_3.4.0.11.zip


NOTE: The following versions of VS are not supported by NCrunch under .NET Core. This is because xproj/project.json is deprecated and will not be supported in future. To use .NET Core with NCrunch, you must be running under VS2017.

http://downloads.ncrunch.net/NCrunch_VS2008_3.4.0.11.msi
http://downloads.ncrunch.net/NCrunch_VS2010_3.4.0.11.msi
http://downloads.ncrunch.net/NCrunch_VS2010_3.4.0.11.zip
http://downloads.ncrunch.net/NCrunch_VS2012_3.4.0.11.msi
http://downloads.ncrunch.net/NCrunch_VS2012_3.4.0.11.zip
http://downloads.ncrunch.net/NCrunch_VS2013_3.4.0.11.msi
http://downloads.ncrunch.net/NCrunch_VS2013_3.4.0.11.zip
http://downloads.ncrunch.net/NCrunch_VS2015_3.4.0.11.msi
http://downloads.ncrunch.net/NCrunch_VS2015_3.4.0.11.zip
Back to top
 |  Edit by user
4 users thanked Remco for this useful post.
memark on 3/1/2017(UTC), GreenMoose on 3/1/2017(UTC), gravypower on 3/5/2017(UTC), martinklinkexavo on 3/7/2017(UTC)
memark
#2 Posted : Wednesday, March 1, 2017 9:28:19 AM(UTC)
Rank: Newbie

Groups: Registered
Joined: 8/26/2014(UTC)
Posts: 9
Location: Sweden

Thanks: 4 times
Was thanked: 3 time(s) in 3 post(s)
I'm grateful that this test build is finally available!

I have tried it on two different solutions:

* One consisting of only .net core projects (targeting .net framework). It says "No supported projects detected".

* One consisting of mixed project types. The .net framework projects are detected correctly (as before). The .net core projects loaded correctly once (but had build errors concerning references), but usually they end up with this error:

Quote:
There are projects in this solution that have not been reported as loaded by the IDE within the timeout period allowed during NCrunch initialisation. It is possible that these projects are of an unusual type and NCrunch has been unable to correctly detect them. They may be 'unloaded' in Visual Studio, or alternatively you may be experiencing IDE solution loading times that are much higher than normal.

If these projects are not required for your NCrunch session, it is recommended that you ignore them using the NCrunch 'Ignore this component completely' configuration setting. This will result in faster NCrunch initialisation times as the engine no longer needs to wait for data related to these projects.

The NCrunch 'Project load timeout' configuration setting can also be adjusted to improve startup times if you regularly experience this problem.

The following projects exist in this solution but could not be resolved by NCrunch during initialisation:

MyProject.Api\MyProject.Api.xproj
MyProject.Api.Tests\MyProject.Api.Tests.xproj


Using NCrunch_VS2017_3.4.0.11.msi on VS 2015 Upd 3 on Windows 10 Pro N.

I will be happy to try out new builds and/or help you solve these problems.
Back to top
 |  Edit by user
Remco
#3 Posted : Wednesday, March 1, 2017 9:30:31 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 6,974

Thanks: 929 times
Was thanked: 1256 time(s) in 1169 post(s)
Sorry, I should have clarified. This build won't work with .NET core projects that are using xproj/project.json. It will only work with .NET Core projects as built from the VS project templates under VS2017.

This is because the xproj/project.json system is built on a whole toolchain that has been deprecated by Microsoft. Rather than spend months integrating with a dead system, it seemed more sensible to plug into the new one under VS2017.

This does mean that you'll need to be using VS2017 RC to run .NET Core under NCrunch. VS2015 won't work unfortunately.
Back to top
 |  Edit by user
memark
#4 Posted : Wednesday, March 1, 2017 9:35:07 AM(UTC)
Rank: Newbie

Groups: Registered
Joined: 8/26/2014(UTC)
Posts: 9
Location: Sweden

Thanks: 4 times
Was thanked: 3 time(s) in 3 post(s)
Oh ok, I see. No problem, I fully understand your reasoning.

But it's still little confusing when you provide builds for all versions of Visual Studio in your post. You might consider removing the ones not actually supported, since users visiting this post probably came here to actually use .net core. :)
Back to top
Remco
#5 Posted : Wednesday, March 1, 2017 9:45:03 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 6,974

Thanks: 929 times
Was thanked: 1256 time(s) in 1169 post(s)
memark;9863 wrote:
Oh ok, I see. No problem, I fully understand your reasoning.

But it's still little confusing when you provide builds for all versions of Visual Studio in your post. You might consider removing the ones not actually supported, since users visiting this post probably came here to actually use .net core. :)


That's fair reasoning :) I'll amend the post above so this is clearer for everyone. This build does contain a few other fixes, so the earlier versions of VS might still be worth something to someone.
Back to top
shaynevanasperen
#6 Posted : Wednesday, March 1, 2017 11:33:57 AM(UTC)
Rank: Newbie

Groups: Registered
Joined: 3/1/2017(UTC)
Posts: 2
Location: United Kingdom
I'm very disappointed. I just decided to purchase a licence so that I could try out this new build, only to discover after purchasing that it only lasts for one year. That should have been made clear before I purchased it. It wouldn't be so bad if the software actually worked though, but unfortunately it crashed for me. So now I have a licence to some software that doesn't even work and I don't know how long it will be before this bug is fixed. I think it would be fair to expect my licence to be extended by however long it takes to get this bug fixed. I've submitted the bug report using the NCrunch bug report submitter, but here's the stack trace of the error:

An error occurred while analysing this project after it was built: NCrunch encountered an unexpected error occurred while building an environment to analyse an assembly: System.NullReferenceException: Object reference not set to an instance of an object.
at nCrunch.Core.TestManagement.TestRunnerProcess..()
at nCrunch.Common.PerformanceTracking.PerfTracker.TrackActivity(String name, Action activity)
at nCrunch.Core.TestManagement.TestRunnerProcess.(Boolean , FilePath , GridClientId , CustomEnvironmentVariable[] )
at nCrunch.Core.TestManagement.TestRunnerProcess..()
at nCrunch.Common.PerformanceTracking.PerfTracker.TrackActivity(String name, Action activity)
at nCrunch.Core.Processing.AnalysisTaskLogic.DoProcessTaskAndReturnSuccessFlag()

This was using NCrunch in the latest release candidate of Visual Studio 2017 on a .NET Core project with xUnit tests and BDDfy/Specify. The project compiles without any warnings or errors and the tests run fine in the Visual Studio test runner.
Back to top
memark
#10 Posted : Wednesday, March 1, 2017 11:37:47 AM(UTC)
Rank: Newbie

Groups: Registered
Joined: 8/26/2014(UTC)
Posts: 9
Location: Sweden

Thanks: 4 times
Was thanked: 3 time(s) in 3 post(s)
Doesn't the normal NCrunch trial period work for this build as well?
Back to top
Remco
#7 Posted : Wednesday, March 1, 2017 12:00:39 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 6,974

Thanks: 929 times
Was thanked: 1256 time(s) in 1169 post(s)
shaynevanasperen;9865 wrote:
I'm very disappointed. I just decided to purchase a licence so that I could try out this new build, only to discover after purchasing that it only lasts for one year. That should have been made clear before I purchased it. It wouldn't be so bad if the software actually worked though, but unfortunately it crashed for me. So now I have a licence to some software that doesn't even work and I don't know how long it will be before this bug is fixed. I think it would be fair to expect my licence to be extended by however long it takes to get this bug fixed. I've submitted the bug report using the NCrunch bug report submitter, but here's the stack trace of the error:

An error occurred while analysing this project after it was built: NCrunch encountered an unexpected error occurred while building an environment to analyse an assembly: System.NullReferenceException: Object reference not set to an instance of an object.
at nCrunch.Core.TestManagement.TestRunnerProcess..()
at nCrunch.Common.PerformanceTracking.PerfTracker.TrackActivity(String name, Action activity)
at nCrunch.Core.TestManagement.TestRunnerProcess.(Boolean , FilePath , GridClientId , CustomEnvironmentVariable[] )
at nCrunch.Core.TestManagement.TestRunnerProcess..()
at nCrunch.Common.PerformanceTracking.PerfTracker.TrackActivity(String name, Action activity)
at nCrunch.Core.Processing.AnalysisTaskLogic.DoProcessTaskAndReturnSuccessFlag()

This was using NCrunch in the latest release candidate of Visual Studio 2017 on a .NET Core project with xUnit tests and BDDfy/Specify. The project compiles without any warnings or errors and the tests run fine in the Visual Studio test runner.


I'm sorry to hear you had a bad experience with this build. Please do be aware that this is the first unstable test build of a huge feature that is built to integrate with a pre-release platform. I really can't stress this enough; this are going to go wrong in this build. The good news is that they should be fixed quickly as soon as the problems are found, thanks to bug reports like yours.

This looks to me to be a dependency related issue. I'm wondering if you can check your list of Nuget packages (under C:\Users\USER\.nuget) to see if any of the following are not installed on your system. If they aren't there, try installing them. This can be easily done by just adding the right version of the package to a dummy project in your VS:

System.Collections.NonGeneric version 4.3.0
System.Reflection version 4.3.0
System.Reflection.TypeExtensions version 4.3.0
System.Runtime.Loader version 4.3.0
System.Runtime.Serialization.Formatters version 4.3.0
System.Threading version 4.3.0
System.Threading.Thread version 4.3.0
System.Diagnostics.TraceSource version 4.3.0
System.ComponentModel.TypeConverter version 4.3.0

If this solves the problem, I should be able to implement a proper solution in the next build.
Back to top
2 users thanked Remco for this useful post.
jorgen on 3/5/2017(UTC), martinklinkexavo on 3/7/2017(UTC)
Remco
#11 Posted : Wednesday, March 1, 2017 12:05:27 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 6,974

Thanks: 929 times
Was thanked: 1256 time(s) in 1169 post(s)
memark;9866 wrote:
Doesn't the normal NCrunch trial period work for this build as well?


Yes and no. All NCrunch builds ship with the 30 day evaluation license, but once it's been used, you can't use it again, even in future versions.

It's not ideal for test builds like this. To be honest, the only reason the system hasn't been changed for this build is because the build is expected to have a very short lifespan (i.e. likely less than two weeks) and it just didn't seem worthwhile to reimplement and retest the whole licensing system for the sake of a throw-away build. I'm hoping that within a couple of weeks all the major kinks will be resolved or at least publicly identified and we'll have something stable out there.
Back to top
shaynevanasperen
#8 Posted : Wednesday, March 1, 2017 2:02:21 PM(UTC)
Rank: Newbie

Groups: Registered
Joined: 3/1/2017(UTC)
Posts: 2
Location: United Kingdom
Remco;9867 wrote:
shaynevanasperen;9865 wrote:
I'm very disappointed. I just decided to purchase a licence so that I could try out this new build, only to discover after purchasing that it only lasts for one year. That should have been made clear before I purchased it. It wouldn't be so bad if the software actually worked though, but unfortunately it crashed for me. So now I have a licence to some software that doesn't even work and I don't know how long it will be before this bug is fixed. I think it would be fair to expect my licence to be extended by however long it takes to get this bug fixed. I've submitted the bug report using the NCrunch bug report submitter, but here's the stack trace of the error:

An error occurred while analysing this project after it was built: NCrunch encountered an unexpected error occurred while building an environment to analyse an assembly: System.NullReferenceException: Object reference not set to an instance of an object.
at nCrunch.Core.TestManagement.TestRunnerProcess..()
at nCrunch.Common.PerformanceTracking.PerfTracker.TrackActivity(String name, Action activity)
at nCrunch.Core.TestManagement.TestRunnerProcess.(Boolean , FilePath , GridClientId , CustomEnvironmentVariable[] )
at nCrunch.Core.TestManagement.TestRunnerProcess..()
at nCrunch.Common.PerformanceTracking.PerfTracker.TrackActivity(String name, Action activity)
at nCrunch.Core.Processing.AnalysisTaskLogic.DoProcessTaskAndReturnSuccessFlag()

This was using NCrunch in the latest release candidate of Visual Studio 2017 on a .NET Core project with xUnit tests and BDDfy/Specify. The project compiles without any warnings or errors and the tests run fine in the Visual Studio test runner.


I'm sorry to hear you had a bad experience with this build. Please do be aware that this is the first unstable test build of a huge feature that is built to integrate with a pre-release platform. I really can't stress this enough; this are going to go wrong in this build. The good news is that they should be fixed quickly as soon as the problems are found, thanks to bug reports like yours.

This looks to me to be a dependency related issue. I'm wondering if you can check your list of Nuget packages (under C:\Users\USER\.nuget) to see if any of the following are not installed on your system. If they aren't there, try installing them. This can be easily done by just adding the right version of the package to a dummy project in your VS:

System.Collections.NonGeneric version 4.3.0
System.Reflection version 4.3.0
System.Reflection.TypeExtensions version 4.3.0
System.Runtime.Loader version 4.3.0
System.Runtime.Serialization.Formatters version 4.3.0
System.Threading version 4.3.0
System.Threading.Thread version 4.3.0
System.Diagnostics.TraceSource version 4.3.0
System.ComponentModel.TypeConverter version 4.3.0

If this solves the problem, I should be able to implement a proper solution in the next build.


Thank You! That solves the problem. I was missing System.Runtime.Serialization.Formatters and System.Diagnostics.TraceSource. After installing them in a dummy project I can now run my tests with NCrunch.
Back to top
Remco
#9 Posted : Wednesday, March 1, 2017 10:09:35 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 6,974

Thanks: 929 times
Was thanked: 1256 time(s) in 1169 post(s)
shaynevanasperen;9869 wrote:
Thank You! That solves the problem. I was missing System.Runtime.Serialization.Formatters and System.Diagnostics.TraceSource. After installing them in a dummy project I can now run my tests with NCrunch.


Excellent! Thanks for confirming this!
Back to top
jorgen
#12 Posted : Sunday, March 5, 2017 4:09:22 AM(UTC)
Rank: Newbie

Groups: Registered
Joined: 3/5/2017(UTC)
Posts: 2
Location: Australia

Thanks: 2 times
Was thanked: 3 time(s) in 2 post(s)
Thanks ShanyeV and Remco. Having just seen on Twitter that the first version is out, I installed the latest (as of 2 hours ago) ncrunch having removed the old one into latest 2017RC. Same issue came up for me.

I was missing...

All of: System.Runtime.Serialization.Formatters version 4.3.0
The 4.3 version of: System.Diagnostics.TraceSource version 4.3.0

I installed those using nuget packet manager in a throwaway project and after this was able to create a new core project with a Xunit 2.2.0 test project, and verified that NCrunch would perform a simple test. Finally, green bars in a Core project. I can't even begin to understand the complexity of that, well done and thanks Remco. :-)

(As a PS, the throwaway project I used was a Xunit template project which using RC versions of Xunit got into a bad state after I performed package upgrades. Hundreds of "detected pacakage downgrade 4.3.0 to 4.0.1". So if anyone else comes across that, perhaps just create a new empty project and add Xunit 2.2.0 manually).
Back to top
2 users thanked jorgen for this useful post.
Remco on 3/5/2017(UTC), martinklinkexavo on 3/7/2017(UTC)
martinklinkexavo
#13 Posted : Tuesday, March 7, 2017 3:50:14 PM(UTC)
Rank: Newbie

Groups: Registered
Joined: 3/7/2017(UTC)
Posts: 1
Location: Germany

Thanks: 4 times
First of all, thank you for providing a .NET Core test build. After resolving the first issue with the help of this thread, I am now facing another issue that might be related to NCrunch.

I have an ASP.NET Core app with a test project that works on both the command line (via dotnet test) as well as in the regular VS test explorer.

The implementation requires to access the generated XML documentation file that is placed next to the DLL during the build process. Apparently, NCrunch does not include this file in its temporary build folder. I guess I could find a workaround by explicitly adding the file as output (although it is generated by the compiler and there is no source representation of the file). But I assume that this is a bug in the current implementation.

Please let me know if you are interested in further details, glad to help.

Thanks again for a great product!

Cheers,
Martin

UPDATE: None of the Project artifacts are contained in the build folder where NCrunch is running the tests. There are only the test project's bin files.

UPDATE 2: The switch "Copy Referenced Assemblies To Workspace" fixes the problem but gives me an ugly warning that makes me feel that I shouldn't be doing this ;) After all, I just need the XML file anyway. But that seems to pick it up.
Back to top
 |  Edit by user
Remco
#14 Posted : Tuesday, March 7, 2017 10:15:38 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 6,974

Thanks: 929 times
Was thanked: 1256 time(s) in 1169 post(s)
Hi, thanks for sharing this problem. Are these artifacts originating from a project your test project is referencing? If so, this isn't a problem specific to .NET Core - see http://www.ncrunch.net/documentation/considerations-and-constraints_assembly-colocation-assumptions for more details.
Back to top
Remco
#15 Posted : Wednesday, March 8, 2017 12:37:19 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 6,974

Thanks: 929 times
Was thanked: 1256 time(s) in 1169 post(s)
Back to top
1 user thanked Remco for this useful post.
jorgen on 3/9/2017(UTC)
GreenMoose
#16 Posted : Wednesday, March 8, 2017 9:56:32 AM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 6/17/2012(UTC)
Posts: 503

Thanks: 142 times
Was thanked: 66 time(s) in 64 post(s)
Every time I try to run a test manually, I get error below:
Quote:

ENGINE - [10:49:25.2727-LocalTestExecutionTask-49] ERROR (Internal): System.IO.FileLoadException: Could not load file or assembly 'nunit.framework, Version=3.6.1.0, Culture=neutral, PublicKeyToken=2638cd05610744eb'.
at System.Runtime.Loader.AssemblyLoadContext.LoadFromPath(IntPtr ptrNativeAssemblyLoadContext, String ilPath, String niPath, ObjectHandleOnStack retAssembly)
at System.Runtime.Loader.AssemblyLoadContext.LoadFromAssemblyPath(String assemblyPath)
at nCrunch.Common.ExecutionPlatform.LoadAssembly(FilePath assemblyFilePath)
at nCrunch.Module.NUnit3.Integration.NUnit3FrameworkInteractor..ctor(TestEnvironmentConfig testEnvironmentConfig, DynamicProxy[] dynamicProxies)
at nCrunch.Module.NUnit3.Integration.NUnit3FrameworkRuntimeEnvironment.InitialiseFrameworkRuntimeEnvironment(TestEnvironmentConfig testEnvironmentConfig, DynamicProxy[] dynamicProxies)
at nCrunch.TestExecution.RemoteTaskRunner.<>c__DisplayClass21_0.<getInitialisedTestFrameworkEnvironment>b__0()
at nCrunch.Common.PerformanceTracking.PerfTracker.TrackActivity(String name, Action activity)
at nCrunch.TestExecution.RemoteTaskRunner.getInitialisedTestFrameworkEnvironment(TestFrameworkRuntimeEnvironmentReference executorReference, TestExecutionParameters parameters)
at nCrunch.TestExecution.RemoteTaskRunner.RunTests(TestFrameworkRuntimeEnvironmentReference executorReference, TestExecutionParameters parameters)


This is in a 1 file "Class 1" - project with 1 test, it just "stalls" (icon "test is queued") with above error in log output.
however, if I set the engine mode to "run tests automatically" it works just fine (after re-initializing engine), but as soon as I try to execute a test explicitly it stops working again.
Also I noted that if I add a nuget package via package manager console, I must save project in vstudio before NCrunch picks up the package and builds the project successfully.
Back to top
Remco
#17 Posted : Wednesday, March 8, 2017 10:03:13 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 6,974

Thanks: 929 times
Was thanked: 1256 time(s) in 1169 post(s)
Thanks, I just saw your bug report come through and I've reproduced the problem. NCrunch isn't resolving the nunit.framework assembly correctly when it uses newly initialised test processes that weren't used for discovery. You'll see this often if you are using NUnit under .NET Core and you have parallel execution enabled.

A fix has been committed and I'm about to make a new release build (v3.5) to fix this problem. It'll be up there within the next half hour or so.
Back to top
Remco
#18 Posted : Wednesday, March 8, 2017 10:23:37 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 6,974

Thanks: 929 times
Was thanked: 1256 time(s) in 1169 post(s)
Before I put v3.5 up, I'd like to learn a bit more about the other bug report you just submitted.

The project you have that NCrunch is failing to analyse is falling over because of a missing dependency, System.Diagnostics.TraceSource v4.0.0.0.

Are you able to identify how this package is being referenced from your project? Is it being referenced directly? If the project is built, does the reference show in the generated .deps.json file in the build output directory?

Also, is the package installed on your machine?

NCrunch should usually identify all these references and flag them up so they can be found in the runtime environment. It's expected that VS would have automatically restored them if they are being used.
Back to top
GreenMoose
#20 Posted : Wednesday, March 8, 2017 10:38:30 AM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 6/17/2012(UTC)
Posts: 503

Thanks: 142 times
Was thanked: 66 time(s) in 64 post(s)
Great!

Also I noticed that it doesn't seem to respect [OneTimeOnly], as in:
Quote:

/// <summary>
/// One time only initialization routine for this test assembly.
/// </summary>
[SetUpFixture]
public class SetupTestSuite
{
[OneTimeSetUp]
public void SetupTestSuiteSetUp()
{
}
}


I get a lot of test errors due to this is being invoked multiple times (as in a static member is already set). Moving it out to have "one time only" execution (guarded via static field) as part of normal setup in a test fixture resolves the issue.
(I didn't get stacktrace either when it failed).
Back to top
Remco
#21 Posted : Wednesday, March 8, 2017 10:43:19 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 6,974

Thanks: 929 times
Was thanked: 1256 time(s) in 1169 post(s)
GreenMoose;9888 wrote:

I get a lot of test errors due to this is being invoked multiple times (as in a static member is already set). Moving it out to have "one time only" execution (guarded via static field) as part of normal setup in a test fixture resolves the issue.
(I didn't get stacktrace either when it failed).


If I understand this correctly, I think this one is by design due to the SetUpFixture being invoked every time NCrunch starts a test run for a batch (test runner re-use). It's been a problem since the early days, and there isn't any way to fix it in NCrunch itself. Adding a static guard check is the correct solution to this problem.

I'm not sure if you saw my earlier comment about the System.Diagnostics.TraceSource issue. If you do have time, I'd really like to learn more about this as v3.5 gives us an immediate release window to fix it :)
Back to top
1 user thanked Remco for this useful post.
GreenMoose on 3/8/2017(UTC)
Users browsing this topic
Guest
2 Pages12>
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.166 seconds.
Trial NCrunch
Take NCrunch for a spin
Do your fingers a favour and supercharge your testing workflow
Free Download