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

Notification

Icon
Error

2 Pages12>
Empty Test .csproj fails to build
UppSol
#1 Posted : Tuesday, May 26, 2020 9:24:10 AM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 3/21/2019(UTC)
Posts: 41
Location: Austria

Thanks: 30 times
Was thanked: 7 time(s) in 7 post(s)
I also send you a report with details via VS 2019, we are using the latest NCrunch version (4.3 from Feb 02)


[11:05:46.8825-UI-1] GetServiceLocal for Microsoft.VisualStudio.ComponentModelHost.SComponentModel
ENGINE - [11:05:51.1501-InitialisationQueueTask-23] ERROR (Internal): System.IO.IOException: The path 'C:\Dev\Vie\Shared\SolutionItems\C:\Dev\Vie\Shared\SolutionItems\CustomRules\Upper.FxCop.CustomRules.dll' could not be processed because it is not of legal form
at nCrunch.Common.IO.DiskPath..ctor(String absolutePath, Boolean pathIsChecked)
at nCrunch.Common.IO.FilePath..ctor(String absoluteFilePath, Boolean isAbsoluteFilePathChecked)
at nCrunch.Core.InlineModules.CodeAnalysisRulesetDependencyResolver.(IList`1 , String )
at nCrunch.Core.InlineModules.CodeAnalysisRulesetDependencyResolver.(FilePath )
at nCrunch.Core.InlineModules.CodeAnalysisRulesetDependencyResolver.ResolveAnalysisRulesetDependencies(FilePath rulesetFilePath).

Please have a look at the image as well: https://ibb.co/VMFB2gZ

Here is the Upper.FxCop.CustomRules.dll (we are using this custom FxCop Rule dll for years now) and as I stated in the VS report the FxCop Custom rule dll is correct processed by NCrunch when at least on Cs file is in the .csproj only if the .csproj is empty this error occurs.

https://drive.google.com...PvCUkQ/view?usp=sharing

Please let me know as soon as I can delete the shared files.

Info: We are using .Net 4.7.2 with sdk based projects.
Remco
#2 Posted : Wednesday, May 27, 2020 12:20:19 AM(UTC)
Rank: NCrunch Developer

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

Thanks: 959 times
Was thanked: 1290 time(s) in 1196 post(s)
Hi, thanks for sharing this problem.

This looks to be caused by an oversight in our parsing of the code analysis ruleset file. It looks like your ruleset has a dependency specified using an absolute path (i.e. 'C:\Dev\Vie\Shared\SolutionItems\') as opposed to a relative path. At the time this code was introduced, we weren't aware that an absolute path was legit in this field.

Does replacing the absolute path with a relative one resolve your issue?
UppSol
#3 Posted : Wednesday, May 27, 2020 4:47:59 AM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 3/21/2019(UTC)
Posts: 41
Location: Austria

Thanks: 30 times
Was thanked: 7 time(s) in 7 post(s)
Remco;14740 wrote:
Hi, thanks for sharing this problem.

This looks to be caused by an oversight in our parsing of the code analysis ruleset file. It looks like your ruleset has a dependency specified using an absolute path (i.e. 'C:\Dev\Vie\Shared\SolutionItems\') as opposed to a relative path. At the time this code was introduced, we weren't aware that an absolute path was legit in this field.

Does replacing the absolute path with a relative one resolve your issue?


Hi Remco,

Unfortunately it's not working!
Out of curiosity why is the absolute path an issue when the .csproj contains no files, but when files are available everything is working fine?
We are using NCrunch and the CustomRules.dll (with an absolute path) for years now and I think I have never encountered this issue before.

I tried the following relative paths:
<RuleHintPaths>
<Path>CustomRules\Upper.FxCop.CustomRules.dll</Path>
</RuleHintPaths>

<RuleHintPaths>
<Path>.\CustomRules\Upper.FxCop.CustomRules.dll</Path>
</RuleHintPaths>

<RuleHintPaths>
<Path>..\SolutionItems\CustomRules\Upper.FxCop.CustomRules.dll</Path>
</RuleHintPaths>

Btw. We are using the optimised mode (but it's also happening with the "normal" one).

ENGINE - [06:45:18.3958-LocalBuildTask-36] ERROR (Internal): System.IndexOutOfRangeException: Index was outside the bounds of the array.
at nCrunch.Compiler.Cil.Symbols.Legacy.CilLegacyPdbDbiStream..ctor(CilAddress address, UInt32 totalStreamCount)
at nCrunch.Compiler.Cil.Symbols.Legacy.CilLegacySymbolsDataSource..ctor(Byte[] pdbFileContent, UInt32 entryPointToken)
at nCrunch.Compiler.Cil.CilAssembly.Load(FilePath assemblyFile, CilContext context)
at nCrunch.Compiler.Cil.CachedCilAssembly..ctor(FilePath assemblyFilePath, CilContext context, Boolean isInstrumentationTarget)
at nCrunch.Compiler.Cil.CilSession.LoadAssembly(FilePath assemblyFilePath, Boolean isInstrumentationTarget)
at nCrunch.Compiler.NewStaticManipulation.BuiltCilAssembly..ctor(FilePath builtAssemblyFilePath, IList`1 adjustedAssemblyReferences, Boolean instrumentForPerformanceMeasurement, ComponentInstrumentationParameters instrumentationParameters, ILogger logger)
at nCrunch.Compiler.RemoteBuildRunner..()
at nCrunch.Common.PerformanceTracking.PerfTracker.TrackActivity(String name, Action activity)
at nCrunch.Compiler.RemoteBuildRunner.(ComponentInstrumentationParameters , BuildOutput , IBackgroundTaskProcessor )
at nCrunch.Compiler.RemoteBuildRunner.PerformPostProcessingOfBuiltAssembly(ComponentInstrumentationParameters instrumentationParameters, BuildOutput output, IBackgroundTaskProcessor backgroundTaskProcessor)
at nCrunch.Core.BuildManagement.BuildEnvironment..()
at nCrunch.Common.PerformanceTracking.PerfTracker.TrackActivity(String name, Action activity)
at nCrunch.Core.BuildManagement.BuildEnvironment.Build(SnapshotComponent snapshotComponentToBuild, IList`1 referencedComponents, GridClientId gridClientId, IList`1 customEnvironmentVariables, IPlatformBuildExtender extender, Guid taskId, GridAddress clientAddress)
at nCrunch.Core.Processing.BuildTaskLogic.DoProcessTaskAndReturnSuccessFlag()
at nCrunch.Core.Processing.TaskLogic.ProcessTaskAndReturnSuccessFlag()
at nCrunch.Client.Processing.LocalProcessingTask.ProcessTaskAndReturnSuccessFlag()
at nCrunch.Client.Processing.ProcessingQueue..()

