Navigate Into Success: C# Injection: Don’t trust FOB

[Blog bot]

Источник: http://vjeko.com/c-injection-dont-trust-fob/
==============

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.

Read this post at its original location at http://vjeko.com/c-injection-dont-trust-fob/, or visit the original blog at http://vjeko.com. 5e33c5f6cb90c441bd1f23d5b9eeca34The post C# Injection: Don’t trust FOB appeared first on Vjeko.com.




Источник: http://vjeko.com/c-injection-dont-trust-fob/