AL
AL copied to clipboard
microsoft
Suggestion: Make property RDLCLayout relative to report file
The path specified in the property RDLCLayout of a report should be relative to the file of the report itself instead of being relative to the root folder of the entire extension.
That's a good point. We will consider what we can do here. Just changing it would mean it's a breaking change that would cause existing RDLCLayout values to be incorrect.
You could allow us to prefix it with something that indicates if it is relative to the app.json or relative to the report itself. I think that both 'methods' could be useful. Something like ... I don't know
RDLCLayout = '.\Layout.rdl' // relative to report
RDLCLayout = 'Layout.rdl' // relative to app.json
Just stumbled over this one.
According to the documentation the RDLC file must be in the same folder as the report AL object. Which is incorrect as far as I know, the location is relative to the root. See: https://docs.microsoft.com/en-us/dynamics365/business-central/dev-itpro/developer/properties/devenv-rdlclayout-property
Please be careful with changing this. There are more places where you have to point to a file with a relative path. E.g. including javascript files and css files in control addins.
@StanislawStempin I noticed MS had some trouble in the ALAppExtension repo with the relative controladdin paths, since it needs to open vscode on different folder levels and relative paths therefor break.
An example would be if you have "System Application", where every .al file can be compiled/published together but if you're only working on the Blob "Module", you can open it in a multi-root workspace and only compile/publish these files.
The solution there was to copy-paste the exact same code into at least two places (e.g. OAuthintegration.js is in 3 places) - this could also be automated by tracking only the highest folder in git and then propagating it down to a gitignored folder via some script. @JesperSchulz mentions a logged bug in the workaround commit, but this is the most closely related issue I found.
Have you considered allowing settings.json to define where the root of relative paths should start? You already support that for .netpackages (al.assemblyProbingPaths) and .alpackages (al.packageCachePath). A similar setting like al.relativeRootPath could allow you to start from "../../" for example or even an absolute path "C:\mylayouts\", where RDLCLayout = './mylayout.rdlc' could reside or StartupScript = './startup.js'.
I believe this would make this pattern much easier and cleaner, at least.
Just following up on the status of this.
@bjarkihall I am not the biggest fan of having the settings.json determine the location of the RDLCLayout root relative path. Unless that value in settings.json would eventually becomes default it seems like it could be headache of its own. If it can be independently defined in the AL report file it would allow for no adjustments needed when sharing and migrating a reports folder from one person/project.
The solution to our case was to use pragma directives to switch between paths (which were released after my last comment).