Br
Remco
#4 Posted : Wednesday, May 27, 2020 1:06:33 PM(UTC)
Rank: NCrunch Developer

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

Thanks: 959 times
Was thanked: 1290 time(s) in 1196 post(s)
UppSol;14741 wrote:

Out of curiosity why is the absolute path an issue when the .csproj contains no files, but when files are available everything is working fine?
We are using NCrunch and the CustomRules.dll (with an absolute path) for years now and I think I have never encountered this issue before.


NCrunch attempts to parse the FxCop rules files to identify dependencies that need to be included in the workspace. People often have ruleset files that aren't referenced by the build system but are still required for certain build tasks, and parsing the ruleset files is the only way to find them. The stack trace you provided earlier in this thread points specifically to a piece of code in the ruleset parser where NCrunch assumes that the file paths in the ruleset file are always relative and never absolute. The use of absolute paths breaks this logic, so it's something that I've marked for fixing. There could be a number of structural reasons for why this hasn't bothered you before, but the NCrunch code involved has been there for years and hasn't changed in a very long time.

I can't speculate as to all the conditions around this because the build system is very complex and it may be reporting the ruleset files selectively. Regardless:
- A defect has been tasked to make NCrunch work with absolute file paths in ruleset files
- I recommend using relative paths in these files. It's cleaner, and will get you around the immediate issue

UppSol;14741 wrote:

