Are you a Dynamics Craftsman or a CRM developer?

“Don’t comment bad code—rewrite it.” ― Brian W. Kernighan, The Elements of Programming Style

The quality of your work is related to the standards you set yourself #HoskWisdom

 

A few months ago I joined Capgemini and people have been asking me what attracted me to join the Capgemini CRM team and what it‘s like to work for Capgemini.  What attracted me is Capgemini’s want to bring software development principles to Dynamics CRM development and focusing on delivering quality enterprise Dynamics CRM/365 projects.

What I really like is Capgemini Dynamics CRM projects have DevOps who setup automated deployments, Continuous integration,  one of the greatest gifts to dynamics developer because it allows more time in creating customisation

Are you a Craftsman?

When interviewing developers I like to ask them if they are Craftsmen or developers, this question finds if the person being interviewed is driving the quality of their work, if they have pride in what they are creating.

Creating quality code like motivation comes from within and can’t be forced using standards or rules.

Dynamics developers need passion – CRM Developers need Passion and joining Capgemini is a good fit because we shared many beliefs.

It‘s importance to keep the quality of CRM projects high and manage technical debt, these principles are even more important on large projects where poor quality code can slow the project and maintaining code can become a nightmare.

I experienced a project where it took 1 day to add an easy fix because a plugin had one method with 2000 lines of code

I can recommend the book

I recommend a few other books in the post – Why isn’t code reused in Microsoft Dynamic CRM projects?

My experience of CRM development

I started out as a Java developer and learnt traditional programmer principles.  Learning about programming and I remember being iinspired by code craftsman and reading Effective Java : Second EditionHead First Design Patterns, Object orientation programming and other books listed on Recommended Books for Developers.

There was a story about a developer learning to become a craftsman, it was featured in a magazine and was a regular column. It talked sbout problems newbie programmers walk into without realising.  (it was called something like the woodcutter or craftsman)

When I moved from Java/.netdevelopment it seemed many CRM development companies didn’t follow good software development practices or good coding standards.

  • CRM code often put all the code into one method in the plugin
  • Lack of classes
  • No unit testing
  • No automated builds
  • No code reviews or static analysis

There are a few reasons for this

  • Microsoft Dynamics CRM made it difficult for automated builds (before solution packager)
  • Companies were not interested in invested in
  • Many CRM projects were small with no budget for automated builds and unit testing
  • CRM developers often didn’t have programming experience or knowledge of SOLID principles
  • Timescales were short in projects – focus on short term gains

Dynamics CRM and developer principles

When I interviewed with Capgemini they wanted to know my opinions on unit testing, code quality.

Capgemini wants to bring software developer principles to CRM but what does this mean?

Capgemini CRM projects are big enterprise integration projects where code quality is important when creating lots of code, which means you will be maintaining lots of code.

Enterprise projects are long projects, technical debt must be kept low and members of the development team adhere to high standards (high standards are a habit)  Here are some of the methods we use to keep quality high

  • CRM DevOps help developers do their jobs
  • Automated deployments/CI environment
  • Solution packager can import data
  • Solution packager splits up customisations to XML file and stored in source control
  • Code check ins to master have to be reviewed and accepted by senior developers
  • Static analysis on code
  • Static analysis errors and warnings must be removed
  • Capgemini hire good Dynamics developers and make them better (join us here)
  • Minimum 90 percent unit test coverage on Business logic code
  • The Quality code message comes from the top
  • The standards implemented on a Capgemini Dynamics project are higher than developers implemented

Regrets I have a few

After working on a project with automated deployments I think this should be a priority for all Dynamics projects to setup on a project, it offers so many benefits which I discuss in the post below

CRM 2016 – Release management, Solution packager and why you should automate your deployment

I wish I had pushed for higher quality on Dynamics projects I had worked on earlier in my career because if you are not writing high quality code you are adding to the technical debt of a project.  I have seen many Dynamics CRM projects start adding technical debt straight from the first line of code because they used poor standards and practices, these projects get harder and harder

It’s great to work on a Dynamics CRM project using software principles.

Capgemini aim to take good CRM developers and make them better by delivering hard projects with well crafted solutions

You can join the Hosk at Capgemini by applying here

CRM 2013 – Remote Debugging

Only those who dare to fail greatly can ever achieve greatly.”

― Robert F. Kennedy

Developer fear

When I was a junior CRM Developer I couldn’t get remote debugging working, Visual studio wouldn’t attach, port problems etc.  I gave up because I need to resolve the problem.

Until I have done something I’m not sure I can get it working.

The mind makes unknowns scarier; it exaggerates and focuses on worse case scenario’s. Like visiting somewhere you have never been before such as you first day at school/university.  The location seems bigger and shrinks in size with familiarity.

Remote debugging is frustrating because to find out why a customization is erroring you need to debug it.

One day I came to work determined to get remote debugging working and after half a day of trying I got it working.

When using a tool or functionality for the first time, you are outside of your comfort zone (How to cope when you are out of your Developer comfort zone)

Why we need a CRM Developer toolkit

It’s important the CRM developer toolkit is updated and works with CRM 2015/Visual studio 2015.  The CRM developer toolkit makes it easier new CRM developers to write, update and deploy plug-ins.  We don’t want barriers for new CRM developers we want to encourage them to join the CRM development community.

Remote debugging considerations

