AL-Go icon indicating copy to clipboard operation
AL-Go copied to clipboard

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

Open jwikman opened this issue 3 months ago • 7 comments

AL-Go version

7.3

Describe the issue

This issue was first registered here: https://github.com/StefanMaron/BusinessCentral.LinterCop/issues/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

jwikman avatar Sep 15 '25 21:09 jwikman

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.

aholstrup1 avatar Sep 16 '25 06:09 aholstrup1

@aholstrup1, now I've created https://github.com/microsoft/AL/issues/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.

jwikman avatar Sep 16 '25 08:09 jwikman

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" } }

nickgoddard777 avatar Oct 01 '25 11:10 nickgoddard777

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

jwikman avatar Oct 01 '25 14:10 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.

jwikman avatar Oct 07 '25 13:10 jwikman

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

aholstrup1 avatar Oct 09 '25 06:10 aholstrup1

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.

jwikman avatar Oct 09 '25 06:10 jwikman