ENGINE - [06:45:18.3958-LocalBuildTask-36] ERROR (Internal): System.IndexOutOfRangeException: Index was outside the bounds of the array.
at nCrunch.Compiler.Cil.Symbols.Legacy.CilLegacyPdbDbiStream..ctor(CilAddress address, UInt32 totalStreamCount)
at nCrunch.Compiler.Cil.Symbols.Legacy.CilLegacySymbolsDataSource..ctor(Byte[] pdbFileContent, UInt32 entryPointToken)
at nCrunch.Compiler.Cil.CilAssembly.Load(FilePath assemblyFile, CilContext context)
at nCrunch.Compiler.Cil.CachedCilAssembly..ctor(FilePath assemblyFilePath, CilContext context, Boolean isInstrumentationTarget)
at nCrunch.Compiler.Cil.CilSession.LoadAssembly(FilePath assemblyFilePath, Boolean isInstrumentationTarget)
at nCrunch.Compiler.NewStaticManipulation.BuiltCilAssembly..ctor(FilePath builtAssemblyFilePath, IList`1 adjustedAssemblyReferences, Boolean instrumentForPerformanceMeasurement, ComponentInstrumentationParameters instrumentationParameters, ILogger logger)
at nCrunch.Compiler.RemoteBuildRunner..()
at nCrunch.Common.PerformanceTracking.PerfTracker.TrackActivity(String name, Action activity)
at nCrunch.Compiler.RemoteBuildRunner.(ComponentInstrumentationParameters , BuildOutput , IBackgroundTaskProcessor )
at nCrunch.Compiler.RemoteBuildRunner.PerformPostProcessingOfBuiltAssembly(ComponentInstrumentationParameters instrumentationParameters, BuildOutput output, IBackgroundTaskProcessor backgroundTaskProcessor)
at nCrunch.Core.BuildManagement.BuildEnvironment..()
at nCrunch.Common.PerformanceTracking.PerfTracker.TrackActivity(String name, Action activity)
at nCrunch.Core.BuildManagement.BuildEnvironment.Build(SnapshotComponent snapshotComponentToBuild, IList`1 referencedComponents, GridClientId gridClientId, IList`1 customEnvironmentVariables, IPlatformBuildExtender extender, Guid taskId, GridAddress clientAddress)
at nCrunch.Core.Processing.BuildTaskLogic.DoProcessTaskAndReturnSuccessFlag()
at nCrunch.Core.Processing.TaskLogic.ProcessTaskAndReturnSuccessFlag()
at nCrunch.Client.Processing.LocalProcessingTask.ProcessTaskAndReturnSuccessFlag()
at nCrunch.Client.Processing.ProcessingQueue..()


This exception is very different to the one you reported earlier. It looks to be related to the structure of the PDB file. Is this a new problem you've discovered after switching the paths? Or are you still receiving the previous exception?
upper
#5 Posted : Wednesday, May 27, 2020 5:30:21 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 9/21/2016(UTC)
Posts: 31
Location: Austria

Thanks: 8 times
Was thanked: 8 time(s) in 7 post(s)
Remco;14742 wrote:
UppSol;14741 wrote:

Out of curiosity why is the absolute path an issue when the .csproj contains no files, but when files are available everything is working fine?
We are using NCrunch and the CustomRules.dll (with an absolute path) for years now and I think I have never encountered this issue before.


NCrunch attempts to parse the FxCop rules files to identify dependencies that need to be included in the workspace. People often have ruleset files that aren't referenced by the build system but are still required for certain build tasks, and parsing the ruleset files is the only way to find them. The stack trace you provided earlier in this thread points specifically to a piece of code in the ruleset parser where NCrunch assumes that the file paths in the ruleset file are always relative and never absolute. The use of absolute paths breaks this logic, so it's something that I've marked for fixing. There could be a number of structural reasons for why this hasn't bothered you before, but the NCrunch code involved has been there for years and hasn't changed in a very long time.

I can't speculate as to all the conditions around this because the build system is very complex and it may be reporting the ruleset files selectively. Regardless:
- A defect has been tasked to make NCrunch work with absolute file paths in ruleset files
- I recommend using relative paths in these files. It's cleaner, and will get you around the immediate issue

UppSol;14741 wrote:

ENGINE - [06:45:18.3958-LocalBuildTask-36] ERROR (Internal): System.IndexOutOfRangeException: Index was outside the bounds of the array.
at nCrunch.Compiler.Cil.Symbols.Legacy.CilLegacyPdbDbiStream..ctor(CilAddress address, UInt32 totalStreamCount)
at nCrunch.Compiler.Cil.Symbols.Legacy.CilLegacySymbolsDataSource..ctor(Byte[] pdbFileContent, UInt32 entryPointToken)
at nCrunch.Compiler.Cil.CilAssembly.Load(FilePath assemblyFile, CilContext context)
at nCrunch.Compiler.Cil.CachedCilAssembly..ctor(FilePath assemblyFilePath, CilContext context, Boolean isInstrumentationTarget)
at nCrunch.Compiler.Cil.CilSession.LoadAssembly(FilePath assemblyFilePath, Boolean isInstrumentationTarget)
at nCrunch.Compiler.NewStaticManipulation.BuiltCilAssembly..ctor(FilePath builtAssemblyFilePath, IList`1 adjustedAssemblyReferences, Boolean instrumentForPerformanceMeasurement, ComponentInstrumentationParameters instrumentationParameters, ILogger logger)
at nCrunch.Compiler.RemoteBuildRunner..()
at nCrunch.Common.PerformanceTracking.PerfTracker.TrackActivity(String name, Action activity)
at nCrunch.Compiler.RemoteBuildRunner.(ComponentInstrumentationParameters , BuildOutput , IBackgroundTaskProcessor )
at nCrunch.Compiler.RemoteBuildRunner.PerformPostProcessingOfBuiltAssembly(ComponentInstrumentationParameters instrumentationParameters, BuildOutput output, IBackgroundTaskProcessor backgroundTaskProcessor)
at nCrunch.Core.BuildManagement.BuildEnvironment..()
at nCrunch.Common.PerformanceTracking.PerfTracker.TrackActivity(String name, Action activity)
at nCrunch.Core.BuildManagement.BuildEnvironment.Build(SnapshotComponent snapshotComponentToBuild, IList`1 referencedComponents, GridClientId gridClientId, IList`1 customEnvironmentVariables, IPlatformBuildExtender extender, Guid taskId, GridAddress clientAddress)
at nCrunch.Core.Processing.BuildTaskLogic.DoProcessTaskAndReturnSuccessFlag()
at nCrunch.Core.Processing.TaskLogic.ProcessTaskAndReturnSuccessFlag()
at nCrunch.Client.Processing.LocalProcessingTask.ProcessTaskAndReturnSuccessFlag()
at nCrunch.Client.Processing.ProcessingQueue..()