Remote debugging has some drawbacks, if the plugins has isolation mode = “none” you use the CRM async service, W3p.exe.  This stops the CRM server  processing system jobs, other users have to wait until you have finished debugging.  This is frustrating for other developers because it stops them using CRM.

A better alternative is to test your code using unit tests or console app if I want to call it with data in CRM, this has no effect on other developers and units tests can be rerun by any developer.

Most scenario’s you can test your logic without using the remote debugger, Why CRM Developers should unit test their code

I wrote about remote debugging for CRM 2011 before

CRM 2011 – how to set up Remote debugging for plugins

If you experience problems setting up the remote debugger, try this blog

Remote Debugging CRM 2011 Plugin

Learn Remote debugging before you need it

It’s better to learn a process, new functionality before you use it for the first time on a project,

Make mistakes in practice, it’s a less stressful place to learn than on a live project

Get experience remote debugging before you need to use it.

Remote debugging can be a frustrating due to difficulties in setup and configuration.

Remote debugging is on for On Premise CRM only

You cannot remote debug CRM online.

To debug plugins deployed on CRM Online, you have these choices

The purpose of remote debugging is to test the logic.  You can recreate the scenario from in dev by recreating the data.  Remote debugging shouldn’t be the first tool when diagnosing a problem, it can affect performance and other developers

  • Unit Test
  • Console app and Test plugin code
  • Plugin Registration tool

The debugging option work with CRM On Premise but you cannot use the remote debugger with CRM online.

You can unit test code and create a connection for IOrganisationService to your online CRM and pass and then run unit tests.

Console App

Create a console application, connect to your CRM online and test the code, mimicking the plugin.

Plugin Registration tool

The plugin registration tool can debug the code, it has the advantage of not freezing the whole server because it works with CRM on premise and CRM online.

This video has a good walkthrough of the process Debug CRM Online Plugins

CRM 2015 has added plugin tracing, read more about it here and here

Remote debugging steps

The process is the same for CRM 2011, CRM 2013 and CRM 2015 plugins.  Custom Workflows are different, this blog post walks through the process – Debugging Workflow Custom Activities with Plugin Registration Tool

In this blog post I focus on using the remote debugger and a plugin

I’m using CRM Developer toolkit and running the remote debugger, you can run it as a service which runs all the time (called Remote Debugger) or you can run it as application. which starts when you need it.

Running as a service is it’s always running and can be set to auto start on server reboots.

The downside is the remote debugger service will always be running and taking a bit of server memory/processing (although not much).  You can stop the service if you need.

Developers should use remote debugging in a development environment.

Build the plugin

Copy the plugin/custom workflow .dll and .PDB files to the CRM server directory

C:\Program Files\Microsoft Dynamics CRM\Server\bin\assembly

If you haven’t installed CRM on the C drive then you need to look for it on another drive

The DLL’s and PDB copied to the server must contain the code you want to debug in Visual Studio.  If the code on your local machine is different from the deployed plugin you won’t be able to debug

Important – Copy the .dll and .PDB files to C:\Program Files\Microsoft Dynamics CRM\Server\bin\assembly

