Closed tfenster closed 11 months ago
@tfenster - can we get a more minimal repro for this?
@thloke I have no idea how I would narrow it down. Compiling works for a regular extension but gives this error for the base app. How would I even try to find out how I can narrow it down? Any ideas?
Looks like a dotnet reference resolution problem for a dotnet type used in AL. Probably loading mscorlib.
@thloke @kalberes any ideas how I can find out what the root cause for this problem is?
@tfenster You could also share your whole repository (not publicly here on GitHub, of course). I did that a couple of times earlier as well.
Happy to do that if @thloke or @kalberes would take a look
@thloke, I have a similar issue again. I have:
When I then open the workspace, for a very long time I see
After ~ 20 minutes, I get
The AL extension output shows ~ 10 times this
Any ideas? I'd be happy to give you access to the repro VM or privately share the workspace with you. I have used both the current AL extension release and the latest pre-release, same behaviour
@tfenster
We do have the same problem with our baseapp. We cant package it with the same stack overflow in the cecil-thingie, The problem is still there in BC 22 CU 3
our workaround is to set the assembly probing path in vs code to exact this 3 and throw away all other probing pathes.
"C:/Program Files/dotnet/shared/Microsoft.AspNetCore.App/6.0.18", "C:/Program Files/dotnet/shared/Microsoft.NETCore.App/6.0.18", "C:/Program Files/Microsoft Dynamics 365 Business Central/220/Service"
Cave: the order of the assembly probing pathes is relevant and must not be changed!!!
Also we do press the button cancel on the "loading workspace - preparing project"- message
it seems to me that the Al Language extension parse to much files/dotnet components and an internal array flows over
P.S.: Also Greetings to David F., I hope he likes his new job,we miss him here
@kalberes @qutreson Any update on this? Can I do anything to help?
@tfenster Microsoft Support contacted me today regarding the support case i opened with link to the issue I provided the information that it started first with BC 22 when packaging a baseapp. Before with BC 21 and earlier it worked fine to package a baseapp
@MBGWS thanks for sharing, then maybe we'll see some progress :)
@tfenster Issue will be solved in a minor Update of BC 22, hopefully the next
Issue is solved with BC 22 CU 6 OnPrem (Build 22.0.60864.0)
With the Workspace-Path set to "al.assemblyProbingPaths": [ "C:/Program Files/dotnet/shared/Microsoft.AspNetCore.App/6.0.22", "C:/Program Files/dotnet/shared/Microsoft.NETCore.App/6.0.22", "C:/Program Files/Microsoft Dynamics 365 Business Central/220/Service" ]
our Baseapps are packaged successfully everytime
@MBGWS - Thank you for confirming the issue is fixed.
@tfenster - Is the issue also resolved for you?
yes! I didn't try with 22, but 23 works and that is good enough for me. Thanks
1. Describe the bug I try to open a workspace with a modified base application locally, but get an internal error and don't know where to start looking for possible
2. To Reproduce Steps to reproduce the behavior:
3. Expected behavior The workspace should successfully load or give me a meaningful error message what is missing
4. Actual behavior I get the following error:
5. Versions:
Final Checklist
Please remember to do the following:
[X] Search the issue repository to ensure you are reporting a new issue
[X] Reproduce the issue after disabling all extensions except the AL Language extension
Simplify your code around the issue to better isolate the problem --> Don't know what to do there...