This exception is very different to the one you reported earlier. It looks to be related to the structure of the PDB file. Is this a new problem you've discovered after switching the paths? Or are you still receiving the previous exception?


This exception started to occur after using the relative path, the exception I've posted before does no longer occur.

Btw there is no pdb file in this path, is the pdb generated by Ncrunch?
Remco
#6 Posted : Thursday, May 28, 2020 12:00:56 AM(UTC)
Rank: NCrunch Developer

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

Thanks: 959 times
Was thanked: 1290 time(s) in 1196 post(s)
upper;14743 wrote:

This exception started to occur after using the relative path, the exception I've posted before does no longer occur.

Btw there is no pdb file in this path, is the pdb generated by Ncrunch?


The PDB file is output from your build system, it's then manipulated by NCrunch to re-align it with the DLL which we instrument for coverage tracking. I'm wondering if the empty project might result in a PDB structure that we're not handling right.

Does the PDB exception appear for you when you set your instrumentation mode to 'Legacy'?
UppSol
#7 Posted : Thursday, May 28, 2020 9:12:03 AM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 3/21/2019(UTC)
Posts: 41
Location: Austria

Thanks: 30 times
Was thanked: 7 time(s) in 7 post(s)
Remco;14744 wrote:
upper;14743 wrote:

This exception started to occur after using the relative path, the exception I've posted before does no longer occur.

Btw there is no pdb file in this path, is the pdb generated by Ncrunch?


The PDB file is output from your build system, it's then manipulated by NCrunch to re-align it with the DLL which we instrument for coverage tracking. I'm wondering if the empty project might result in a PDB structure that we're not handling right.

Does the PDB exception appear for you when you set your instrumentation mode to 'Legacy'?


No the PDB exception does not appear when I set the instrumentation mode to 'Legacy'.

Br
Remco
#8 Posted : Thursday, May 28, 2020 12:12:50 PM(UTC)
Rank: NCrunch Developer

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

Thanks: 959 times
Was thanked: 1290 time(s) in 1196 post(s)
UppSol;14748 wrote:

No the PDB exception does not appear when I set the instrumentation mode to 'Legacy'.


