Breaking news from around the world
Get the Bing + MSN extension
Now Available in Community - MBAS 2019 Presentation Videos
Catch the most popular sessions on demand and learn how Dynamics 365, Power BI, PowerApps, Microsoft Flow, and Excel are powering major transformations around the globe. | View Gallery
2019 release wave 2 Discover the latest updates to Dynamics 365Release overview guides and videos Release Plan | Early Access Availability
Ace your Dynamics 365 deployment with packaged services delivered by expert consultants. | Explore service offerings
Connect with the ISV success team on the latest roadmap, developer tool for AppSource certification, and ISV community engagements | ISV self-service portal
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance TechTalks | Customer Engagement TechTalks | Talent TechTalks | Upcoming TechTalks
FOBs, those pesky little files that we all take for granted, import into our databases, and live happily ever after. After you read this post, you’ll handle FOB files very, very carefully.
Why is that? Well, if you haven’t already, then read this post first: From C/AL to executable: how NAV runs your C/AL code
Good, now that we are on the same page, let me explain why you must never, ever, ever trust a FOB file.
If you are simply curious, then download this FOB here: HelloWorld.fob.
Good, now go to your development environment, import it, and then find codeunit 87654 Hello, World!
Good, now design this codeunit and take a look at what it contains:
Not much, eh?
Now, close the designer, make sure not to save the object, simply close and cancel saving. It is crucial at this stage not to save or compile this object.
Good, now run this object.
Starts off well, but then quickly develops into quite a dialog between you and some ghosts that come from who knows where.
See? That’s why you must never, ever trust FOB.
Now, compile that codeunit.
Good, now run it again. And it shows only a single message, as expected.
What’s going on here? It’s simple. I have created a codeunit which has more C/AL code than you see in your C/AL editor. Then, I have exported the content of the User Code field from Object Metadata table into a C# file. Then, I have produced the codeunit with only a single MESSAGE that shows “Hello, World!”. Then, I have imported the C# file I exported earlier into the same record of the Object Metadata table.
What I have at this point is an object with a mismatch between C# and C/AL. And as I said, once the object is marked as compiled, C/AL is ignored by everything, and it’s C# that matters. If I export the FOB now, and you import that FOB, you get exactly the same situation: C/AL code contains something, which is completely irrelevant, while C# code contains anything that the FOB author cared about injecting in your object. And know what? If you don’t compile the imported objects, NAV will simply use the C# that it finds in the User Code field. And that’s where all those messages and confirmation dialogs in this FOB you downloaded come from.
Now, I am not saying this to give you an idea how to inject your stuff into FOB files that you ship around. I am writing this to warn you about dangers that FOB files bring with themselves and that you adopt a practice of not using FOB files for transferring the data around.
Instead, you should use text files. A text file contains only C/AL code, and after importing you must compile the imported objects first to generate the C# code.
However, a better approach is to simply ship delta files. You can use PowerShell to create them, and to import them, and then to remove the customizations if you don’t need them. Just like Waldo explains in his fantastic blog post: Apply-NAVDelta to add and remove customizations.
FOB, not good. TXT, good. DELTA, the best.
The post C# Injection: Don’t trust FOB appeared first on Vjeko.com.
Business Applications communities