F# For Dynamics CE - Why and How
A Dynamics Developers Guide
Author: Thomas Cunningham | Principal Development Consultant | Formus Professional Software | April 2020
With these two at your disposal, you might wonder why you’d look elsewhere?
Well… What if I told you that you also have the option of another powerful language, with object-oriented interoperability, and is by its very nature – safer to use? There’s a saying amongst the F# community “if it compiles, it works”.
Dynamics Is Enterprise Development
I’m making the case for F# being a good choice for Dynamics developers on the premise that the work is typically very much part of the genre of enterprise development, and that as a result, F# has a potent array of advantages to offer.
I’ll admit in advance, this piece is partially inspired by this excellent article at the website “F# for fun and profit”. Many of the traits of enterprise development described within it capture the style of work we perform for Dynamics CE, and the benefits that F# offer this follow through.
So why does developing for Dynamics CE qualify as enterprise development?
I would characterise the core of enterprise development as being defined by the following tenets:
- Data Integrity
- Solution focused, not product focused
- Low-risk tolerance
Immediately, these look like familiar concerns for any Dynamics developer.
First and foremost, data integrity is clearly at the heart of any Dynamics system. This can be clearly evidenced by the wealth of tools that Dynamics has available out of the box for ensuring that the integrity of system data remains as pure as possible.
Examples include duplicate detection rules, rich data type definitions and powerful business logic. This is further emphasised by Microsoft’s branding of the more restrained Common Data Service offering “Model-Driven Apps”, the focus is on the schema of the model; the functionality it offers is powered by the how the data is shaped.
The second point is somewhat more nuanced and is dependent on how one defines a product. It could be argued that the production of a Dynamics system is indeed the development of a product. However, that misses the essential quality that products aren’t typically created for just one customer; the success of a product is usually measured by the quantity sold.
If the software being produced is relevant to the specific needs of just one business, you’re really just producing a solution for that customer. Time and money spent on the project is dependent on how effectively it resolves business cases, not how many units have been pushed.
Finally, when developing a system that will sit at the heart of a customer’s business, the tolerance for risk is exceptionally low. Whilst any piece of software can have a disastrous event that results in the loss of service or data, usually that software will be at most making up just a piece of the puzzle that forms the customer’s workflow, so the damage it can cause is limited. The same cannot be said of systems that forms the core of business processes. If that system ceases to function, or loses data, it risks the whole of the business.
Once again, it is easy to identify a Dynamics system with this quality. Even operating purely as a CRM system, it holds and maintains crucial information for business functioning. The threshold for risk is always going to be low, if not business critical.
F# For Enterprise Development
With these qualities in mind, what does F# offer to help resolve them?
Essentially, they are facilitated by one core concept - safety. Safety means that we can ensure data remains integral, that we’re consistently providing stable solutions, and that risk is kept at a minimum.
When it comes to software development, I find that the common ground for most applications of safety as a concept is about expected behaviour; expecting that your code behaves like you intended, your security does indeed keep you secure, and that transactions give you consistent results. Distilled, this should mean that operations performed with the same input, should result in the same outputs.
To quote Joe Armstrong, the creator of the language Erlang:
“the problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle.”
This might at first seems like an obtuse metaphor, but it colourfully captures this innate issue with OOP languages. By their very ontology, all functionality that you expect from OOP code is dependent upon an opaque set of variables and states that unless are fully documented and understood, ultimately endup risking unexpected behaviour.
Put into very specific terms, you might feel like a verbosely written method named “GetNextFiscalYearStartDate()” clearly declares the functionality it will provide. But without having an absolute understanding of the state of the class that encapsulates it, it could feasibly result in variable outputs.
This is only one example of what Joe Armstrong is referring to, but any relatively experienced developer should find it easy enough to extrapolate other scenarios. Code is safer, and more consistent, the surer the developer is of what the code is doing.
This is of course no insignificant thing to resolve, but the Functional paradigm (of which F# is part of) goes a good way to helping. It encourages (in some cases forces) developers to embrace concepts such as immutability, recursion, and higher-order functions.
The essence of a good functional language is that it is deterministic. Each function that makes up the software as a whole provides invariable functionality, with no dependency on hidden qualities. The functions are typically highly flexible as well and can be treated and passed around similarly to how variables are in OOP languages. This results in applications that are highly robust, but reusable. Crucially, it means software that behaves more consistently in an expected manner.
In terms of what this can mean for Dynamics development, who wouldn’t want to guarantee their clients a system that is more consistent and more predictable in how it handles their business processes and data?
Whilst progress has been slow, this is why the Functional paradigm is being eyed as the one to eventually replace OOP.
Why Specifically F#?
Whilst OOP languages are still the dominant choice, there is already a sizeable pool of Functional languages to choose from. If the Functional paradigm as a whole offers these benefits, should we be considering what else is available?
Whilst there are plenty of good Functional choices, some adhering more purely to the Functional paradigm (and more clearly realising its benefits) than F#, for most of us it remains the right choice.
Firstly, it’s simply an easier language to move to if you are used to OOP. F# is primarily composed of pure Functional features but is ultimately a hybrid language. This means that whilst transitioning and if you’re struggling to come to terms with concepts such as using recursion rather than loops, F# has a safety net of OOP features that you can fall back on.
Additionally, as part of the Common Language Runtime, it has full interoperability with .NET. You can fully expect to continue to use your C# libraries, making the transition far smoother.
Secondly, it means you have full weight of Microsoft’s ecosystem behind you. Microsoft have embraced F# as one of their flagship languages. This means that any commitment you make to it is unlikely to be cut short by it being abandoned. It also means that you have easy access to the majority of development tools and products that MS provides, and that you’re likely used to.
Thirdly, as a Dynamics developer, you don’t really have another choice! For good compatibility with the necessary SDK assemblies, F# is currently the only official Functional CLR language.
Register An F# Plugin
If as a result of this read, you’re interested in exploring F# for Dynamics development, you might be wondering to yourself how you can go about creating your first F# plugin. Providing you’re a seasoned C# developer, it might be easier than you expect:
- Create an F# Library Project in Visual Studio.
- Add an F# source file (‘.fs’ file extension).
- Add the following code:
- Build the assembly (CTRL + Shift + B).
- Sign the assembly - F# projects don’t support this in Visual Studio, so it needs to be done manually.
Run the following command in command prompt:
c:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\bin\NETFX 4.5.1 Tools\sn.exe -k <KeyName>.snk
- Use ILMerge to merge your plugin assembly with the core F# assembly.
- Register your plugin via the Plugin Registration Tool.