Thanks for confirming this. This would be a compatibility hole in our new CIL system. Is there any chance you can submit this code sample? I can't seem to produce a project/PDB that can do this. You can submit code through the NCrunch contact form.
UppSol
#9 Posted : Thursday, May 28, 2020 1:02:29 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 3/21/2019(UTC)
Posts: 41
Location: Austria

Thanks: 30 times
Was thanked: 7 time(s) in 7 post(s)
Remco;14751 wrote:
UppSol;14748 wrote:

No the PDB exception does not appear when I set the instrumentation mode to 'Legacy'.


Thanks for confirming this. This would be a compatibility hole in our new CIL system. Is there any chance you can submit this code sample? I can't seem to produce a project/PDB that can do this. You can submit code through the NCrunch contact form.


I will try, are the code and dlls enough or do you need a whole sample (solution + csproj) that can be compiled.
Remco
#10 Posted : Friday, May 29, 2020 12:19:30 AM(UTC)
Rank: NCrunch Developer

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

Thanks: 959 times
Was thanked: 1290 time(s) in 1196 post(s)
UppSol;14752 wrote:

I will try, are the code and dlls enough or do you need a whole sample (solution + csproj) that can be compiled.


Ideally, I'll need the whole project in a form that can be compiled. It might be possible to troubleshoot the problem using the DLL and PDB, but there may be other variables here that exist outside of the output binaries.
UppSol
#11 Posted : Friday, May 29, 2020 7:35:16 AM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 3/21/2019(UTC)
Posts: 41
Location: Austria

Thanks: 30 times
Was thanked: 7 time(s) in 7 post(s)
Remco;14755 wrote:
UppSol;14752 wrote:

I will try, are the code and dlls enough or do you need a whole sample (solution + csproj) that can be compiled.


Ideally, I'll need the whole project in a form that can be compiled. It might be possible to troubleshoot the problem using the DLL and PDB, but there may be other variables here that exist outside of the output binaries.


I've sent you a sample project via the NCrunch contact form, please let me know if that's everything you need or if you need more.
br
upper
#12 Posted : Tuesday, June 2, 2020 1:56:06 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 9/21/2016(UTC)
Posts: 31
Location: Austria

Thanks: 8 times
Was thanked: 8 time(s) in 7 post(s)
UppSol;14759 wrote:
Remco;14755 wrote:
UppSol;14752 wrote:

I will try, are the code and dlls enough or do you need a whole sample (solution + csproj) that can be compiled.


Ideally, I'll need the whole project in a form that can be compiled. It might be possible to troubleshoot the problem using the DLL and PDB, but there may be other variables here that exist outside of the output binaries.


I've sent you a sample project via the NCrunch contact form, please let me know if that's everything you need or if you need more.
br


Do you received the sample, took quite some time to upload and I don't know if submitting was ok, got no success or failure info.

Br
Remco
#13 Posted : Tuesday, June 2, 2020 11:27:49 PM(UTC)
Rank: NCrunch Developer

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

Thanks: 959 times
Was thanked: 1290 time(s) in 1196 post(s)
upper;14766 wrote:


Do you received the sample, took quite some time to upload and I don't know if submitting was ok, got no success or failure info.

Br


Doesn't look like it came through :(

I might be able to analyse it off the single source file if you want to try that?
UppSol
#14 Posted : Wednesday, June 3, 2020 4:22:02 AM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 3/21/2019(UTC)
Posts: 41
Location: Austria

Thanks: 30 times
Was thanked: 7 time(s) in 7 post(s)
Remco;14767 wrote:
upper;14766 wrote:


Do you received the sample, took quite some time to upload and I don't know if submitting was ok, got no success or failure info.

Br


Doesn't look like it came through :(

I might be able to analyse it off the single source file if you want to try that?


Here we go, please let me know If you can download the file.
When you're done I will delete the file.

https://drive.google.com...bS8hSr/view?usp=sharing

Br
Remco
#15 Posted : Wednesday, June 3, 2020 5:27:33 AM(UTC)
Rank: NCrunch Developer

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

Thanks: 959 times
Was thanked: 1290 time(s) in 1196 post(s)
Thanks! I have the file. You can remove it now. I'll let you know as soon as I've looked at it in detail.
1 user thanked Remco for this useful post.
upper on 6/3/2020(UTC)
Remco
#16 Posted : Thursday, June 4, 2020 12:09:33 AM(UTC)
Rank: NCrunch Developer

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

