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
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.
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)
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
very informative, thanks a lot for this post.
ReplyDelete