Rash thoughts about .NET, C#, F# and Dynamics NAV.

"Every solution will only lead to new problems."

Category English posts

Sunday, 14. February 2010

“FAKE – F# Make” 0.29 released – Ready for F# February 2010 CTP and .NET 4.0 RC

Filed under: English posts,F#,FAKE - F# Make — Steffen Forkmann at 16:56 Uhr

Last week I released version 0.29 of my build automation tool “FAKE – F# Make”. The new version comes along with a couple of changes which I will now describe.

F# February 2010 CTP and .NET 4.0 RC

“FAKE – F# Make” should be completely compatible with both, the F# February 2010 CTP and the F# version which is included in Visual Studio 2010 RC.

FAKE self build and binaries on teamcity.codebetter.com

Since “FAKE – F# Make” is a build automation tool, it was always used for it’s own build process. Now this build process could be moved to an open CI server at teamcity.codebetter.com. If you login as a guest you can download the latest “FAKE – F# Make” binaries from there.

FAKE on build servers without F#

With the new F# CTP there is no longer a need for installing F# on the build agents. In fact FAKE itself was built on build agents which don’t have a F# installation.

If you want to create such build scripts you have to do the following:

  1. Download the standalone zip file of the F# CTP
  2. Put the bin subfolder into your project tree
  3. Modify the FSIPath value in the FAKE.exe.config file to match your FSharp bin folder
    1. If you copy the contents the F# bin folder into ./tools/FSharp/ it should just work.

If you have F# projects you also need to modify your .fsproj files like this:


<Import Project="..\..\..\tools\FSharp\Microsoft.FSharp.Targets" />

This modifications should take care that MSBuild will use the F# compiler from your tools paths.

Generate your documentations with “docu”

“What’s a docu? A documentation generator for .Net that isn’t complicated, awkward, or difficult to use. Given an assembly and the XML that’s generated by Visual Studio, docu can produce an entire website of documentation with a single command.” [docu Homepage]

“FAKE – F# Make” 0.29 is bundled with this new documentation tool which can easily convert your xml-Documentation into some nice html pages. You can use the tool with the new Docu task like this:

Target? GenerateDocumentation <-

    fun _ ->

        Docu (fun p ->

            {p with

               ToolPath = @".\tools\FAKE\docu.exe"

               TemplatesPath = @".\tools\FAKE\templates"

               OutputPath = docDir })

            (buildDir + "MyAssembly.dll")

You will also need the docu templates, which you can download from the product homepage. I’m planning to bundle some basic templates with the next version of FAKE.

What’s next?

At the moment I’m working on ILMerge task for FAKE. I hope to release this with the next version. There are also some open issues with the Mono support but since teamcity.codebetter.com is getting a mono build agent I hope to make some progress here too.

If you have any questions or ideas for new features please contact me.

Tags: , ,

Monday, 8. February 2010

New syntactic sugar for “FAKE – F# Make” – Getting rid of magic strings

Filed under: English posts,F#,FAKE - F# Make — Steffen Forkmann at 17:58 Uhr

The new version 0.27 of “FAKE – F# Make” comes with new syntactic sugar for build targets and build dependencies. Don’t be afraid the old version is still supported – all scripts should still work with the new version.

The problem

Consider the following target definition:

let buildDir = "./build/"


