Compiler warnings. Warnings. They’re not errors, only warnings. You can just overlook and forget them, right? Well, I hope you aren’t.
“But even the standard code done by Microsoft throws warnings!”, you could say. And that’s true, but that’s not your code, it’s Microsoft’s. If a functionality you’re using breaks because they didn’t care about their warnings, you can open a support request and it’s Microsoft’s job to fix it. If your code breaks some functionality because you didn’t care about a warning, it’s your job to fix it, and your customer will want it as fast as you’d want Microsoft to fix their error.
That’s why we should be warned about warnings (badum tss).
Warnings
So, why should we take care of warnings? Because they warn us that something could go wrong. The best example could be deprecated features, methods or metadata:
After a period of at least 12 months, Microsoft might delete obsolete methods and metadata elements.
https://docs.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/migration-upgrade/deprecation-deletion-apis#cleanup-of-deprecated-elements
This is a good example. However if Microsoft’s telemetry shows these methods are in use, they won’t delete them, but you’ll get a warning and should fix it.
What if you don’t care? You could be in a situation where your code compiles but it’s not working as expected. A long time ago the postTrans method of class LedgerJournalCheckPost was marked as obsolete and warned you to use the postTransV2 method.
This happened. To me. The customer told me that something stopped working. I checked my extension class and everything looked fine, but my CoC method was never being called. I looked at the call stack and saw that the standard was now calling the V2 method and my code was not being run. It compiled but it didn’t work.
Other changes like methods or classes being changed to internal should be watched carefully too. At some point they can be converted into an error instead of a warning and your code will stop compiling (and working).
(Not so) Crazy example
Sometimes a crazy example is the best to show what one means, because it’s extreme and will probably not happen. Or it might happen, nobody expected to be in the situation we’re right now and look at us…
I know MS says they won’t remove any code if it’s being used, but IMAGINE you don’t see the deprecation warning and after a year it’s gone. The good thing is you probably have implemented a nice MSDyn365FO Dev ALM strategy and you’ll detect it on your continuous build pipeline (but I’m seeing a lot of projects without it so…).
Hey, and with One Version and unmaintained projects this could perfectly happen!
Now imagine worse, the method is not removed but its code is. An empty method with the SysObsolete attribute telling you to use another method. If you don’t check the warnings you’ll never see it and your changes will stop working because you extended the obsolete method. And this extreme case would not even be detected by a nice Dev ALM…
What I’m trying to say with this example is that if you keep ignoring all the warnings because, “Dude relax, it’s just a warning!”, you’ll end up with so many warnings that, one day, you’ll miss the ones that are really, really, really important and in the end will break your code.
Lesser (evil) warnings
Of course what I just described shouldn’t happen, and the kind of warnings you’ll usually get are from casts losing precision, numerical values in extensible enums and things like this.
Then there’s the XBOX warning we’re all getting when developing in X++:
Assembly 'Microsoft.Xbox.Experimentation.Contracts, Version=1.0.0.0, Culture=neutral, PublicKeyToken=d91bba2b903dc20f' failed to load because it was not found.What is this? Why is an ERP trying to use that namespace? Will we get a gamified version of Dynamics 365 where users earn points when they use the ERP as we expect? What will happen when they arent and have negative points?
But jokes aside, you still should try to fix them if you can, because that will make your code nicer, and of better quality. And maybe if in the future someone with an OCD is modifying your code, and you’ve changed jobs and are not there, you want that person to keep his sanity. Do it, please.
Some help
Remember that we have Application Checker available to check other quality metrics.
And also go check Vilmos Kintera‘s post about intepreting VS compiler results using PowerShell.
