[AL0122][AL0133] Cannot convert from DotNet

[ralf-escher]

Based on Business Central Wave 2 (BC15) we are creating an OnPremises solution which uses an external DotNet functionality (for Barcodes). Until now without problems. Newer AL compiler (sandbox & BC16) showed errors, which now also occurs with Cumulative Update 1.

Business Central Plattform 37769, Application 37793 (BC15, CU1) Microsoft (R) AL Compiler version 4.0.2.62932 (al-4.0.194000.vsix)

We add the external DotNet and Standard DotNet (System.Drawing) in dotnet.al:

dotnet
{
    assembly("TECIT.TBarCode")
    {
        ...
        type("TECIT.TBarCode.Barcode"; "Barcode")
        {
        }
     ...
    assembly("System.Drawing")
    {
        Version = '4.0.0.0';
        Culture = 'neutral';
        PublicKeyToken = 'b03f5f7f11d50a3a';

        type("System.Drawing.Rectangle"; "Rectangle")
        {
        }

        type("System.Drawing.Bitmap"; "Bitmap")
        {
        }
       ...
      }

If we now try to assign the DotNet values by:

local procedure ConvertTBarCodeToBase64Bmp(TBarCode: DotNet Barcode): Text;
var
    Bitmap: Dotnet Bitmap;
begin
    Bitmap := TBarCode.DrawBitmap();

this results in an error: Cannot implicitly convert type 'DotNet "System.Drawing.Bitmap"' to 'DotNet "System.Drawing.Bitmap"' (AL0122)

and:

    local procedure SetBoundingRectangle(TBarCode: DotNet Barcode; width: Integer; height: Integer)
    var
        Rect: DotNet Rectangle;
    begin
        TBarCode.BoundingRectangle := Rect.Rectangle(0, 0, width, height);
    end;

which results in another error: Argument 1: cannot convert from 'DotNet "System.Drawing.Rectangle"' to 'DotNet "System.Drawing.Rectangle"' (AL0133)

Quite important to mention: those errors only show up in Visual Studio Code (starting with BC15, CU1). We create our apps by PowerShell directly with alc.exe (4.0.2.62932) without an error message.

[atoader]

Are you seeing this error for other types?

[ralf-escher]

We are only using one external DotNet and there are only those two assignments between a system library and this external function.

[JohanStenberg100]

Hi @ralf-escher! Thanks for reporting this issue, I'm looking into it. It would be of great help if you could provide a ZIP file with a small repro here. If this is not possible, you can also reach out to me personally on jostenbe<@>microsoft.com if you don't want to discuss in public. Thanks!

[ralf-escher]

@JohanStenberg100 : thanks to your advice to build a repo for this issue, we experienced that it wasn't that easy. Means: we had no errors at the beginning. After using our .vscode/settings.json we found out, that the problem was the usage of the System.Drawing library.

To add the "System.Drawing" assembly we did extend the al.assemblyProbingPaths by C:/Windows/assembly. Upgrading to runtime 4.1 this leads to the described errors. Since we did add the System.Drawing.dll to the .netpackages folder (so we could compile within a docker container) this probing path (C:/Windows/assembly) is no longer necessary which solves our problems.

I would prefer to extend the probing path. But that didn't worked with the container.

[atoader]

Hi @ralf-escher ! The NST automatically searches the following paths: the Add-Ins folder, the server's bin folder, the global assembly cache(GAC) (C:/Windows/assembly on most machines) . As far as I understand, this assembly is in the GAC, so you should not need to extend the probing paths in the container. Is my understanding correct that this issue has been resolved for you?

[ralf-escher]

We are somehow confused. If I remove C:/Windows/assembly from the probing path and the System.Drawing.dll from the .netpackages folder then we get errors that those DotNet elements from System.Drawing couldn't be found (AL0185). If I add the C:/Windows/assembly to the probing path, it can find the System Drawing DotNet elements, but then shows that convert from DotNet error again (AL0122,AL0133).

Therefore I need to add the System.Drawing.dll to the .netpackages folder or do any other solutions exists?

[JohanStenberg100]

Hi again @ralf-escher, we suspect there's an issue when using multiple different versions of a DLL with the same name.

• Your first option will not work, since then you simply don't have the DLL.
• Your second option will probe and likely find a version of your DLL which is not the same version as the one your barcode solution uses.
• If you add the DLL manually, I suspect you pick the correct version and then you don't experience the issue.

You could compare the version of what you are putting into the .netpackages folder and what you can find in your GAC (C:/Windows/assembly), do you see a difference?

[ralf-escher]

I did switch the apperance of C:/Windows/assembly to work like a normal folder to extract the System.Drawing.dll [Stackoverflow]. Therefore it is the same version.

Since you agree to the third option we are happy for the moment. ☺️ (maybe there will be native support for 2D barcodes? :wink:)

[JohanStenberg100]

Good that you were able to unblock yourself! We will still take an extra look on this to make sure you can reliably use the GAC in the future.

Regarding native support for barcodes you can try our ideas forum :).

Thanks again, I'll close this issue now.