Target "Clean" (fun _ ->

  CleanDir buildDir



Target "Default" (fun _ ->

  trace "Hello World from FAKE"



"Default" <== ["Clean"]


run "Default"

As you can see we are having a lot of “magic strings” for the target names and the dependency definitions. This was always a small shortcoming in FAKE, since this doesn’t allow refactoring and may result in runtime errors.

One of my goals for “FAKE – F# Make” is to remove these strings in future versions. Unfortunately this is not that easy, because it causes a lot of internal issues. In particular logging to the build server is much harder if you don’t have a target name.

The first step

As posted in a bitbucket comment by cipher we could use the “dynamic lookup operator” to remove some of the magic strings without breaking any internal code.

As a result we can rewrite the above sample as:

let buildDir = "./build/"


Target? Clean <-

    fun _ -> CleanDir buildDir


Target? Default <-

    fun _ -> trace "Hello World from FAKE"


For? Default <- Dependency? Clean


Run? Default

All magic strings suddenly disappeared. I think this syntax looks really nice, but unfortunately the strings are not really gone, since the token Default is only checked at runtime.

The idea for future versions

Since the new syntax is really just syntactic sugar I’m always interested in a better solution. Currently I’m working on a syntax using monads. The result could look like this:

let buildDir = "./build/"


let Clean = target { CleanDir buildDir }

let Default =

  target {

    trace "Hello World from FAKE"

    trace "Another line"



Default <== [Clean]

Run Default

This way the magic string are really gone, but my current problem is retrieving the target name from the let-binding name. Please leave a comment if you have an idea to solve this issue.

Tags: , ,

Monday, 24. August 2009

SOLID Part I – The Open/Closed-Principle – C# vs. F#

Filed under: C#,English posts,F#,Veranstaltungen — Steffen Forkmann at 11:43 Uhr

Friday I attended the .NET BootCamp “NHibernate vs. Entity Framework” in Leipzig and as always it was a pleasure for me being there. Afterwards I had a nice talk with my friend Alexander Groß about the Open/Closed Principle. I didn’t really care about this principle before, but now I think it’s really a nice idea:

“In object-oriented programming, the open/closed principle states "software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification"; that is, such an entity can allow its behaviour to be modified without altering its source code.”


If we follow this principle we get lot’s of small and testable classes. I want to demonstrate this with a simple spam checker for mails.

Let’s say our mail class has only a sender, a recipient, a subject and the mail body:

public class EMail


    public string Sender { get; set; }

    public string Recipient { get; set; }

    public string Subject { get; set; }

    public string Body { get; set; }


    public EMail(string sender, string recipient,

        string subject, string body)


        Sender = sender;

        Recipient = recipient;

        Subject = subject;

        Body = body;




public enum SpamResult






Now we want to know if a mail is spam or not. Of course we need some rules and some kind of “rule checker” to decide this. Here is a very naïve implementation for this:

public class RuleChecker


    public SpamResult CheckMail(EMail mail)


        var result = TestRule1(mail);

        if(result != SpamResult.Unknown)

            return result;


        result = TestRule2(mail);

        if (result != SpamResult.Unknown)

        return result;


        // …

        return SpamResult.Unknown;



    private SpamResult TestRule1(EMail mail)


        // I don’t care about the concrete rules



    private SpamResult TestRule2(EMail mail)


        // I don’t care about the concrete rules



It is obvious that this implementation breaks the Open/Closed Principle. Every time someone comes up with a new anti-spam rule or the rule priorities change I have to modify the code in CheckMail(). Another problem here is that I can’t test CheckMail() isolated from the concrete rules.

With the help of the Open/Closed Principle our implementation could look like this:

public interface ISpamRule


    SpamResult CheckMail(EMail mail);



public class RuleChecker


    private readonly IEnumerable<ISpamRule> _rules;


    public RuleChecker(IEnumerable<ISpamRule> rules)


        _rules = rules;



    public SpamResult CheckMail(EMail mail)


        foreach (var rule in _rules)


            var result = rule.CheckMail(mail);

            if (result != SpamResult.Unknown)

                return result;


        return SpamResult.Unknown;



Now you could easily write isolated UnitTests for RuleChecker.CheckMail() and for every new rule.

You get the your concrete RuleChecker by calling the constructor with a list of rules:

class MyFirstRule : ISpamRule


    public SpamResult CheckMail(EMail mail)


        // I don’t care about this




class MySecondRule : ISpamRule


    public SpamResult CheckMail(EMail mail)


        // I don’t care about this



// …

var ruleChecker =

    new RuleChecker(

        new List<ISpamRule>


            new MyFirstRule(),

            new MySecondRule(),

            // …


Alex please correct me if I’m wrong, but I think this is what you had in mind Friday.

As stated before, we end up writing lot’s of very small classes – mostly with only one (public) method. I think this is some kind of functional approach, the only question is how we glue our code entities together. Let’s look at the corresponding F# implementation:

type EMail =

  { Sender: string;

    Recipient: string;

    Subject: string;

    Body: string}


type SpamResult =

  | Spam

  | OK

  | Unknown


let checkMail rules (mail:EMail) =

  let rec checkRule rules =

    match rules with

    | rule::rest ->

      match rule mail with

      | Unknown -> checkRule rest

      | _ as other -> other

    | [] –> Unknown


  checkRule rules

The signature of checkMail is (EMail -> SpamResult) list -> EMail –> SpamResult, which means it takes a list of rules (as above the order is important) and a EMail and returns the SpamResult. In addition I exchanged the explicit foreach loop with a tail recursion to make it look more functional.

If I want a concrete rule checker I could use partial application:

let myFirstRule mail =

  // I don’t care about this

let mySecondRule mail =

  // I don’t care about this

// val ruleChecker :  (EMail –> SpamResult)

let ruleChecker =


    [ myFirstRule;


As you can see the F# implementation is nearly the same as the C# implementation, just without explicitly wrapping our public method in classes. If we would use Reflector we would see that the F# compiler is building the classes around our functions. One could say if we follow the Open/Closed Principle we come to functional code or the other way around if we write functional code we automatically apply the Open/Closed Principle. I think that’s why I really didn’t care about this before.


After thinking about this implementation and the extra type hint (see mail:EMail) I came up with a slightly more generic implementation:

type SpamResult =

  | Spam

  | OK


let checkRules rules element =

  let rec checkRule rules =

    match rules with

    | rule::rest ->

      match rule element with

      | None -> checkRule rest

      | _ as other -> other

    | [] –> None


  checkRule rules

Here I deleted the enum value for SpamResult.Unknown and used the standard None option. As a consequence the signature changed to:  val checkRules : (‘a -> ‘b option) list -> ‘a -> ‘b option. The function still takes a list of rules and a element and returns a option value. Now the checkRules function works with every kind of rule result and takes arbitrary elements.

Tags: , , , ,

Thursday, 2. July 2009

F# BootCamp – Questions and Answers – part IV – Structural comparison

Filed under: English posts,F# — Steffen Forkmann at 17:37 Uhr

This is the third part in a “Questions and Answers”-series about the F# BootCamp in Leipzig. This time we will look at structural comparison and structural equality.

Question 6: Please describe the terms “Structural Comparison” and “Structural Equality”.

This was a simple question. Basically the answer is F# provides a default implementation for IComparable and .Equals() for all custom types. This default implementation compares all public fields of the two instances. Let’s consider some samples:

let a = 3,4,"foo"
let b = 3,4,"bar"

printfn "a > b = %b" (a > b) // true
printfn "a < b = %b" (a < b) // false
type MySimpleRecord =
  { a: int;
    b: int;}
type MyCompositeRecord =
  { x: string;
    y: int;
    z: MySimpleRecord}

let a =   
  { x = "Test";
    y = 3;
    z = {a = 1; b = 4;}}
let b = 
  { x = "Test";
    y = 3;
    z = {a = 1; b = 2;}}

// Structural comparison
printfn "a > b = %b" (a > b) // true
printfn "a < b = %b" (a < b) // false

printfn "Min(a,b) = %A" (min a b)
printfn "compare(a,b) = %d" (compare a b) 
let a = [3; 2; 4; 5]
let b = [3; 2; 4; 3; 3]

// Structural comparison
printfn "a > b = %b" (a > b) // true
printfn "a < b = %b" (a < b) // false

printfn "Min(a,b) = %A" (min a b)
printfn "compare(a,b) = %d" (compare a b)
Tags: , ,

Wednesday, 1. July 2009

Extensibility of functions with lambdas (in F# and C#)

Filed under: English posts,F# — Steffen Forkmann at 16:02 Uhr

One of the nice properties of functional programming languages is the easy extensibility of custom functions. Let’s consider a simple F# function (from “FAKE – F# Make”) for a recursive directory copy:

open System
open System.IO

/// Copies a directory recursive
/// Thanks to Robert Pickering http://strangelights.com/blog/
///  param target: target directory : string
///  param source: source directory : string
let CopyDir target source =
  Directory.GetFiles(source, "*.*", SearchOption.AllDirectories)
    |> Seq.iter (fun file -> 
      let newFile = target + file.Remove(0, source.Length)
      printf "%s => %s" file newFile
      Directory.CreateDirectory(Path.GetDirectoryName(newFile)) |> ignore
      File.Copy(file, newFile, true))

If we want to allow users to set custom file filters, we can add a third parameter:

/// Copies a directory recursive
/// and allows to filter the files
/// Thanks to Robert Pickering http://strangelights.com/blog/
///  param target: target directory : string
///  param source: source directory : string
///  param filterFile: FilterFunction: string -> bool
let CopyDirFiltered target source filterFile =
  Directory.GetFiles(source, "*.*", SearchOption.AllDirectories)
    |> Seq.filter filterFile
    |> Seq.iter (fun file -> 
      let newFile = target + file.Remove(0, source.Length)
      printfn "%s => %s" file newFile
      Directory.CreateDirectory(Path.GetDirectoryName(newFile)) |> ignore
      File.Copy(file, newFile, true))

Now we can define some filter functions:

/// Exclude SVN files (path with .svn)
/// excludeSVNFiles: string -> bool 
let excludeSVNFiles (path:string) = not <| path.Contains ".svn"

/// Includes all files
/// allFiles: string -> bool 
let allFiles (path:string) = true

Now it is possible to use CopyDirFiltered in the following ways:

/// Copies all files <=> same as CopyDir
CopyDirFiltered "C:\\target" "C:\\source" allFiles

/// Copies all files except SVN files
CopyDirFiltered "C:\\target" "C:\\source" excludeSVNFiles

/// Copies all files only if random number <> 2
let r = new Random()
CopyDirFiltered "C:\\target" "C:\\source" (fun path -> r.Next(5) <> 2)
Extensibility of functions in C#

Of course we can do the same thing in C# 3.0:

/// <summary>
/// Copies a directory recursive
/// and allows to filter the files
/// </summary>
/// <param name="target">The target.</param>
/// <param name="source">The source.</param>
/// <param name="fileFilter">The file filter.</param>
public static void CopyDirFiltered(string target, string source,
                                   Func<string, bool> fileFilter)
    string[] allFiles = Directory.GetFiles(
        source, "*.*", SearchOption.AllDirectories);
    foreach (string file in from f in allFiles
                            where fileFilter(f)
                            select f)
        string newFile = target + file.Remove(0, source.Length);
        Console.WriteLine("{0} => {1}", file, newFile);
        File.Copy(file, newFile, true);

Now it is easy to use the C# function with lambdas:

“A lambda expression is an anonymous function that can contain expressions and statements, and can be used to create delegates or expression tree types.”


Func<string, bool> filterSVN = x => !x.Contains(".svn");
Func<string, bool> allFiles = x => true;

/// Copies all files <=> same as CopyDir
CopyDirFiltered("C:\\target", "C:\\source", allFiles);

/// Copies all files except SVN files
CopyDirFiltered("C:\\target", "C:\\source", filterSVN);

/// Copies all files only if random number <> 2
var r = new Random();
CopyDirFiltered("C:\\target", "C:\\source", path => r.Next(5) != 2);

Keeping this simple technique in mind allows to create very flexible functions.

Tags: , , ,

Wednesday, 24. June 2009

F# BootCamp – Questions and Answers – part III – Lazy evaluation

Filed under: English posts,F#,Informatik — Steffen Forkmann at 11:27 Uhr

This is the third part in a “Questions and Answers”-series about the F# BootCamp in Leipzig. This time we will look at lazy evaluation.

Question 5 – What is the difference between “Lazy Evaluation” and “Eager evaluation”?

Lazy evaluation is a technique of delaying a computation until the result is required. If we use eager evaluation an expression is evaluated as soon as it gets bound to a variable.

One participant answered that lazy evaluation is used in most programming languages to calculate boolean expressions faster. For instance in the expression “x() or y()” the function y() is never called if x() returns true.

Of course this answer is correct, but this "short-circuit evaluation" is only a special case of lazy evaluation. The program would also work correctly without it. But if we want to define an infinite sequence then we can not use eager evaluation. Let’s look at an example:

// val fibs: seq<int>
let fibs = (1, 1) |> Seq.unfold(fun (n0, n1) -> Some(n0, (n1, n0 + n1)))

We do not need to understand the concrete syntax of this code here. We’ll discuss this later. Let’s just say fibs is bound to an infinite sequence (IEnumerable<int>) of Fibonacci numbers. You could also write this in C#:

/// <summary>
/// Infinite sequence of Fibonacci numbers.
/// </summary>
public static IEnumerable<int> Fibs()
    var n0 = 1;
    var n1 = 1;
        yield return n0;
        var t = n1;
        n1 = n1 + n0;
        n0 = t;

The trick is IEnumerable evaluates the elements lazy. Only at the time we take an element from the sequence the element will be computed:

  |> Seq.take 10
  |> Seq.to_list
  |> printfn "%A" // prints [1; 1; 2; 3; 5; 8; 13; 21; 34; 55]

If we would use eager evaluation then “Seq.take” would never been called. But we can go one step further. If we want to get the first 10 even-valued terms in the Fibonacci sequence, we can write this code:

  |> Seq.filter (fun fib -> fib % 2 = 0) // lazy (via pipe)
  |> Seq.take 10                         // lazy (via pipe)
  |> Seq.to_list                         // eager
  |> printfn "%A" 
// prints [2; 8; 34; 144; 610; 2584; 10946; 46368; 196418; 832040]

This would be a little bit tricky if we use eager evaluation, but of course this nice laziness comes with some costs for storing intermediate results (and code). So eager evaluation is still often the better choice and sometimes (e.g. DateTime.Now()) it makes no sense to use lazy evaluation – at least not if we don’t reevaluate the function.

Tags: , ,

Wednesday, 17. June 2009

F# BootCamp – Questions and Answers – part II – Currying

Filed under: C#,English posts,F#,FAKE - F# Make,Informatik,Mathematik,Veranstaltungen — Steffen Forkmann at 12:36 Uhr

Yesterday I was talking about F# at the .NET Developer Group Braunschweig. It was my first talk completely without PowerPoint (just Live-Coding and FlipChart) and I have to admit this is not that easy. But the event was really a big fun and we covered a lot of topics like FP fundamentals, concurrency and domain specific languages (of course I showed “FAKE – F# Make”).

Now I have a bit time before I go to the next BootCamp in Leipzig. Today Christian Weyer will show us exciting new stuff about WCF and Azure.

In the meanwhile I will write here about another important question (see first article) from the F# BootCamp in Leipzig:

Question 4 – Try to explain “Currying” and “Partial Application”. Hint: Please show a sample and use the pipe operator |>.

Obviously this was a tricky question for FP beginners. There are a lot of websites, which give a formal mathematical definition but don’t show the practical application.

“Currying … is the technique of transforming a function that takes multiple arguments (or more accurately an n-tuple as argument) in such a way that it can be called as a chain of functions each with a single argument”


I want to show how my pragmatic view of the terms here, so let’s consider this small C# function:

public int Add(int x, int y)
   return x + y;

Of course the corresponding F# version looks nearly the same:

let add(x,y) = x + y

But let’s look at the signature: val add : int * int –> int. The F# compiler is telling us add wants a tuple of ints and returns an int. We could rewrite the function with one blank to understand this better:

let add (x,y) = x + y

As you can see the add function actually needs only one argument – a tuple:

let t = (3,4)         // val t : int * int
printfn "%d" (add t)  // prints 7 – like add(3,4)

Now we want to curry this function. If you’d ask a mathematician this a complex operation, but from a pragmatic view it couldn’t be easier. Just remove the brackets and the comma – that’s all:

let add x y = x + y

Now the signature looks different: val add : int -> int –> int

But what’s the meaning of this new arrow? Basically we can say if we give one int parameter to our add function we will get a function back that will take only one int parameter and returns an int.

let increment = add 1      // val increment : (int -> int)
printfn "%d" (increment 2) // prints 3

Here “increment” is a new function that uses partial application of the curryied add function. This means we are fixing one of the parameters of add to get a new function with one parameter less.

But why are doing something like this? Wouldn’t it be enough to use the following increment function?

let add(x,y) = x + y       // val add : int * int -> int 
let increment x = add(x,1) // val increment : int -> int
printfn "%d" (increment 2) // prints 3

Of course we are getting (nearly) the same signature for increment. But the difference is that we can not use the forward pipe operator |> here. The pipe operator will help us to express things in the way we are thinking about it.

Let’s say we want to filter all even elements in a list, then calculate the sum and finally square this sum and print it to the console. The C# code would look like this:

var list = new List<int> {4,2,6,5,9,3,8,1,3,0};

If we don’t want to store intermediate results we have to write our algorithm in reverse order and with heavily use of brackets. The function we want to apply last has to be written first. This is not the way we think about it.

With the help of curried functions, partial application and the pipe operator we can write the same thing in F#:

let list = [4; 2; 6; 5; 9; 3; 8; 1; 3; 0]

let square x = x * x
 |> List.filter (fun x -> x % 2 = 0) // partial application
 |> List.sum
 |> square
 |> printfn "%A"                     // partial application

We describe the data flow in exactly the same order we talked about it. Basically the pipe operator take the result of a function and puts it as the last parameter into the next function.

What should we learn from this sample?

  1. Currying has nothing to do with spicy chicken.
  2. The |> operator makes life easier and code better to understand.
  3. If we want to use |> we need curryied functions.
  4. Defining curryied functions is easy – just remove brackets and comma.
  5. We don’t need the complete mathematical theory to use currying.
  6. Be careful with the order of the parameter in a curryied function. Don’t forget the pipe operator puts the parameter from the right hand side into your function – all other parameters have to be fixed with partial application.
Tags: , , , , , , , ,

Thursday, 2. April 2009

Adding FxCop to a “FAKE” build script

Filed under: C#,English posts,F#,FAKE - F# Make,NaturalSpec,Tools — Steffen Forkmann at 18:19 Uhr

This post has been moved to http://fsharp.github.io/FAKE/fxcop.html

Tags: , , , , , ,

Wednesday, 1. April 2009

Getting started with “FAKE – F# Make” – Get rid of the noise in your build scripts.

Filed under: C#,English posts,F#,FAKE - F# Make,Informatik,NaturalSpec,Tools — Steffen Forkmann at 21:02 Uhr

This article has been moved to http://fsharp.github.io/FAKE/gettingstarted.html

Tags: , , , , , , ,

Thursday, 5. March 2009

Sample chapter from "Implementing Microsoft Dynamics NAV 2009" published on Navision-blog.de

Filed under: C#,Dynamics NAV 2009,English posts,msu solutions GmbH,Visual Studio — Steffen Forkmann at 14:39 Uhr

Implementing Microsoft® Dynamics™ NAV 2009"Implementing Microsoft Dynamics NAV 2009" is a new book by David Roys (MVP for Dynamics NAV) and Vjekoslav Babic (Dynamics NAV consultant). It shows the new features of Dynamics NAV 2009 in step-by-step explanations of real-world examples.

If you are interested in this book you can read the complete seventh chapter right here on navision-blog.de:

Chapter 6 (“Modifying the System”) is also available for download.

What the book covers

Chapter 1

The purpose of this chapter is a teaser introduction to get you excited about the product, what’s in it in general, and what’s in it as compared to previous versions, to give you a little taste of what’s coming up in the book, and explain what the fuss about this new release is all about.

Chapter 2

The RoleTailored client is the new user interface for users of Microsoft Dynamics NAV 2009, and it is completely different to the pervious versions. We’ll take you through the different components of the interface, introduce the terminology, explore the navigation components and page types, and teach you how to personalize the application to meet your own requirements using the extensive personalization features.

Chapter 3

Microsoft Dynamics NAV 2009 introduces a new paradigm to ERP. Instead of the system being focused on the forms that capture and present data and the functions the user can perform, the system is based around the individuals within an organization, their roles, and the tasks they perform. We cover how Microsoft researched the roles and explore the departments, roles, and tasks that have been identified in the Microsoft Dynamics Customer Model. We also show the reader how to assign the standard roles to users, how to create new roles, and how to allow departmental super users to configure the application for their role so that the change is applied to all users with the same profile.

Chapter 4

Microsoft Dynamics NAV is not a product with a Next-Next-Finish type of installation, and it takes a lengthy project to deploy it successfully. We focus on the six phases of the implementation process, and explain each phase with detailed dos and don’ts for a typical implementation. Based on the Dynamics Sure Step implementation methodology with advice liberally sprinkled throughout, special attention is given to new features of Microsoft Dynamics NAV 2009, and where the new capabilities must be taken into account to make most out of the implementation project.

Chapter 5

Every implementation of Microsoft Dynamics NAV 2009 will require the system to be configured to meet the needs of the business. This chapter tells the implementation consultant how to do this from a core financials perspective and provides valuable information that will allow developers to understand more about the application they are changing. We cover basic accounting for programmers, dimensions, and posting groups, and how to use the Rapid Implementation Methodology (RIM) Toolkit to speed things along.

Chapter 6

Hardly any standard system can fit the needs of a business out of the box. Either the customer must shape their processes to match the system, or the consultant must shape the system to match the processes, and usually the latter prevails. This chapter explains the process of modifying the system, how to design a viable data model, and how to design and develop a functional user interface for both RoleTailored and Classic clients, without writing any code.

Chapter 7

The three-tiered architecture of Microsoft Dynamics NAV 2009 and native Web Services Enablement open up a whole new world of possibilities for NAV implementations. We cover some of the many possibilities for extending the application, allowing the consultant and developer to understand the technologies that are available and their respective design considerations. Our practical examples introduce the NAV programmer to the world of .NET and show how you can use the information available on the internet to develop your own killer .NET add-ons.

Chapter 8

There’s much more to development than programming. It starts with understanding what customer really needs, and usually extends way beyond the system being deployed to a test environment. This chapter focuses on the development phase, and what it takes to get from a concept to a live and working solution.

Chapter 9

After the system goes live, or as it grows, there are periods when new problems may arise, and often their source is far from obvious. This chapter explores the tools and techniques available for detecting problems, pinpointing the source, and helping to remove them from the system quickly and painlessly. It explains how to debug the Service Tier, how to troubleshoot performance issues, what can be done to avoid problems, and how proper planning before design can help to get it right the first time.

Chapter 10

Our sample application focuses on requirements gathering, functional specification creation, solution design, and the eventual build of a prototype. We look at how a business problem can be explored using techniques such as interviewing, use-case modeling, and object-role modeling to create a solution design that can be molded into a working prototype.

If you want to get more information about the book visit: http://www.packtpub.com/implementing-microsoft-dynamics-nav-2009/book

Tags: ,