All,
It has been a while since I have written a blog item., so it is about time I do that. Here is something that surprised me, and that I had to react to in the middle of the night in a customer call.
The issue boiled down to label specifications not being expanded to the correct label in the selected culture. Instead of generating the correct string that the user has defined, it just yielded a copy of the label name, the behavior we get when the label is not defined. After doing some analysis, it turned out that the customer had a few places where the label he had defined as
"@Model:MyLabel"
was used as
"@Model.Mylabel".
The example is obviously for illustration purposes only.
The model names ("Model" above) are not case sensitive, but the labels ("MyLabel") are. There is a best practice rule that notifies you if there is an undefined label, but the customer either did not run this best practice rule or did not understand the implications.
The old school labels,do not have this problem, they are not case sensitive, so the labels "@Sys12345" and "@sYs12345" are equivalent.
Usually we don't see this issue, because people often use the tooling we have for labels to paste the labels into the code and into the property sheet in Visual Studio. However, sometimes changes are made by hand and this sort of thing can easily happen.
We are looking to make either make this error more prominent in the tooling or making the system tolerant of the case differences. The latter is obviously the better solution (since X++ is case insensitive in most other cases), but also more difficult, and we suspect it will have some impact on the compiler performance.
We will keep you posted as we make progress on this, but at least I have now shared this hard-won little nugget of information.
*This post is locked for comments