Al: Refactor does not always work on extensions that depend on the one refactored

[salgiza]

Describe the bug
Lets say that you have a VS Code workspace with two apps: A & B.
App B extends app A (eg. a test extension, a localisation for a particular country...)
A has a method GetWhatever() that is referenced multiple times from B.
If you refactor method GetWhatever() using F2 from VS Code... sometimes it also updates references in app B, sometimes it doesn't (most of the time it does not).

To Reproduce
Create two apps like previously mentioned (A, B, one method in A that is called from B), in a common workspace.
Restart VS Code.
Refactor the method name using F2.
App B still references the old method name.

Expected behavior
The refactor action should find any references to the field/method/x, in any AL app in the current workspace.

5. Versions:
AL Language: 5.0.271898

[NKarolak]

B gets updated only if the project reference is correctly set, hence the B's app.json is referencing the exact A version. It is not possible to define any lower version.

[NKarolak]

I've just had the phenomenon that despite my correct settings, the connection between my two apps was obviously lost: F2 did not update the B app anymore.
Reason for it seemed to be a rename of objects in the A app directly before. To solve it, I needed to publish the A app separately again, next the B app, and after that both were in sync again. Sometimes, a Reload Window allone does the trick already.

[salgiza]

Yep, we checked and we have the correct version specified in app.json.

I kind of get the feeling that this bug partly depends on whether you have opened files from both projects in the UI (but I don't know for sure).

I mean: I don't get warnings in a workspace on projects that I haven't opened yet, like if the AL analyzer did not detect AL projects in the workspace until you opened a file in the editor, and it wouldn't surprise me if this things were related, even though I'm not sure if there are more situations that trigger the bug.

[NKarolak]

@kalberes Could you shed some light on this?
The online help article mentions in the note box that the reference resolution might stop working, but we don't know why.

[kalberes]

Opening a project means opening an AL file in the project, which will start the background compilation tracking process. Symbols can be harvested as a consequence and reference resolution completed.
When you open a workspace having project dependencies, then not all projects will be loaded by the AL language server.
If you have _test-> base_ for example. If you open _base_ that will not open _test_.
If you open _test_ that will open _base_.
If you do a rename refactoring when _test_ is not opened references will not resolve and you will get compilation errors.

[salgiza]

@kalberes While I understand that this might be due to the way VS Code handles projects, wouldn't it be possible to load all AL projects when a workspace is loaded?

At least, maybe someway to specify it in the .workplace file? (Or a VS Code command to do so)

I don't know how other partners organise workspaces but, for us, if two AL projects are in the same workspace, it's because they are related. And usually it's because we have a "core" app plus one extra (usually very small) app which extends it with localisations for each country that we support, in addition to tests for all of them.

That means that, every time we do changes to the core app (which is were most of the code is) we should open an AL file in very single country/test project before doing so, in order to avoid errors. Say we had localisations for 10 countries + tests + core + core tests = 22 projects. I don't see that scaling...

[kalberes]

VsCode does not have a concept of project. This is by design to limit the memory surface working with a base app kind of solutions with all their tests.
I think it makes sense to have an option to forceload the whole workspace.
You should probably create a suggestion to have an option to force-load the whole workspace.

[salgiza]

Suggestion created: https://experience.dynamics.com/ideas/idea/?ideaid=60803f9d-b2a0-ea11-8b71-0003ff68d920

[AndreyKorepanov]

So, as the suggestion is on place I am going to close this issue. We will put it on our roadmap and implement asap. Thank you for reporting the issue!