Getting started with NAV and .Net Interop – Part 1


The Fear

Since .Net Interop was announced in NAV 2009 R2 there has been an uneasy vibe going around amongst the “developmentally inclined” (new term, just invented). People had heard of this “.Net” thing. They knew it had something to do with programming OUTSIDE of Navision. These are often the same people still insisting on calling it Navision instead of NAV. And, as we all know, any code kept OUTSIDE (shudder) of Navision is A Bad Thing™. It doesn’t help to say it’s somewhat like Automation. Automation is what’s causing those annoying errors when this library or that tool hasn’t been installed on your machine and blocking from testing that feature or simply compiling your code (*cough* Excel Buffer table *cough*).
So no, relating .Net Interop to Automation is NOT a good idea. Or should at least be attempted with care.
Because there are level headed developers out there. They want to get to know this thing people are raving about. But, if you don’t know .Net, how can you start using it?

Getting to know .Net

And that’s where the hurdle lies. Talk to anyone who spent some quality time editing the Excel Buffer table (on a machine with the correct Excel version installed). Once you get over that initial hurdle it is fun tweaking and playing with the Excel Object Model (just stay away from the darker, undocumented parts). The same goes for the .Net Framework, multiplied by 1000.

What IS the .Net Framework and why should you care

So “What is the .Net Framework”? In my own words:
It is a toolbox of classes (with their methods and whatnots) intended to solve recurring problems for you.
Now, you may or may not already experiencing a -what I like to call- “The Aha Moment”. You know, where a lightbulb gets turned on over your head and it starts dawning on you. For those who are still in the dark let me give you a little example:
Say you have a field in Table 311 “Sales & Receivables Setup” called “Export Files Path” containing a path “C:\ExportFiles\”. The intention is that you export a file in there and give it a timestamp. You have a Text[250] variable called FileName all set up with “data 20140513 2317.txt” and all you need to do is put those together. So you do



and export away!
But wait! What if some business consultant with a higher salary then yours and less coding skills decides to change SalesSetup.”Export Files Path” to “C:\RealExportFiles”? See what happened? He forgot to add the trailing backslash! Result: “C:\RealExportFilesdata 20140513 2317.txt”. Now there are several ways you could tackle this:
-          Add an OnValidate to SalesSetup.”Export Files Path” to automatically check if a trailing backslash is present and add one if not found.
-          Join your path and you filename with an additional backslash. Sure, you could get “C:\RealExportFiles\\data 20140513 2317.txt” but Windows will optimize that away.
However, now your export file does not have the exact same path as your variable (a small point I agree, but I mostly don’t like it).
-          Check and add the trailing backslash on the join. Also perfectly valid and safe.
OR, you could define a DotNet variable called Path and do:



The .Net class Path (full name System.IO.Path) has a handy function called Combine that checks what the folder separating character is (‘\’ on Windows, ‘/’ on Linux), checks if either side has one and if not adds it in between before concatenating the strings.
This is why you should care about the .Net Framework. Path alone has a LOT of methods that make Path-manipulation easier, and if you are aware they exist you’re practically there.

And why you should not care

See what I did there? First I write you should care about what the .Net Framework is. And, one chapter later, I tell you there’s a distinct possibility you might not NEED to care (Schrödinger’s caring). Now that’s got to be interesting. This is because the second cool thing about the .Net Framework is that it is required to be installed. It has been since NAV 5.0 required .Net 2.0 to be installed. NAV 2009 required .Net 3.5 and NAV 2013 requires .Net 4.0. That means the bulk of the handy .Net functionality is guaranteed to be installed on every client >= NAV 5.0. Since we’re talking about .Net Interop from NAV 2009 R2 we’re in the clear! And not only that, it comes installed with Windows:
-          .Net 3.5 on Windows 7
-          .Net 4 on Windows 8
It’s also pushed to PC’s with Windows Update. So chances are it’s already going to be installed.
.Net everywhere!

By the way

Some notes:
-          .Net has versions. .Net 4 contains functionality not found in .Net 3.5. So if you look stuff up, be sure to select or filter for your relevant version.
-          By and large all the cool stuff for us was added in .Net 2.0. Except some things like Stream.CopyTo (we’ll get back to that in a later part).
Some URLs:
-          The MSDN Reference for the .Net Framework: http://msdn.microsoft.com/en-us/library/ms229335(v=vs.90).aspx

Reacties

Een reactie posten

Populaire posts van deze blog

Getting started with NAV and .Net Interop – Part 4

Afbeelding
Once more into the breach Jeez, Part 4 already? Last time in Part 3 we imported files using streams and learned a bit more about .Net and our stamina to read boring code. The previous example was a tad bigger than the first one, but now we’ll wrap that into an even bigger example! Exampleception !! Import all files in a folder We have all done this before . When you want to import a file you make a Record variable on the File record. Filter it, loop over it, build your filename, and import it. Something like this: lv_ImportPath := 'C:\Import'; //You get this from Setup or the user of course //Filter lt_Files.SETRANGE(Path,lv_ImportPath); lt_Files.SETRANGE("Is a file",TRUE); lt_Files.SETFILTER(Name,'*.csv'); //Loop IF lt_Files.FINDSET THEN BEGIN   REPEAT     //Build file path and import file   UNTIL lt_Files.NEXT = 0; END; I’ve always found this solution clunky when it works. Sometimes it won’t. We can do better rig...
Meer lezen

Getting started with NAV and .Net Interop – Part 3

Afbeelding
Taking it further After showing in Part 2 how to take the simplest piece of C# code and walk through the process of converting it to C/AL it’s time we crank it up a notch (see what I did there? J ). Importing a single file with streams First off something we’ve all done since Dataports left us and XMLPorts refused to import from a filename directly: lf_File.OPEN(lv_FilePath); lf_File.CREATEINSTREAM(lis_); lx_MyXMLPort.SETSOURCE(lis_); lx_MyXMLPort.IMPORT; lf_File.CLOSE; Opening the stream We can Google for “ c# create stream from file ” and find this page . With that we see we need to use the FileStream class, instantiate it by calling the constructor with some parameters and close it. Not entirely unlike what we do in our C/AL sample… [C#] using System.IO; FileStream fileStream = new FileStream ( @"c:\file.txt" , FileMode .Open); try {   // read from file or write to file } finally {   fileStream.Close(); } Enumerations are a pain i...
Meer lezen