[Bug]: LinterCop pre-release cannot be used with AL-Go for nextmajor - AL1005 Unable to load Analyzer assembly

[jwikman]

AL-Go version

7.3

Describe the issue

This issue was first registered here: StefanMaron/BusinessCentral.LinterCop#1149

It seems as when running AL-Go on nextmajor, with latest pre-release version of compiler (the only option if you want to use LinterCop on a nextmajor), LinterCop cannot be loaded any longer.

One workaround seems to be to rename the file from BusinessCentral.LinterCop.AL-PreRelease.dll to BusinessCentral.LinterCop.dll, but AL-Go does not support this...

Settings being used:

                "customCodeCops": [
                    "https://github.com/StefanMaron/BusinessCentral.LinterCop/releases/latest/download/BusinessCentral.LinterCop.AL-PreRelease.dll"
                ],
                "vsixFile": "preview"

From the logs:

Compiling...
  Downloading C:\build\vsix\extension\bin\Analyzers\BusinessCentral.LinterCop.AL-PreRelease.dll
  .\alc.exe /project:"c:\sources\App" /packagecachepath:"c:\sources\.packages" /out:"c:\sources\.output\NAB Solutions AB_Test CI_26.1.49.2.app" /analyzer:C:\build\vsix\extension\bin\Analyzers\Microsoft.Dynamics.Nav.Analyzers.Common.dll /analyzer:C:\build\vsix\extension\bin\Analyzers\Microsoft.Dynamics.Nav.CodeCop.dll /analyzer:C:\build\vsix\extension\bin\Analyzers\Microsoft.Dynamics.Nav.AppSourceCop.dll /analyzer:C:\build\vsix\extension\bin\Analyzers\Microsoft.Dynamics.Nav.UICop.dll /analyzer:C:\build\vsix\extension\bin\Analyzers\BusinessCentral.LinterCop.AL-PreRelease.dll /ruleset:c:\sources\App\.vscode\nab.ruleset.json /SourceRepositoryUrl:https://github.com/nabsolutions-product/TEST-CI /SourceCommit:2e026f97659800eac919268a9b5e9373553cc826 /BuildBy:AL-Go for GitHub,v7.3 /BuildUrl:https://github.com/nabsolutions-product/TEST-CI/actions/runs/17577596931 /assemblyprobingpaths:"C:\Program Files\dotnet\shared","C:\ProgramData\BcContainerHelper\Extensions\bc17577596931\.netPackages\Service"
  Microsoft (R) AL Compiler version 17.0.26.46427
  Copyright (C) Microsoft Corporation. All rights reserved
  
  Compilation started for project 'Test CI' containing '5' files at '11:55:54.610'.
  
  Warning: AL1005  Unable to load Analyzer assembly C:\build\vsix\extension\bin\Analyzers\BusinessCentral.LinterCop.AL-PreRelease.dll : Unable to load BusinessCentral.LinterCop
  
  Compilation ended at '11:56:00.905'.

Expected behavior

LinterCop should be able to load also on new compiler

I see two different options here:

1. Figure out why the file name must be the same as the assembly name nowadays, and maybe change that?
2. Add support to AL-Go to be able to rename the custom code cop file after download.

Steps to reproduce

Use settings

                "customCodeCops": [
                    "https://github.com/StefanMaron/BusinessCentral.LinterCop/releases/latest/download/BusinessCentral.LinterCop.AL-PreRelease.dll"
                ],
                "vsixFile": "preview"

Run nextmajor pipeline
You should get the error above.

Additional context (logs, screenshots, etc.)

No response

[aholstrup1]

I'm not sure there's much we can/should do from the AL-Go side here. 2) sounds like a workaround to mask the actual issue so I think we should start by figuring out why this it is failing.

Typically, these compiler/analyzer related issues are handled via https://github.com/microsoft/AL

Can I get you to create an issue on there? I can also transfer this one if you prefer that.

[jwikman]

@aholstrup1, now I've created microsoft/AL#8105

Please nudge any friendly colleague on the compiler team if possible. ;-)

Hopefully we get an explanation on why this is happening soon, so we can figure out a way forward.

[nickgoddard777]

I had a similar issue and had to set my NextMajor test to use the latest vsixFile, see my setting below. I can't find the article I read that said this needed to be set.

{ "workflows": [ "Test Next Major" ], "settings": { "vsixFile": "default" } }

[jwikman]

@nickgoddard777 that does not work for me. Does it for you, with latest BC27?

[jwikman]

@aholstrup1 I know you tagged this as "unrelated to AL-Go", but we have no workaround outside of AL-Go. And since LinterCop is widely used, I think we need to find a solution for this.
I'm just surprised that (almost) no-one else is having this issue, but I guess they just disable LC and hopes that time will solve this...

I can do a PR with a proposed solution to this, if you think it's a good idea?

But I have to admit that I have not dived too deep into this, maybe I need to do a PR to BcContainerHelper first.

[aholstrup1]

@jwikman I've pinged our developer tools team internally to see if we can get some clarity around this first before we move forward.
Ideally, I would really love to not have such a temporary workaround within AL-Go/Containerhelper.

Could another temporary workaround be to upload the file with the right filename somewhere and update the customCodeCops setting to point to that location?

[jwikman]

Thanks @aholstrup1,
If it is by design (and maybe for some new security reason?) I still believe that we should support this in AL-Go/Containerhelper, and not rely on workarounds.
It might not even need a new setting; we could probably figure out the correct naming of the file by looking inside it.

But first, let's see what they say before doing anything.