Thanks: 959 times
Was thanked: 1290 time(s) in 1196 post(s)
Unfortunately, I haven't had any luck in reproducing the PDB exception using the sample you've provided. It seems that no matter what I do, the projects all build and instrument correctly.

I wonder if there may be an environment difference (i.e. compiler version, something in the build system, etc) that is triggering this.

Is there any chance you could get for me a copy of the DLL/PDB from the NCrunch workspace that is causing the problem for you? You can retrieve this by right clicking on the failing project in the Tests Window, then going to 'Advanced->Browse To Workspace' and finding both the DLL and PDB that are resident in the build output directory. Perhaps I can introduce a speculative fix for this if I can establish what is structurally different about the PDB file.
upper
#17 Posted : Thursday, June 4, 2020 11:29:49 AM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 9/21/2016(UTC)
Posts: 31
Location: Austria

Thanks: 8 times
Was thanked: 8 time(s) in 7 post(s)
Remco;14770 wrote:
Unfortunately, I haven't had any luck in reproducing the PDB exception using the sample you've provided. It seems that no matter what I do, the projects all build and instrument correctly.

I wonder if there may be an environment difference (i.e. compiler version, something in the build system, etc) that is triggering this.

Is there any chance you could get for me a copy of the DLL/PDB from the NCrunch workspace that is causing the problem for you? You can retrieve this by right clicking on the failing project in the Tests Window, then going to 'Advanced->Browse To Workspace' and finding both the DLL and PDB that are resident in the build output directory. Perhaps I can introduce a speculative fix for this if I can establish what is structurally different about the PDB file.


For the projects that are failing to build "by right clicking on the failing project in the Tests Window, then going to 'Advanced->Browse To Workspace" does not work, the file explorer will not open.
If right click on a non failing project in the test window the explorer opens up.

But I navigated manually to the corresponding folder in the file system and created a zip package for you (that contains 2 of the failing projects).
br

https://drive.google.com...tgR1U-J/view?usp=sharing
Remco
#19 Posted : Thursday, June 4, 2020 1:19:49 PM(UTC)
Rank: NCrunch Developer

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

Thanks: 959 times
Was thanked: 1290 time(s) in 1196 post(s)
Thanks! I have the files now. You can remove the link. I'll let you know when I have more information.
upper
#18 Posted : Friday, June 5, 2020 6:07:02 AM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 9/21/2016(UTC)
Posts: 31
Location: Austria

Thanks: 8 times
Was thanked: 8 time(s) in 7 post(s)
upper;14771 wrote:
Remco;14770 wrote:
Unfortunately, I haven't had any luck in reproducing the PDB exception using the sample you've provided. It seems that no matter what I do, the projects all build and instrument correctly.

I wonder if there may be an environment difference (i.e. compiler version, something in the build system, etc) that is triggering this.

Is there any chance you could get for me a copy of the DLL/PDB from the NCrunch workspace that is causing the problem for you? You can retrieve this by right clicking on the failing project in the Tests Window, then going to 'Advanced->Browse To Workspace' and finding both the DLL and PDB that are resident in the build output directory. Perhaps I can introduce a speculative fix for this if I can establish what is structurally different about the PDB file.


For the projects that are failing to build "by right clicking on the failing project in the Tests Window, then going to 'Advanced->Browse To Workspace" does not work, the file explorer will not open.
If right click on a non failing project in the test window the explorer opens up.

But I navigated manually to the corresponding folder in the file system and created a zip package for you (that contains 2 of the failing projects).
br

https://drive.google.com...tgR1U-J/view?usp=sharing


Hi, just to let you know, I removed the custom ruleset.dll from the ruleset file and the 4 projects (that are empty) are still failing to build, so it seems that it's not related to the custom ruleset.dll.

br
1 user thanked upper for this useful post.
Remco on 6/6/2020(UTC)
Remco
#20 Posted : Monday, June 8, 2020 6:38:22 AM(UTC)
Rank: NCrunch Developer

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

Thanks: 959 times
Was thanked: 1290 time(s) in 1196 post(s)
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.194 seconds.
Trial NCrunch
Take NCrunch for a spin
Do your fingers a favour and supercharge your testing workflow
Free Download