Before you start working on C# as a Dynamics NAV developer, or as
some call us Dinosaur, you need to be aware of the differences in
approach.
Database driven development
In Dynamics NAV we are used to develop in a “database”. This used to
be a native “fdb” file in the old days and nowadays it’s a SQL Server
database. The development we do is a combination of coding and defining
metadata.
More than one developer can work in the same database and we can move
parts of our code from one system to another using binary files we call
“fob”.
File driven development
When working on a piece of C# code in Visual Studio you’ll probably
work in what they call a “project” or “solution”. This is usually a
folder somewhere on your drive with a bunch of files. To start working
on a solution you have to open the “.sln” file which will give visual
studio the information it needs. In the simples scenario where you
develop a piece of C# code for Dynamics NAV your solution will have a
“.cs” file that contains the actual C# code. You can compare this file
to a Code Unit in Dyanamics NAV. Visual Studio will also generate a
bunch of other files that you can ignore for now.
Compiling
Compiling in Dynamics NAV is called Build in Visual Studio. Both
features check the code for errors and generate “stuff”. The stuff in
Dynamics NAV is (funny enough) generating the C# from the C/AL and
binding it into the other objects. The stuff in Visual Studio is
generating the DLL file that you will use in Dynamics NAV as a DotNet
library.
Versioning
Both Dynamics NAV and Visual Studio do not offer object versioning by default.
Team Foundation Server
When working together on a larger Visual Studio C# project you can
use TFS, or Visual Studio Online to manage tasks and versions of your C#
files.
TFS is text based, like Visual Studio and does not understand the
structure of Dynamics NAV and its binary objects that are stored in a
SQL Server Database.
You can use TFS manually with the Text files you can export from
Dynamics NAV, but there is no automatic interface. There are some third
party tools that provide help with that.
Let’s get started: “Hello World”
So having explained the differences, let’s start working on a very
simple C# project. We will start with a good old “Console Project”.
After having started Visual Studio we will generate a new project like this:
And then we get “the list” that confuses most people that get started with Visual Studio and makes you unsure.
Lets discuss what we see here
On the right there is a bunch of templates. Ignore everything you see
here and only go to Visual C# and Windows. Within this menu we have
three types of projects that we will use in this series: Console
Application, Windows Forms Application and Class Library. We will now
choose “Console Application”.
On top we can choose the version of DotNet we want to use. Dynamics
NAV uses 4.5 so we know that our users will have that installed and can
go ahead and use this version.
Then we can select a name and location for our project. We choose “Hello World” and leave the folder to default.
On the far right bottom you can see the “golden” option “Add to
source control” which will register the solution on TFS or Visual Studio
Online system. We will not do that for this example.
The “main” function
When Visual Studio has generated the project we get this window:
Let’s talk through them
First we see a bunch of “using” lines. These are the DotNet libraries
that will be used by this project, which can be compared by using Code
Units in Dynamics NAV that contain functions you use accross the
application, if you don’t define the Code Unit you cannot use the
function. We’ll get back to that later in the series.
Then we see the namespace of our project. You can compare this to the
Add-On number bands in Dynamics NAV, every project or customer get’s
their own Namespace. During our series we will not change the
namespaces, just leave it as it is.
Within the namespace we see a class. This can be compared to a object
in Dynamics NAV, a logical group of code or features. You can put
everything in one class like in a Code Unit but that would not be
maintainable
Lastly we see what is most important
static void Main(string[] args)
This is a function. It is very important to understand the syntax of a
function. Unlike Dynamics NAV where we define functions as metadata we
can define functions in C# by just typing in new text. We can break down
this line into four parts
static
This defines how the function can be used. We will need this when we
start working on DLL files that we use in NAV. Functions can be
Static,
Public &
Private. Comparable to using local functions in Dynamics NAV or Single Instance codeunits.
void
This is the return value. Void means no return value. Like Dynamics NAV a function can only have one return value
Main
This is the function name. Main is a reserved name that can be
compared with Codeunit 1 in Dynamics NAV. The program starts here and
always passes this code.
(string[] args)
These are the parameters of the function. In this case the function accepts an array (
[] means array) of strings.
Hello World
Now that we know what we see here we can add some code to our function Main and test if it runs.
Since we have a console application we can write to the console. Lets add these lines:
Console is a variable we can use like DIALOG in Dynamics NAV. This will display “Hello World” and wait for user input.
Console.ReadKey();
Please note that even though we are not passing values to the ReadKey
we still have to provide the (). When you start writing C# this will
make you go bananas and if you forget them you get a really weird error
like this:
So never forget them!
Let’s run the thing alright!
This is what you get when you press the Start button.
Congratulations you have just created your very first C# application
and learned about a lot of differences between Dynamics NAV and Visual
Studio.
**Reference taken from the original post of
Mark Brummel.
Regards,
Sathish
http://sathish-nav.blogspot.com
