Empty Test .csproj fails to build

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/file/d/11e3O_sZPiosD_cdm_pnojWwUXYPvCUkQ/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.

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?

Remco 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

UppSol 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 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?

Remco wrote:

UppSol 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 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?

upper 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'?

Remco wrote:

upper 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

UppSol 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.

Remco wrote:

UppSol 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.

UppSol 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.

Remco wrote:

UppSol 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

UppSol wrote:

Remco wrote:

UppSol 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

upper 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?

Remco wrote:

upper 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/file/d/10n_nv-6ILh-YluR4OyRXXmd4kybS8hSr/view?usp=sharing

Br

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.

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.

Remco 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/file/d/1oLAZQ39dtfJglDo_Z7qF-3mEPtgR1U-J/view?usp=sharing

Thanks! I have the files now. You can remove the link. I'll let you know when I have more information.

upper wrote:

Remco 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/file/d/1oLAZQ39dtfJglDo_Z7qF-3mEPtgR1U-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

Thanks for your patience with this issue. Would you be interested in trying the build below? It contains a targeted fix for the PDB related exception under optimised mode:

NCrunch_Console_4.4.0.10.msi
NCrunch_Console_4.4.0.10.zip
NCrunch_GridNodeServer_4.4.0.10.msi
NCrunch_GridNodeServer_4.4.0.10.zip
NCrunch_LicenseServer_4.4.0.10.zip
NCrunch_VS2008_4.4.0.10.msi
NCrunch_VS2010_4.4.0.10.msi
NCrunch_VS2010_4.4.0.10.zip
NCrunch_VS2012_4.4.0.10.msi
NCrunch_VS2012_4.4.0.10.zip
NCrunch_VS2013_4.4.0.10.msi
NCrunch_VS2013_4.4.0.10.zip
NCrunch_VS2015_4.4.0.10.msi
NCrunch_VS2015_4.4.0.10.msi.7z
NCrunch_VS2015_4.4.0.10.zip
NCrunch_VS2017_4.4.0.10.msi
NCrunch_VS2017_4.4.0.10.msi.7z
NCrunch_VS2017_4.4.0.10.zip
NCrunch_VS2019_4.4.0.10.msi
NCrunch_VS2019_4.4.0.10.msi.7z
NCrunch_VS2019_4.4.0.10.zip