Important 2 – Any dependencies in your plugins (dll‘swhich are not in the GAC need to be copied to the server as well.

I copied the PDB files here

C:\Program Files\Microsoft Dynamics CRM\Server\bin\assembly

What is a PDB file?

You may be wondering what a PDB file is, my knowledge of them is you need them for debugging and they contain the code you have written where as the DLL has the compiled code. 

Wiki describes PDB file as

http://en.wikipedia.org/wiki/Program_database

PDB stands for Program Database, a proprietary file format (developed by Microsoft) for storing debugging information about a program (or, commonly, program modules such as a DLL or EXE). PDB files commonly have a .pdb extension. A PDB file is typically created from source files during compilation. It stores a list of all symbols in a module with their addresses and possibly the name of the file and the line on which the symbol was declared. This symbol information is not stored in the module itself, because it takes up a lot of space.

A PDB is needed for debugging, it isn’t needed when you deploy your plugins or custom workflows.

recap of steps

  • Ensure the remote debugger is running as a service or application
  • Build the plugin
  • Deploy the plugin
  • copy the DLL and PDB to the CRM server folder
  • C:\Program Files\Microsoft Dynamics CRM\Server\bin\assembly

Attaching the process

You should be ready to attach Visual Studio to the process and wait for the code to be trigger and your visual studio breakpoint to be hit.

Set a breakpoint in the plugin, put the breakpoint at one of the first lines to avoid breakpoints not being hit because their code was either erroring or not being triggered.

Press the Attach button

remote debugger attach

Brings up this page, it will default to your local machine but you need to put in the name of the CRM server and the port used in the remote debugger.

If my port was 4016 and the CRM server was called CRM server.

CRM Server:4016

Remote Debugging 3

Make sure you tick Show Processes from all users, if you don’t you won’t be able to see the CRM services because  they are most likely run as a different user.

If you don’t know your port number, you can go to the CRM server, open the Remote Debugger to find the path of the application

Remote Debugging 1

click on msvsmon and it will error and tell you the port number you are using.

Remote Debugging 2

When you put in the correct CRM server and port number, the services running will be listed.

If you plugins are in the sandbox (Understanding Plugin sandbox mode) you need to attach the to the process Microsoft.CRM.Sandbox.WorkerProcess.

remote debugging

Usually there are multiple Microsoft.CRM.Sandbox.WorkerProcess. This is because you get one for each CRM web page.  It’s difficult to work out which process is the process you want to debug, so I usually select all of the Sandbox WorkerProcesses to ensure I debug my process.

The final stage is to trigger the plugin and debug your plugin.

Good luck

CRM 2015 – How to diagnose plugin errors

This blog talks about a plugin error which I have seen a number of times when using the Plugin Developer Toolkit, it will discuss how to diagnose plugin errors in general.

Before I talk about plugins can I encourage people to vote on the connect item to get the CRM Developer toolkit working with Visual studio 2013, if you can’t wait for Microsoft to fix it then read my blog post CRM Developer Toolkit Alternatives

Hosk CRM Brain

I like to think of my blog as my CRM brain uploaded to the internet, so whilst reading this you are currently crawling through my CRM brain.  This allows me to search my CRM brain when my real brain forgets how I resolved a problem, actually sometimes I even forget I have experienced a problem and get pleasantly suprised when I have found not only did I have the problem before but I blogged the solution.

The benefit of me blogging about CRM is I benefit and other people who read and search my blog.

My goal in writing articles focused on errors is not only to write about how to resolve the issue but additionally look into the cause of the problem and , the WHY.

Knowledge helps when things go wrong

There is always a difference between theoretical knowledge and practical knowledge.   You can learn the theory of something but find it’s different when you try to use the theory in practical use (e.g. after reading about plugins you then try to write a plugin) you there are gaps in knowledge which you quickly find.

When developers start to plugins they usually go through

  • learn to write plugin code, find lots of errors
  • try to deploy plugin, error haven’t signed the plugin, error permissions etc.
  • Slowly but surely the developers experience fewer problems or problems they know how to resolve

Indepth knowledge of how Microsoft Dynamics CRM works and the underlying plugin infrastructure becomes extremely important when things go wrong.  When errors appear and hold up development, developers need to understand the cause of the error but why it’s complaining, the answer is usually understandable if you understand

  • how the CRM developer toolkit works
  • The various parts of the CRM Developer toolkit
  • The CRM plugin execution framework
  • The roles and privileges needed to deploy plugins

Some useful Hosk Plugin blog posts

The CRM developer toolkit is great (which is why I get annoyed it hasn’t been updated because it automates a lot of the repetitive actions needed to deploy a plugin using the plugin registration tool.) but I feel CRM Developers should learn how to use and deploy plugins using the plugin registration tool.

I use the plugin registration tool to inspect what plugins and steps are deployed and the ability to change the view to see what plugins are deployed for each entity is really useful when investigating bugs on CRM solutions you are not familiar with.

Most of the time you don’t want to mix using the plugin registration tool and the CRM developer toolkit because the CRM developer toolkit will overwrite the changes you make manually next a developer uses it to deploy CRM customizations.

The plugin registration tool is great for viewing the plugins deployed and its portability allows you to use it in customer environments.

If the CRM Developer toolkit gets in a mess you might need to use the plugin registration tool to quickly update or deploy a plugin whilst you fix the plugin developer toolkit.

I had an error previously but the problem was the CRM developer toolkit had got out of sync and I struggled to resolve this problem.  You can read about my frustrations with the CRM Developer toolkit

Dealing with Plugin errors

If When you experience a plugin error I would recommend you first read my blog on common problems because I cover the most common errors.

If you don’t find the answer then stop and think about the potential cause of the problem.  Many developers can go into a mild panic mode when they encounter an error, instead of logically thinking about the problem they instantly go and get a senior developer to help them.

Then when the senior developer is at their desk, they explain the problem.  The process of explaining the problem to the developer, the solution to the problem can become clear.  This is known as rubber ducking or I call this Cardboard developer

When you encounter a plugin problem or CRM developer problems, follow these steps

  1. Stop
  2. Engage Brain\Think
  3. What’s happening?
  4. What should happen?
  5. Make a list of the possible causes of the problem
  6. Investigate your list

If you can’t resolve the problem, you can then at tell the developer what you know, what you have tried.

I don’t encourage any developers to suffer in silence but it’s more beneficial for you own personal learning if you try to understand and resolve problems yourself.  The major benefit of trying to resolve the problem yourself is you get in the habit and become less dependent on the help of your colleagues.

Don’t Assume, know

Don’t Assume, Know is a Hosk mantra I tell myself when investigating problems or debugging.  I have wasted many hours investigating problems and looking for solutions based on an incorrect assumption.  When dealing with problems don’t assume anything, check assumptions and cross them off.  Lots of times you will find the problem.

Plugin Error Messages

The error messages Microsoft Dynamics CRM throws are a mixture of a confusing statement with a nugget of truth tucked inside.  To developers new to CRM development they are just unhelpful messages.

As your experience and knowledge of CRM development increases you will find they often point you in the right direction but you need to have built up a map of the CRM landscape, so you know where to go and check.

Plugin Error Example

This is common error I have experienced a few times but I was trying to deploy a plugin using the CRM developer toolkit and I got this error

Error registering plugins and/or workflows. Plug-in assembly does not contain the required types or assembly content cannot be updated.

Lets break down the message to try and decify the problem

  1. It can’t register the plugin/workflow
  2. Plugin Assembly does not contain required types or the assembly cannot be updated.
  3. So we know the plugin assembly (the DLL) exists but it cannot update it.

The first thing to do is know not assume.  So I opened the Plugin Registration tool and found the DLL.  I could see it had three steps.

I then looked at the RegisterFile.crmregister file and found this had two steps.

The problem was because we were trying to update an assembly with 2 steps but the assembly had 3 steps.  It couldn’t update the assembly because it was too different and this error message was letting us know (in a slightly confusing way).

I have experienced this problem before and the solution to the problem is to unregister the Assembly and install it again.

This problem has occurred when I have created new plugins and sometimes when I have updated a plugin maybe in a different solution but for some reason I couldn’t update the DLL.

In this case how the extra step got into the assembly was a complete mystery but it’s OK to delete the plugin assembly because I knew I was going to deploy it again and install a new version of the Plugin assembly.

CRM 2015 – How to decompile a plugin Assembly (DLL)

This blog post looks at how to decompile plugin code because I had a problem recently where I needed to do it.  The process will work in all version of CRM because fundamentally it works at DLL level rather than CRM level.

It’s a useful to understand because there are some instances where you need to know what code has been deployed because it might be different from the code you have or the code in your source control.

The problem – Why isn’t my fix working?

A bug fix I had deployed and tested in our dev environment and test environment suddenly stopped working when deployed to the customer environment.

This isn’t an unusual problem but an annoying one for developers.

Don’t assume, know

When bug fixing and testing try to avoid the trap of assuming because assumptions are often wrong, resulting in missing the obvious source of the problem, spending time testing other possible reasons for a problem.

Usually when a bug fails on a different environment I want to recreate it in the DEV environment where I can easily debug it.
For this problem we have two internal instances

DEV
TEST

I tested my fix in DEV and it seemed to work and then I tested the fix in internal TEST environment and found my fix didn’t work, why?

Finding the plugin code deployed

There are instances when you need to find the code deployed in a plugin. It’s possible to version plugins but CRM developers don’t bother versioning their plugins and I currently don’t version the CRM plugins.

Plugins can be versioned in the same way solutions are version in CRM

major.minor.build.revision

You need to think about versions and solutions because when you change the major number of a plugin assembly CRM considers it a completely different plugin assembly

Microsoft has a good article on Plugin Assembly

This article on how to upgrade version

Hardcore CRM: Do a major upgrade of a plugin version!

What to do if you don’t use assembly versioning

The problem I had was how could I tell what code was inside the plugin and if my fix was deployed?  The code in TFS (Source Control) was correct and up-to-date but I tested the functionality and could see it wasn’t working.

I decided to download the plugin assembly dll and decompile the code.

The tools I used was

XRMToolbox

Go to releases and click latest release if you want to download the application not the source
https://github.com/MscrmTools/XrmToolBox/releases

The XRMToolbox has a tool called Assembly Recovery Tool. This tool allows you to connect to a CRM instance, it loads all the assembly DLL’s (which can some time), you can choose to download any of the Plugin assemblys(dll file). This will give you the dll, which you can decompile using a different tool.

Once you have the DLL file you can decompile the dll using a tool such as

ILSPY

There are lots of other decompilers out and the main reason I use ILSPY is because its free

To use the decompiler you open it up, select a DLL or copy one to the application, below I have selected a HoskCRMDev2013 plugin.  The dll’s in blue are dependant plugins

decompile plugin

If you then click on one of the methods, it decompiles the code, which you can view it in the yellow right hand screen.

decompile plugin1

ILSPY has a few neat options to save the to file.

A few notes on decompiling DLLS

DONT decompile DLL’S you or the company you work for doesn’t own because basically you are viewing the source code.

I’m not sure about the legality of it but it’s probably illegal, particularly if you don’t own the intellectual property.

If you aren’t sure if you should decompile a DLL think about it like this.  If you went to the owner of the source code and asked to view the source code, would they let you?

A common cause of decompiling plugins/custom workflows is to see what has been deployed if plugin versioning is not used.

Be warned decompiled code is slightly different, often the variables don’t have the same name.

If you are concerned about your dlls being decompiled there is a tool to encrypt them, I haven’t used it.  The discussion on StackOverflow is a good place to start if you are interested

Protect .NET code from reverse engineering?

When might you need to decompile a DLL?

Surprisingly there are quite a few scenarios where you might need to decompile a DLL, I will go through some of the common scenarios but the

Lost source control

I have seen scenarios where a company has lost the source control for code which has been deployed.  Often its old legacy systems and most people who worked on the project have left the company

Deployed with source control checked out pending

A developer deploys some code, forgets to check in the code.  The developer then might leave the company, go on holiday and can’t be contacted.  You need to know what code has been deployed and what code might not be checked it.

Plugin won’t deploy from CRM Developer toolkit

Sometimes a plugin won’t deploy and you will get an error like this

Error registering plugins and/or workflows. Plug-in assembly does not contain the required types or assembly content cannot be updated

The reason for this error is often because the deployed assembly file (DLL) is different.  It might have an extra step and you are not updating the file but trying to replace it.  CRM doesn’t like this.

I had an example of this recently and there was an additional step in the deploy DLL.  I used the plugin registration tool to compare the steps but I wasn’t sure what was in the extra step.  So I download the DLL and looked at the code.

What has been deployed

This is the problem I was experiencing for this bug.  I needed to check if the code deployed was the same as the code in source control, the only way I could do it was to decompile the code and compare.

Plugins without versioning

A common cause of decompiling plugins/custom workflows is to see what has been deployed if plugin versioning is not used.

Multiple Developers Versus Source Control

When you have multiple developers working on a project, source control can sometimes lead to problems with people not getting the latest code and deploying an older version

Who deployed the different plugin?

I was wondering how the different plugin version got deployed. I wondered if I could work out what solutions were imported

I remember review a useful tool a while ago the Solution History tool, which is a tool which works with the XRMToolbox

You can download the tool here

The tool usefully told me what solutions had been imported and what files were included.

I could see the solution had been changed and who imported but I couldn’t tell what version of the Plugin Assembly had been deployed.

This tool would be extremely useful if the project you are working on imports multiple solutions without changing the version number.

What gets updated when you import a plugin to the database?

In the background when you import a plugin it updates system entity called plugin. I wondered if I could select these entities to see when they had been updated.

The problem is you can’t select system entities in an advanced find, so I remember another tool which works with the XRMToolBox the FetchXML Builder

You can get the tool here

This tool is useful because it has GUI interface to allow you to create Fetch XML queries. This means you can select system records.

The real beauty of this is you can create FetchXML queries and then use them in your plugins.

I wanted to use the tool to easily query the system entity of plugin

retrieve plugin

Which produces the FetchXML below

<fetch count ="50 " >
<entity name ="pluginassembly " >
< filter>
< condition attribute= "name" operator=" eq" value ="Full Assembly Name " />
</ filter>
</entity>
</fetch>

This allowed me to retrieve when the plugin was changed and by who. I was wondering if someone had directly deployed a plugin to the Test environment and bypassing the Solution import phase but it turned out not to be the case.

I couldn’t work out who had deployed an old plugin version and the important point was I had the resolution to the problem (although you would like to be confident it wouldn’t happen in the future)

Summary

This blog should show you how to download and decompile a DLL file.  There are certain scenarios where you aren’t sure if the code deployed is the same as the code in your source control.

Downloading and decompiling DLL’s is another tool to put in your development bag, make sure you use it for good not evil.

How to find classes

This is the 3rd part of my trilogy of blogs on classes and code quality in plugins, the previous two parts are

  1. Are your CRM plugins creating technical debt?
  2. Are CRM Developers are afraid of creating classes?

I have written an increasing number of articles focusing on the quality and design of code, which you can find Hosk’s CRM Developer Articles

To summarise the first blog discusses the effects of creating plugins and putting the code into the plugin.

  • Complex code
  • Hard to read
  • No code reuse
  • Difficult to debug
  • Writing unit tests is hard so most CRM developers don’t bother
  • Creates duplicate code

The second blog post discusses the benefits of creating classes and using abstractions, it allows the developer to manage the effects of change whilst cr

The role of classes

  • Removes duplicate code
  • Modelling real world and abstract ideas
  • Reduces complexity
  • Manages the effects of change
  • Information hiding
  • Create reusable code

The benefits of classes

  • The code is created from many simple classes and methods
  • The code is easy to unit test
  • Well designed classes have minimal dependencies
  • Well designed classes should be able to be reused
  • Classes and method can make the code easier to understand
  • Good abstractions can be used in different projects

You should now be convinced creating classes is the way to go, so how do you find classes

Finding classes

The benefits of creating classes have been outlined above but finding classes and abstractions can be tricky.  Numerous times I have created some initial classes only to find my one class could then be broken into two or three separate classes.

The design of code emerges overtime with unit tests allowing developers to change the code and test it still works.  Development tools can help refactor the code but there is an overhead to changing existing code and tests.

The earlier you can successfully identify classes/abstractions the less time you can spend refactoring your code, so it’s worth improving the methods you use to find classes.

There are some common methods to help developers find classes which I will outline below.

NOUNS = Class, Verbs = Methods

CRM developers usually get a requirements document/functional spec.  It’s good practise to create a use case document to see what steps the end user will go through using the functionality (This will find the different paths through the customization).

The requirements document/use case can be used to find nouns and verbs to help you creates classes and methods.   Nouns give you the classes and Verbs give you the methods.

Nouns – Person/Place/Things
Verbs – Methods/Behavior/action

Using the nouns/verbs method gives you a good start identifying classes but it’s far from fool proof and will miss some classes and create duplicates.

When using this method be aware classes are not always specified as nouns, you may need to look a bit harder.

The nouns/verb method of finding classes and methods is a good start point for finding classes/methods.  When using the process keep in mind you are trying to find abstractions and common functionality in the requirements, design is an iterative process which involves understanding the problem and solution, uncovering more details as you go.

It’s common in use case to use different nouns whilst referring to the same abstraction, so you will find duplicate nouns and part of the process will involve getting rid of duplicates and merging some of the nouns together.

Code Complete 2 gives a clear definition of what an abstraction is

abstraction is the ability to view a complex operation in a simplified form.  A class interface provides an abstraction of the implementation that’s hidden behind the interface

A good way to think about classes as an interface, methods are the actions performed.  Inside a class you have hidden variables.

Finding classes, designing the methods before you start coding helps give a developer a more holistic top down view of the design.  Once a developer starts coding the perspective tends to shift more towards a bottom up approach of the functionality required.

Relationships

After identifing a list of potential classes a good method to find the relationships between those classes is to do a quick Conceptual object of those classes

Object-modeling technique

This helps to identify the interactions between classes, the goal of this task is to highlight any missing classes.

This will show you the behaviour of the classes and what classes will interact with other.  Some of these behaviours will have been found when you looked at the adjectives in the use case.

Responsibilities

It’s interesting to think about the responsibilities your classes are going to have, which class is responsible for certain data

Responsibilities can be

  • Knowledge/state an object maintains
  • Actions/methods an object will perform
  • Services/functionality provided by an object

It can be useful to CRC models

CRC models shows the Colloborators and Responsiblities of a class, below is a useful video

https://www.youtube.com/watch?v=5IpsMwxL37k&list=PLqlI1RpjIS59ziAx7YBqQ0rtyAcpgdsjm&index=25

Find Common Functionality

Classes are also in common functionality and actions used by other classes.

It can help to create class diagrams to see the classes and the interactions between classes.  This can help you find missing classes.

The next stage is create the classes, code and unit tests.  Once the code is working you can think about refactoring/tidying the code and thinking about apply SOLID principles

A good way of finding 2 or more classes within one class is to check the class is focused and doing one thing e.g. The Single Responsibility principle.

A quick way to check if a class is doing more than one thing is the name of the class.  The class should clearly describe what it is/what it does.  Badly named classes often are badly named because they are doing more than one thing.

Actions, manager, Super

Class smells

Here is a list of class smells which often indicate the class is doing to much and could be split into more separate classes

  • Difficult to name the class?  This is usually a sign the class is doing more than one thing
  • Cohesive.  Are all class variables used by most methods, do some methods not use certain variables.  A lack of cohesion is usually a sign a class can be broken out.
  • To many methods.  A high number of methods usually means high complexity, indicating the class is a candidate for refactoring to simplify the code
  • Method length (in lines) – a class bigger than 200 or 300 hundred lines is to big

When checking classes you are often checking for cohesion and if the class can be broken into smaller more cohesive classes.

Cohesion when used to describe design can confuse some readers, so here is wiki’s definition of cohesion

In computer programming, cohesion refers to the degree to which the elements of a module belong together.  Thus, it is a measure of how strongly related each piece of functionality expressed by the source code of a software module is.

Cohesion is the concept all the variables and methods in the class fitting together under the name and purpose of the class.  A class should have a single responsibility, a single purpose.  If a class has more than one purpose then it should be split up.

Example

Here is a quick example

ATM Machine

A bank customer must be able to make withdrawals from the ATM machine using their card.  The card must be validated before the ATM will give money.

ATM machine will check the user has at least the amount of money to be withdrawn in the account.

The bank customer can make a balance enquiry.

Nouns

  • Customer
  • ATM Machine
  • Card
  • money

verbs

  • withdrawn
  • check
  • validated

Further reading

OOSC-2: HOW TO FIND THE CLASSES

From the awesome Bertrand Meyer.  I found the article above very useful

Are CRM Developers are afraid of creating classes?

I have seen lots of CRM code and my initial thoughts are CRM developers don’t seem to create many classes or spend much time designing their code.  In this blog post I will discuss the effects of not creating classes and explain the benefits of classes and abstractions.

Are CRM Developers afraid of creating classes?

The problem seems to be self reinforcing.  Previous CRM projects contain few classes and most of the code exists in the plugin, this sets an unspoken standard which encourages developers to not create classes.

This is a mixture of a safety in numbers/wisdom of crowds approach, it could be seen as consistency and a standard approach to CRM development is good.  Consistency in CRM development helps developers maintain, debug and extend CRM projects.

In the case of putting code in the plugin and not creating classes I think it’s bad practise and every plugin you add creates more technical debt for the CRM project and CRM projects quickly resemble legacy projects with complex CRM customizations

The end result is complex code doing lots of things and impossible to reuse and extremely difficult to work with (maintain, debug, read, etc).

To not use classes and put all or the bulk of the code in the plugin class

  • makes it impossible to reuse code
  • create complex code which does many things
  • creates duplicate code
  • create code which is hard to understand
  • Code is very difficult to test

CRM plugins are often small, focused code but to not create classes or abstractions is to create a code base technical debt.  This debt is paid back when CRM developers take longer to interact with the code in the future.

Plugins with few or no classes results in each developer creating new code every time because it’s impossible to reuse any of the code in the other plugins.

If CRM developers are not creating classes they are creating legacy code and plugins contain monster methods – Hosk

Boy Scout rule

The focus when creating code should be to keep the quality high, test everything and keep code as simple as possible.

When you create plugins or every time you make a code change you make you should leave the code in better state than you found it.  Why you should write code and customizations like a boy scout

Quality of code is fundamental to the long term success of a CRM project and as soon as you lower your coding standards and let in bad code, it will soon spread Bad code is like a virus, don’t get infected

What is the role of Classes in programming

I advocate no code logic should be added to the plugin class except a call to a class passing in the entity, IOrganisationService, ITracing.

Putting logic in a plugin creates complex code, which is difficult to unit test but there are other reasons to create classes which are listed below

No Duplicate code

Duplicate code is one of the worst code smells and it has multiple bad side effects

  • More code = more potential bugs
  • duplicate code = bug fixing can result in multiple fixes
  • bug fix one set = miss out changing duplicate code, which one is right?

When ever you find duplicate code or are about to create duplicate code, take the opportunity to find the common behaviour and abstract it into a class.  This will enable you to reuse this single piece of code in many places.

Using classes and functions is the primary weapon against duplicate code because you are logically sorting code in logical class/method, which will allow developers to easily find and use it.

Modelling real world and abstract ideas

Classes allow you to model real world objects (account) and abstract concepts (printing, validating).  The benefit is you can split up the code into logical abstractions which give clarity to the intent of the code.

CRM out of the box models plenty of real world objects

  • Accounts
  • Contacts
  • Opportunities
  • Phone Calls

Abstract classes

  • Security role
  • Solution
  • Behaviours

You can create classes to model behaviours, this could be things like validating, printing, logging.  These behaviours can be use in composition and used in multiple classes.  The benefit of modelling behaviours is reuse

  • Create abstract objects
  • Create real world objects

Reduce complexity

Classes reduce complexity by splitting code into abstract or logical sections.  The term abstract can be confusing, instead replace it with logical groups.  Splitting code into logical groups organises the code into smaller/reusable sections.

Breaking the code into classes creates cohesive code and reducing dependencies between classes.

Creating well named classes with well named methods reduces complexity and makes the code using those methods and classes easier to read/understand.

Creating classes and methods allows you to create descriptive methods, e.g. call the a print method is easier to understand than reading all the lines of code needed to print.  At a high level you might not need to know all the details of printing.

Manage the effect of change

Classes help reduce the effects of change by removing dependencies between classes (assuming the classes are well designed).  Using abstract classes can remove the effects of change on the code using the abstract classes.

Well designed code can make it easy to add new types by encapsulating what varies and programming to interfaces.  Adding a new type should not effect the other types or the code using the abstract class.

Managing the effects of change can reduce dependences and stop changes in code unexpectedly breaking other parts of the system.  You could rename this to limiting the effects of change by reducing the ripple effect change has on badly designed code.

Information hiding

Read my blog post Good coding practices – Information hiding

hold data instead of lots of parameters

You can structure classes to hold the data instead of passing lots of variables between methods.  This makes the code easier to understand and interact with.

Create reusable code

Many CRM projects I have worked on/inspected have had almost no code reuse partly due to the lack of classes created.  Part of the reason is attitude, CRM developers don’t view creating reusable code as a priority.

CRM organised internal entities to make it easier to understand how it works.  If we take security roles as an example.

The security role entity contains the main privileges which have a value of TRUE or FALSE and one of the four access levels Global, Business Child, Business unit, user.

Every time we add a new entity, we can set privileges for Create, Read, Write, Delete, Append, Append To, Assign, Share.

Whilst thinking about the example above I would except Privilege to be a separate class but we can see understanding the data in this structure is easier.

The benefits of designing classes 

The clean coder has a good change on classes which talks about change isolating change

Needs will change, therefore code will change. We learned in OO 101 that there are concrete classes, which contain implementation details (code), and abstract classes, which
represent concepts only. A client class depending upon concrete details is at risk when those details change. We can introduce interfaces and abstract classes to help isolate the impact of those details.

Abstraction and modularity allows developers to work on separate parts of a system without having a detailed knowledge of the whole system.

Plugins allow developers to create new plugins without affecting other plugins.  The crm dev needs to check there are no other plugins being triggered on the same entity.  Good design of the code is based on on the plugin interface and not the concrete class e.g. your plugin.

Well designed classes have many benefits

  • The code is created from many simple classes and methods
  • The code is easy to unit test
  • Well designed classes have minimal dependencies
  • Well designed classes should be able to be reused
  • Classes and method can make the code easier to understand
  • Good abstractions can be used in different projects

Coding to an interface

The benefits of coding to an interface and using classes behind the interface is you limit the effects of change behind the interface.

You can add new types behind the interface without affecting any of the code which uses the interface.

A quick example is routing records to different users or teams, for this you could create an interface called Route and then concrete classes will contain the routing details and default value of the users/teams.

Route – Interface

  • RouteToTeam
    • RouteToDefaultTeam
    • RouteToSalesTeam
    • RouteToMarketingTeam
  • RouteToUser
    • RouteToSalesManager
    • RouteToCaseManager

The benefits of coding to an interface and using classes

  1. Any code using the Route interface will be unaware of what specific type of route they are using.
  2. The code calling the interface has no knowledge of what objects, variables are used to route, it calls the Route interface methods
  3. Its easy to add new Routes which will involve changing minimal amount of code
  4. The code using the Interface is decoupled from the concrete classes
  5. The effects of change are restrained by the interface
  6. Easy to test
  7. Selecting the type can be done dynamically at runtime

Dependency Inversion Principle (DIP)

Reading about the Dependency Inversion Principle (DIP) helped me understand abstractions and the benefits of using them.  To remind you what DIP is

Depend on abstractions, not on concretions.

Wiki adds two more points to help understand

A. High-level modules should not depend on low-level modules. Both should depend on abstractions.
B. Abstractions should not depend on details. Details should depend on abstractions.

I highly recommend you read Uncle Bobs article The Dependency Inversion Principle, where he explains it a lot better than me.

This article DIP in the Wild has a good example of using DIP which helps understand  the concept and it’s usage in developer life.

Abstract ideas can be tricky to understand, to make this easier to understand think of black boxes.

Black boxes are code which works but the user of the black box doesn’t know how the code works inside the black box.  The internal code can change but the consumers of the black box wouldn’t know.

Change has been isolated inside the black box, Interfaces and abstract classes operate as black boxes hiding the change behind them.   Any code which interacts with an interface/abstract class won’t need to change if the internal workings behind the interfaces/abstract classes change.

A good example is using the CRM SDK to interact with the CRM database.  Microsoft can change how the internal workings of the CRM SDK change and can change the CRM database structure (in CRM 2015 they removed CRM database extension table).

Microsoft removed a whole table but CRM developers who used the SDK wouldn’t have noticed any difference (I didn’t notice) but those who developed code/reports directly against the CRM table would suddenly find their code/reports no longer worked when they upgraded to CRM 2015.

The next blog in the series is how to find Classes

CRM 2015 – CRM developers should think in Entities

The humble Entity is one of core building blocks of CRM and CRM development.

  • CRM developers need to view the world as entities
  • You need to translate users work items to entities
  • Understand out of the box entities and custom entities

When CRM developers look at things they should see things in entities like the matrix picture.

When a customer tells you the requirements you should be thinking about it in entities

You are an entity called CRM Developer!

What is an Entity

Entities do a lot in CRM, to understand what they are and what they do I think it helps to view them in different ways

Customer

Entities are used to model the business data of the customer to accompany the out of the box entities which exist in the default CRM system (account, task, contact, business unit)

CRM Database point of view

  • Every entity in CRM is a table in the CRM database.
  • Every field on an entity is a column on the entity table.

CRM Dev point of view

Most entities have at least one form in CRM.

Customizations are organised (to some extent around entities) in your solutions

Task

CRM Developer Plugins

Plugins are triggered by actions on Entities (you can add multiple triggers on a plugin).  The messages (read actions on an entity) aer

  • Create
  • Update
  • Delete
  • Retrieve
  • Retrieve Multiple
  • Assign
  • Share
  • Associate
  • Dissociate
  • Set State

Entity Status

Entities have a status and status reason.  These values can be used to drive the entity through a process/life cycle.  To learn more about Status and Status reason read the blogs below

CRM 2013 – Understanding Status and Status Reason – think before deleting them

CRM 2015 – how to find Statecode value

Security

Security roles set access rights on entities – Create, Read, Write, Delete, Append, Append To, Assign, Share.

Entities can be owned by users/teams and these provide access levels such as none, user, business unit, child business unit, organisational.

security

Start with the CRM SDK

When learning about topics in CRM it’s good policy to start with the CRM SDK and find the truth about entities, find out what properties and methods entities have.  When I use the term CRM SDK I mean the CRM SDK documentation

Development for Microsoft Dynamics CRM Online and on-premises (CRM SDK)

You could also look at the CRM Developer Website, which I wrote a blog about recently

CRM Developer Centre gets updated and it looks good

Entity

Microsoft.Xrm.Sdk.Entity

What properties/members do you get with the Entity

Entity Properties

The Entity has a number of properties but here are the keys ones

Attributes

The attributes parameter holds a collection of all the fields in an Entity.  The atrributes collection works by holding fields which have a value.  If a field is null it isn’t included in the attributes collection (when you call from plugins).

You often need to check for a value in the Attributes collection using the contains method

entity.Attributes.Contains(“name”);

This will create lots of if statements with contains, if true retrieve the attribute type code.  You can work around this by using Entity.GetAttributeValue which will get the value if the field exists in the Attributes collection or return the default value for simple variables or null for complex variables.  Read more about it using the link below

CRM 2013 – using Entity.GetAttributeValue instead of Entity.Contains

LogicalName
Each Entity has it’s own individual name stored as a string.  The logical name is useful because sometimes in the code you will need to know what type of entity it is e.g.

task, account, phonecall, contact.

The LogicalName can be useful if you have plugin code which is triggered on a number of different entities.

Id

The all important Id of the entity record.  This holds the Guid.  This is important because when you retrieve any information you can use this ID to retrieve the individual Entity record and ask for particular fields of interest.

EntityState

Gets the state of the entity, useful

Entity Abstraction and Early binding

Good practise for CRM developers is to use Early binding which will create an Entities file and allow you to create Account, Contact, Task records.

Early binding strongly types the field values for an entity.  These values are the same fields you would find in the attributes collection on the Entity object.

  • What are the benefits of early binding
  • Readability
  • moving type errors into compile time and not run time (e.g. compile time = developers, runtime = testing or users)
  • reduce syntax errors

The easy way to make your Entities file is to use the CRM Early bound generator

CRM 2013 Tool – CRM Early Bound Generator

Whilst you are there don’t forget to make your optionset enums

CRM 2013 – Create Enumerations for option sets

What has the Entity got to do with Abstraction?

When you are using early bound classes in your CRM code you are then extending Entity object with the new early bound classes

Entity –> Account, Contact, Task, etc

Using Entity can be useful when creating common functions because all your early bound classes inherit from Entity.

The code below checks the entity (which is an Entity object) to check the name.  The code in the example could be either a Task or PhoneCall.  The Complete activity either sets a task to completed or a phonecall to made.


            if (entity.LogicalName.Equals(Task.EntityLogicalName))
            {
                CompleteActivity(activity.ToEntity<Task>());
            }
            else if (entity.LogicalName.Equals(PhoneCall.EntityLogicalName))
            {
                CompleteActivity(activity.ToEntity<PhoneCall>());
            }

It’s useful to remember all early bound entities inherit from Entity.

EntityReference – Entity’s little brother

The EntityReference object in CRM is a lookup to an Entity object.  An EntityReference has LogicalName and Id (guid) of the entity.

When ever you see a lookup in a CRM form you know this is an EntityReference with just enough detail for you to retrieve the Entity object.

There is a good code tip is you can get an Entity Reference from an Entity object

Hosk CRM Dev Tip – Get EntityReference from Entity

EntityReference entRef = entity.ToEntityReference();

When creating new lookups on your forms, it’s best practise to put ID on the end of the field name, so CRM developers can easily find the lookups

Hosk CRM Dev Tip – add ID suffix to lookup fields