search

microsoft / AL

Home of the Dynamics 365 Business Central AL Language extension for Visual Studio Code. Used to track issues regarding the latest version of the AL compiler and developer tools available in the Visual Studio Code Marketplace or as part of the AL Developer Preview builds for Dynamics 365 Business Central.
MIT License
732 stars 243 forks source link

Suggestion: Make property RDLCLayout relative to report file #2682

Open hemisphera opened 6 years ago

hemisphera commented 6 years ago

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.

StanislawStempin commented 6 years ago

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.

hemisphera commented 6 years ago

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
ajkauffmann commented 6 years ago

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.

bjarkihall commented 3 years ago

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

jklassen commented 2 years ago

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.

bjarkihall commented 2 years ago

The solution to our case was to use pragma directives to switch between paths (which were released after my last comment).