So over the last couple of posts, we’ve looked at what does work well in C# from F#, and most of it seems to go pretty smoothly. But there are occasions where the languages refuse to play nice with each other. That’s what we’ll be discussing in this final post. Options Option in F# are a way to get around the idea of null by providing two ‘sub-types’ called Some and None.

Continuing on from where we left off last time, we will try to cover off the rest of F#’s features that play really well and simply when being consumed from a C# codebase. Values F# can have values places directly inside modules, almost ‘global’ values in the module. See an example below :- module FunctionalParadigms let aNumber = 5 As we know from the last post, modules expose themselves as static classes in C#.

What makes F# special? In the Dotnet world, F# stand out as being the Functional based language. This might sound strange, and I on’t have time to go into the full difference between Function and Object-Oriented languages and paradigms here, please do a google if you wish to learn more. Some of the main features of F# that are relevant to this series are as follows:- Higher Order Functions Modules Records Sequences Discriminated Unions Options I put them in this order for a reason.

This is Part 1 in my series of Blog Posts on DotNet interop. Why Visual Basic? I decided to use visual basic as my first way to show Interop as C# and Visual Basic both share the same programming paradigm of object orientation. A sample of the languages! Below I have snippets of two classes which are mirrors of each other in both Visual Basic and C#. Visual Basic C# (Those more astute of you will have notice Visual Basic’s superiority with a lack of Semi-Colons and Brackets …)