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

Notification

Icon
Error

Private support page does not work.
playtime222
#1 Posted : Tuesday, May 4, 2021 9:11:09 AM(UTC)
Rank: Member

Groups: Registered
Joined: 3/5/2019(UTC)
Posts: 12
Location: Netherlands

Thanks: 2 times
Was thanked: 2 time(s) in 2 post(s)
Submitting the form at https://www.ncrunch.net/support/contact results in a 'could not find the page' error.

It worked now I try with garbage parameters and no zip file.

My zip file is approx 18Mb - could that be the issue?

Remco
#2 Posted : Tuesday, May 4, 2021 9:19:18 AM(UTC)
Rank: NCrunch Developer

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

Thanks: 819 times
Was thanked: 1096 time(s) in 1039 post(s)
playtime222;15432 wrote:

My zip file is approx 18Mb - could that be the issue?


The form does have a size limit of 20Mb, which I'll admit is on the low side given the size of many sample solutions. It's possible that something in the webserver is cutting that down further. If you like, you can try emailing it to support at ncrunch.net. If you have any opportunity to reduce the size of the compression, that may also do the trick.

playtime222
#3 Posted : Tuesday, May 4, 2021 9:21:27 AM(UTC)
Rank: Member

Groups: Registered
Joined: 3/5/2019(UTC)
Posts: 12
Location: Netherlands

Thanks: 2 times
Was thanked: 2 time(s) in 2 post(s)
I just stripped out the obj and bin folders. Bit more setup cos private nuget packages but its all there. Email me if you have any issues when you get around to taking a look.

Thanks.
Remco
#4 Posted : Wednesday, May 5, 2021 6:21:37 AM(UTC)
Rank: NCrunch Developer

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

Thanks: 819 times
Was thanked: 1096 time(s) in 1039 post(s)
playtime222
#5 Posted : Wednesday, May 5, 2021 6:57:58 AM(UTC)
Rank: Member

Groups: Registered
Joined: 3/5/2019(UTC)
Posts: 12
Location: Netherlands

Thanks: 2 times
Was thanked: 2 time(s) in 2 post(s)
Thanks!

As soon as coffee and the required increase in brain power permits :D
playtime222
#6 Posted : Wednesday, May 5, 2021 7:43:45 AM(UTC)
Rank: Member

Groups: Registered
Joined: 3/5/2019(UTC)
Posts: 12
Location: Netherlands

Thanks: 2 times
Was thanked: 2 time(s) in 2 post(s)
Short version - it's a step in the right direction. Some of the projects now compile but some still do not and have the first error I saw:

The custom attribute 'Positive' constructor threw the exception FileNotFoundException: Could not load file or assembly 'nCrunch.TestRuntime.DotNetCore, Version=0.0.0.0, Culture=neutral, PublicKeyToken=01d101bf6f3e0aea'. The system cannot find the file specified

I'll investigate a bit more and put together another project extract for you.

Cheers.

**Updated - new extract sent.
Remco
#7 Posted : Wednesday, May 5, 2021 12:35:00 PM(UTC)
Rank: NCrunch Developer

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

Thanks: 819 times
Was thanked: 1096 time(s) in 1039 post(s)
Thanks for sending this through.

Could you quickly confirm for me if turning on the 'Copy referenced assemblies to workspace' setting for the projects involved makes any difference in regards to this error?
playtime222
#8 Posted : Wednesday, May 5, 2021 12:39:15 PM(UTC)
Rank: Member

Groups: Registered
Joined: 3/5/2019(UTC)
Posts: 12
Location: Netherlands

Thanks: 2 times
Was thanked: 2 time(s) in 2 post(s)
No difference on or off.


[This message may be a repeat - browser glitched!]
Remco
#9 Posted : Thursday, May 6, 2021 12:18:21 AM(UTC)
Rank: NCrunch Developer

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

Thanks: 819 times
Was thanked: 1096 time(s) in 1039 post(s)
Thanks for sending through the larger sample.

The problem here is again caused by interoperability between PostSharp and NCrunch. In this situation, there is an aspect in one of your projects that triggers the creation of attribute constructor code which PostSharp executes during the build of subsequent projects. Because NCrunch also instruments code when it builds your projects, the aspect itself is instrumented and has references to NCrunch.TestRuntime.DotNetCore.dll. When NCrunch processes your tests at runtime, it can supply the test environment with the binding information necessary to find this file. However, PostSharp needs the file at build time (which we never expected, since normally user code is not run during build time).

Under .NET Framework, this wouldn't be a problem as the NCrunch.TestRuntime binary is loaded in the GAC where everything can find it. Unfortunately, .NET Core does not rely on this search path.

If more users encounter this situation we might be able to add an integration point in NCrunch to properly solve it, but right now this looks quite situational, so the focus is on finding a suitable workaround. The plan is to make sure that the NCrunch.TestRuntime.DotNetCore file exists in the build output directory of the project declaring the aspects.

To do this, we use a pre-build step to copy the file from a fixed location and place it in the necessary place when NCrunch is processing the project containing the aspects. I managed to get this working in the aspect project you provided by adding the following to the .csproj:

<Target Name="PreBuild" BeforeTargets="PreBuildEvent" Condition="'$(NCrunch)' == '1'">
<Exec Command="md $(ProjectDir)bin\debug\net5.0&#xD;&#xA;copy /Y c:\PathToAssembly\nCrunch.TestRuntime.DotNetCore.dll $(ProjectDir)bin\debug\net5.0" />
</Target>

For this code to work, you'll need to grab the nCrunch.TestRuntime.DotNetCore.dll file from your NCrunch installation directory (usually something like C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\Common7\IDE\Extensions\Remco Software\NCrunch for Visual Studio 2019), then copy this to a known location (i.e. 'C:\PathToAssembly').
1 user thanked Remco for this useful post.
playtime222 on 5/6/2021(UTC)
playtime222
#10 Posted : Thursday, May 6, 2021 5:57:47 AM(UTC)
Rank: Member

Groups: Registered
Joined: 3/5/2019(UTC)
Posts: 12
Location: Netherlands

Thanks: 2 times
Was thanked: 2 time(s) in 2 post(s)
I'll try this workaround shortly (Coffee depletion as per usual).

The TLDR version seems to be - get the nCrunch.TestRuntime.DotNetCore.dll file into the project build folder with a pre-build step.

I did some more investigation myself last night and it conforms to what you are saying. The thing that was puzzling me was that the ReferenceParameterPolicy aspect - from my own Nuget package - didnt cause an issue. Neither did using Postsharps own aspects.

I spent some time playing 'spot the difference' with dotPeek to no avail. I even tried making my Positive aspect a simple subclass of Postsharp's StrictlyPositive - same problem.

So a tweak on the above workflow would be:

Develop all your aspects and put them into nuget packages using the above build event workaround.
Develop the main projects using the above nuget packages with no further side effects.
playtime222
#11 Posted : Thursday, May 6, 2021 7:39:12 AM(UTC)
Rank: Member

Groups: Registered
Joined: 3/5/2019(UTC)
Posts: 12
Location: Netherlands

Thanks: 2 times
Was thanked: 2 time(s) in 2 post(s)
Turning off instrumentation for the whole solution also works - but then that sort of removes the second primary function of NCrunch - the code coverage dots.

So the work around is working but it is not without strangeness...

1. Changing the project file contents was not immediately reflected in ncrunch test window. Something is being cached somewhere? I tried reloading project and reloading whole solution too.
2. Editing the project file occasionally resulted in a hung, crashed, restarting automatically.

These is the strange one:

3. The projects EntityComponentSystem and EntityComponentSystem.Tests both used to fail before the workaround. EntityComponentSystem ALSO contains aspects. NCrunch compiled these 2 projects (and others dependent on the same aspects) correctly WITHOUT the pre-build event.
4. When I turned off the pre-build events in NCrunch (either individual project or whole solution) Framework.Contracts.Tests continued to compile correctly??!!!???

So, right now, I can make progress but given 3 and 4, I'm not confident it won't suddenly bork again :( If it does, I'll capture the circumstances and let you know.
Remco
#12 Posted : Thursday, May 6, 2021 8:01:32 AM(UTC)
Rank: NCrunch Developer

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

Thanks: 819 times
Was thanked: 1096 time(s) in 1039 post(s)
playtime222;15446 wrote:
Turning off instrumentation for the whole solution also works - but then that sort of removes the second primary function of NCrunch - the code coverage dots.


Yes, this will reliably solve the problem as the missing DLL then isn't needed. I also don't recommend doing it as it makes NCrunch far less useful. Worst case scenario you could instead just disable instrumentation for the projects containing aspects.

playtime222;15446 wrote:

1. Changing the project file contents was not immediately reflected in ncrunch test window. Something is being cached somewhere? I tried reloading project and reloading whole solution too.


Because the problem itself is a referencing issue between projects, NCrunch may not have known to rebuild the dependencies, so an engine reset would fix this.

playtime222;15446 wrote:

2. Editing the project file occasionally resulted in a hung, crashed, restarting automatically.


Not wanting to point fingers, but this sounds like a VS bug. No shortage of those around these days.

playtime222;15446 wrote:

3. The projects EntityComponentSystem and EntityComponentSystem.Tests both used to fail before the workaround. EntityComponentSystem ALSO contains aspects. NCrunch compiled these 2 projects (and others dependent on the same aspects) correctly WITHOUT the pre-build event.
4. When I turned off the pre-build events in NCrunch (either individual project or whole solution) Framework.Contracts.Tests continued to compile correctly??!!!???


The pre-build event will copy the NCrunch DLL into the required place in the build output directory of the project involved. If the event is deactivated or removed, the file may still be there somewhere in a search path where the PostSharp build step can find it. I'm not sure what kind of dependency handling PostSharp use inside their build step, but it may be quite sophisticated. Assume you will always need the pre-build step in projects that declare aspects, as otherwise the problem is highly likely to resurface in a future session.
playtime222
#13 Posted : Thursday, May 6, 2021 8:11:19 AM(UTC)
Rank: Member

Groups: Registered
Joined: 3/5/2019(UTC)
Posts: 12
Location: Netherlands

Thanks: 2 times
Was thanked: 2 time(s) in 2 post(s)
That all makes sense.

Just in case you missed it, the other workaround is to remove all the aspects from the solution and put them in a nuget package. You then only need the workaround for solutions with the aspects themselves and the main solution will consume the aspects just fine.

VS bugs? Say it isn't so! :D

For 1 I did try various things like resetting the NCrunch engine and outright deleting the ncrunch workspace folder to see if I got a reaction but I see what you mean.

3/4 is odd but I get what you mean about 'its in the search path'.

TLDR, as long as one of the leaf dependencies is fixed with the workaround, it looks like I am good to go.

Thanks for all the help and the immediate response (especially given the time zone difference and having to occasionally stop hobbits from chewing through your broadband line).

1 user thanked playtime222 for this useful post.
Remco on 5/6/2021(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.088 seconds.
Trial NCrunch
Take NCrunch for a spin
Do your fingers a favour and supercharge your testing workflow
Free Download