How to improve as Dynamics 365 developer

Everyone wants to improve but few want to put in the work needed to get better #HoskWisdom

Becoming a champion is not an easy process… It is done by focusing on what it takes to get there and not on getting there – Nick Saban

 

Improving as a Dynamics 365 developer takes dedication and persistence.  It takes years to build up your experience and knowledge but you can speed up the process by learning from the mistakes and experience of others.

This blog post my advice to Dynamics 365 developers who want to improve.  The core message of the post was written to a frustrated junior developer who wrote me an email simply saying “I want to stop making mistakes and get better, what is the quickest way to improve.”

A few posts improving and tips to improve, start by reading those

• Tips on how to become a CRM MVP from CRM MVP’S
• Tips to boost your career in Microsoft Dynamics CRM
• 12 Ways to become a better CRM Developer 

No shortcuts

Becoming a good Dynamics developer is difficult and takes time, which is why there are so few good Dynamics developers.

 No shortcuts to becoming an awesome Dynamics 365 developer 

It involves focus, effort and learning from your mistakes.  The more focus on improving the quicker you will improve.   It takes time for your skills, knowledge and experience to accumulate and learn from your mistakes.

Aim to finish work wiser about Microsoft Dynamics than you when you started.  Each day learn something new, improve your skills and reflect on your experiences

If you want to be a better coder then commit to being better and start being a better coder now #HoskCodeWisdom

There is no shortcut, only time and dedication.  Warren Buffett talks about Charlie Munger and his focus

“Charlie, as a very young lawyer, was probably getting $20 an hour. He thought to himself, “Who’s my most valuable client?” And he decided it was himself. So he decided to sell himself an hour each day. He did it early in the morning, working on these construction projects and real estate deals. Everybody should do this, be the client, and then work for other people, too, and sell yourself an hour a day.”

Enjoy being a Dynamics developer

 “You must understand the following: In order to master a field, you must love the subject and feel a profound connection to it. Your interest must transcend the field itself and border on the religious.” ― Robert Greene, Mastery 

 

If you don’t enjoy Dynamics development you will find the work boring and the days long.  If you are not passionate, you won’t care enough and you devote the time needed to improve.

Want to improve

Development is difficult but rewarding when you do it well #HoskCodeWisdom

Improvement comes from within, it‘s a desire to get better.  You need a passion for development, keep motivated, know why you want to improve if you don’t have a good reason you will give up.

It’s a slow process of continuous improvement, end each day learning something new or improving skills.  This is sucking less each day.  Junior Dynamics developers struggle with the limitations of Dynamics 365 functionality, often creating a customisation only to find due to a limitation the solution won’t work.

Why .NET developers struggle with CRM Development

A student mindset uses opportunities to learn and improve,  the more experience and knowledge you build the fewer mistakes you make.

“Most people don’t have the patience to absorb their minds in the fine points and minutiae that are intrinsically part of their work. They are in a hurry to create effects and make a splash; they think in large brush strokes.

Their work inevitably reveals their lack of attention to detail – it doesn’t connect deeply with the public, and it feels flimsy.”
― Robert Greene, Mastery

Visualise your day – plan your day

What will you check? What processes will you follow?  When visualizing the perfect day, remind yourself how you should do everything.

Plan your day, make sure you tackle the important tasks and don’t be reactive to change via email or requests.  Developers need to concentrate and focus on one task, avoid switching between many tasks and losing time through switching.

Don’t let email push low priority tasks to the front of the queue,  Email tasks can be the tasks which shout the loudest but the task you do next should be the most important.

Reflect

Learn from your experiences, review your mistakes you and avoid repeating them.  Inspecting how you work and adapting, keep improving.

Learn from your mistakes, identify patterns, catch yourself from being busy but not productive.

The person who doesn’t learn from their mistakes, repeats them.  Don’t waste your experiences, make the most of them.

Start with the SDK

The CRM SDK is the main tool for a CRM developer, the better a CRM developer knows its capabilities, limitations, and documentation the better they do their job.

Every time you don’t understand something, read the Dynamics 365 SDK, understand it, master it.

• Why CRM Developers should always start with the CRM SDK  
• Why you should read the What’s new for developers in the CRM SDK

Improve code quality

Read Clean Code: A Handbook of Agile Software Craftsmanship.  To write simple code you need to understand design principles are important, they decouple code and avoid making code brittle.

Brittle code with large methods is hard to read and breaks.  When you change one line of code ,it breaks other unrelated parts of the code.  Controlling dependencies and decoupling code allows you to manage the effects of change.

Naming is important, go back over your code and get the names of variables, methods and classes correct.  Like writing a book, developers never give the best names in the first draft, it‘s important to edit, refactor and refine your code.  The first draft gets it working, further drafts are to simplify and improve readability.

• 7 Design lessons for a developer
• How do you know your code is bad?
• Writing clean code  
• Steps to better code
• Good coding practices – Information hiding
• Why Code Readability is important

Design code

Don’t just write code. Think about it, design it, write it, refactor it, be proud of it #HoskCodeWisdom

Before you start typing, spend time designing your code, find classes and abstractions.  Designed code is easier to read, debug, reuse, unit test, maintain and extend.  All code has an impact, well-designed code minimizes the dependencies

• Why understanding abstractions can help you write better code
• Understanding levels of abstraction can improve your code design
• How to find classes
• Are CRM Developers are afraid of creating classes?
• CRM 2015 – CRM developers should think in Entities
• Are your CRM plugins creating technical debt?

Understand SOLID principles

SOLID principles are the building blocks of good code.  You will produce better quality code, fewer dependencies, and fewer problems later.  SOLID principles help developers recognise good code.

• Uncle Bob Principles of OOD
• SOLID architecture principle in C#
• SOLID – the first five principles of object oriented design
• Wikipedia SOLID

Help yourself

Don’t suffer in silence and sit frozen in front of the code, don’t waste time not making progress.  Don’t look give me the answer, I want to be pointed in the right direction.  Software development has lots of dead ends where to solve a problem you must rule out options and clarify assumptions.

Resolving your own problems is time-consuming, be pragmatic and know when to spend the time learning it yourself and when to get help.

A useful tool is to describe my problems to a toy/cardboard developer,  explaining the problem to the toy and myself I can uncover the solution and I avoid wasting other peoples time.

Why all developers should be friends with a cardboard developer

Understand how Dynamics CRM works

He who knows the most, get’s paid the most #HoskWisdom

Take every opportunity to understand how Dynamics 365 works. A greater knowledge of Dynamics 365 allows consistent choice of the right customisations and enabling quicker trouble shooting.

Dynamics 365 error messages point you in the right direction

Seek out what you are weakest

Improve knowledge and skills, build up your experience.  Don’t hide from these, focus and improve.  Use weaknesses and mistakes as triggers for learning.

Its better to learn functionality before it’s needed on a customer project, where the pressure is on and deadlines are looming.

How to cope when you are out of your Developer comfort zone

Learn from colleagues

Fellow developers are walking, talking troves of knowledge and experience,  learn from their experience.

Colleagues might be useful sources of knowledge but don’t ask them for help without trying to solve problems yourself.  Solving problems yourself gives you the solution and the learning.

The goal is to create customisations delivering the required functionality but it‘s the journey which improves your skills.  Create customisations and get senior developer to ratify your solution.

All developers have tips, tricks and shortcuts which can help you, if you ask and talk to them.

Write unit tests

Know how are you going to test the logic of your code, understand every line of code is doing what it should.

Test your code with unit tests, it‘s best practice and encourages you to write decoupled code which is easy to unit test.

• Why CRM Developers should unit test their code
• Information to Get started with Unit Testing with Microsoft Fakes and Microsoft Dynamics CRM 2013

A good framework is Unit Testing Microsoft Dynamics CRM using FakeXrmEasy Framework

At Capgemini we structure plugins to separate business logic and repository layer (CRM SDK CRUD) to make testable.

Unit tests are a vital part of emerging code design 

When manually testing, Don’t just test the happy path

Talk Dynamics 365

Talk Microsoft Dynamics 365 with your colleagues and you will learn something or at worst give information to someone else.

Share knowledge with the team and work together to create a broad knowledge of Dynamics 365 bringing in your differences experiences and thoughts.

Be organised

Don’t waste time looking for files, projects and code.  Be professional, be organised and minimise distractions.

• Why developers need to be organised and stop wasting time
• What’s slowing down your CRM development?

Get Certified

Certifications gives a more rounded and in-depth knowledge of Dynamics 365.  Investigating functionality in Dynamics 365 which they no practical experience of.

Dynamics 365 is the developers main tool, they should know it inside, outside, up and down.

• What are the benefits of CRM certifications

• CRM 2013 – Why you should take and pass the Configuration and Customization Certification 

Studying for Dynamics certifications helps to understand the limitations of Dynamics 365 functionality.  Limitations are key factors when deciding the right customization for a requirement.

Average is not good enough

Developer skills are like a snowball, they start off small and quickly pick up speed as your knowledge and skills grow #HoskWisdom

Don’t do average work, do great work.  Customers and other developers can quickly tell if someone is delivering quality work.  Good developers code works well and anticipates the needs of the users, it contains fewer bugs and when bugs are fixed they don’t bounce back.

Developers who work too quickly often don’t fully understand the requirements, don’t clarify them and deliver what they think the users want.  The code contains assumptions and bugs and never seems to be finished

Deliver code you are proud of

Don’t put non-supported customisations

If you write unsupported customisations Microsoft will not support your Dynamics 365 customisations.  A detailed explanation below

Why you shouldn’t put unsupported customizations in Microsoft Dynamics CRM

Know why things are not working

Errors and functionality not working is an opportunity to learn.  Don’t just find the solution on the internet, make sure you take the time to learn what the problem was and how/why it’s fixed.

Microsoft Dynamics CRM not working? check these common causes

The next problem you might get could be different and the better your understanding of Dynamics 365 the quicker you will be able to diagnose the problem.

Read CRM blogs

There are lots of great Dynamics 365 blogs which will help you keep up to date with the latest functionality in Dynamics 365, you can find a great list of them here

https://community.dynamics.com/crm/b

I also recommend follow these hashtags on twitter

• #MSDYN365
• #Dynamics365
• #HoskWisdom and #HoskCodeWisdom 🙂

Finally here are some of my other favourite blog posts I have written

• Why you should write code and customisations like a boy scout
• Are you a Dynamics Craftsman or a CRM developer?
• Bad code is like a virus, don’t get infected 
• You are not the end user 
• CRM Developers don’t know what they don’t know!

Advertisement

Dynamics 365 – Problems debugging fields on a form

“ If debugging is the process of removing software bugs, then programming must be the process of putting them in. ” – Edsger Dijkstra

Dynamics 365 is a place where only dirty entities and fields are saved! The clean fields are ignored #HoskCodeWisdom

• Junior developer – assumes how things work
• Good developer – finds out through trial and error
• Great developer – does not assume and methodically confirms

Dynamics 365 can frustrate developers (The Frustrations of a CRM Developer), developers are provoked by the idiosyncratics, limitations and bonkersness of Dynamics 365 as Microsoft works on new ways to annoy developers 🙂

Bugs and problems areopportunities to gain a deeper knowledge of the workings of Dynamics 365.

New developers get caught out such as in the CRM 2011 (good old) when SetSubmitMode was a rite of passage for Dynamics CRM developers – CRM 2011/2013 – What does setSubmitMode do? and how does it work?

Unless you made the field dirty and change SubmitMode the field was not sent to the database to be saved

Try, Try and try again

On creation of an appointment the start and end times should be editable, on a form update those fields should be readonly.

Examples of using the SetDisabled(true) were found in the code, copied and adapted for the start and end times on the appointment entity.

He kept debugging and being puzzled because the start and end times were not changing, but why not?

Insanity: doing the same thing over and over again and expecting different results.  Albert Einstein

Developer Insanity: Testing the same code over and over and expecting intermittent result #HoskCodeWisdom

Hosk developer debugging beliefs

• Investigate bugs with an empty mind
• Microsoft 365 is full of quirks which make sharing knowledge between team members important
• Bugs are not a sign of a bad developer, they are a sign of a developer developing #HoskCodeWisdom
• Always help your fellow developers, big projects need a strong team.  Never leave a developer stranded
• Don’t suffer in silence if you are not making progress, get help and get direction #HoskWisdom

SetDisabled = true

The way to make a read-only field editable is to use the Dynamics 365 JavaScript Xrm, get the control and use the setDisabled(false)

Xrm.Page.ui.controls.get(“your field name”).setDisabled (true); //Field readonly you can’t write any thing on field

if you change true as false;

Xrm.Page.ui.controls.get(“your field name”).setDisabled (false); //Anyone can put value on this field

I looked at the code, it looked fine, we checked a few things

• Is there any other code changing the field back to read only –> No
• Checked the line worked in the debugging console –> Yes
• Was there a JavaScript error –> No
• Debug the code, does it run the line of code which enables the field –> Yes

Appointment entity

In this example we used the appointment entity, which is an odd entity.  It‘s not possible to add new forms for the appointment entity Dynamics 365 – You can’t add new forms to the appointment entity There is code running on the appointment entity which a CRM developer has no control over, cannot see and cannot edit.

When you book appointment it sets the user who booked the appointment as the organizer of the appointment.  This is fine for Outlook but not what I wanted to happen in Dynamics 365.

Adding hidden custom code which developers can’t disable is frustrating as much as it is undocumented, I believe Microsoft should write customizations in the same way standard Dynamics 365 developers do. This would allow us to see, modify, disable or extend the default behavior.

Stop, think

When you rule out the obvious, it’s time to check the stupid – #HoskWisdom

Appointment entities don’t allow you to add new forms (or change the status/status reason of the appointment) because we couldn’t add new forms, we had JavaScript which when the regarding field was set to a specific custom entity we disabled the default section and showed a new section with custom fields on.

Usually a developer would create another form but we couldn’t because it was the appointment entity

This resulted in the same fields being on the form twice, the start and end times.  So the code was working, except it was making the fields on the hidden section and the first fields on the form.

To resolve the problem go to the section (in code) and then retrieve the field you want and then make it make it editable.

Hosk values with bug fixing

• Developers who fix a problem which doesn’t keep popping back because it‘s not properly fixed
• Developers who use a bug as an opportunity to learn how Dynamics 365 works
• Developers should try to resolve the problem first before asking for help
• Don’t spend too long being puzzled by a bug before asking for help, Dynamics 365 has odd quirks and limitations which can take hours to resolve.  Get direction from a colleague after 1 hour of frustration
• Developers should not assume, they must clarify (I wasted hours looking in the wrong place because I didn’t check my assumptions)

On a separate note but relatedish – Developers using JavaScript onload should be careful when setting and changing values because it can frustrate user by asking them to save a form when they haven’t change any values When to automatically change fields using Javascript 

picture from here

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 a 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.

• Definition of Software Craftsman
• Don’t be a Software Developer, be a Software Craftsman

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

• Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin)

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 Edition, Head 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.

• Where is the CRM Developer toolkit for CRM 2015?
• CRM Developer Toolkit Alternatives
• Getting the CRM Developer toolkit working with Visual Studio 2013

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‘s) which 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

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

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

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

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.

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

• CRM 2011/2013 – Common Plugin Errors and Isolation Mode
• Understanding Plugin sandbox mode
• CRM 2015 – Understanding impersonation in plugins and knowing when to use it
• CRM 2015 – How to decompile a plugin Assembly (DLL)
• CRM 2015 – Understanding the plugin profiler and a puzzling error

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

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

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

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

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.

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

 

Why all developers should be friends with a cardboard developer

I read an article  about a development team who used a cardboard developer.  The team had acquired a life-size cardboard person who they welcomed into the development team.

If anyone in the team had some code which wasn’t working, before asking another developer to sit with them to look at the problem the person had to first get the cardboard developer, stand him next to them, explain the problem to the cardboard developer, run through the code with him to see if he could help see the problem.

I have also learnt this process is known as Rubber duck debugging from the excellent book

The Pragmatic Programmer

The funny thing about this story is quite often the cardboard developer would help resolve the problem.

How exactly does a cardboard cut out help solve development problems and why aren’t companies deploying armies of them.

Stop! walk through the process step by step

The truth is people can often solve their own problems, once they understand the problem and walk through it.

This is what I would term as

can’t see the wood for the trees

This is a saying which regularly gets said, but I’m not sure everyone understands what it really means

Here is an explanation

Meaning: If you can’t see the wood for the trees, you can’t see the whole situation clearly because you’re looking too closely at small details, or because you’re too closely involved.

In terms of CRM development you can get  absorbed in a problem, the methods you have already tried to resolve it, you can get to a point where the CRM developer stops thinking logically about the problem.  For coding problems in particular you can get too close to the problem you forget to use a systematic process of trying to resolve the problem.

A classic example of the cardboard developer – Grumpy IT person

I’m sure many people have called the IT person in their organisation only to find they have given him the role of cardboard cut out.  You calmly explain the problem to the IT person (who is usually grumpy grumpily) to come and try and solve your problem.

When the IT person comes to your desk you go through the steps and it works perfectly and the IT person grunts and goes back to his warm nest away from troublesome users.

Many times I have asked someone to look at a problem and then as I was explaining it to them I instantly knew the answer.  It’s a similar sensation to not hearing someone, saying pardon and then your brain belated tells you what they said.

Why does the Cardboard developer work?

The reason the cardboard developer or any inanimate object works (it helps if it resembles a person or you feel stupid explaining your problem to an apple) is when you explain the problem to someone/something you

• You have stepped back from the problem, you have stopped to think
• Go through step by step
• Explain what you want to happen
• Explain what is happening

Developers often have to do the same/similar tasks many times they often

• Engage autopilot
• Stop thinking and just do
• Miss steps/Take shortcuts
• rush

Why should you use the Cardboard developer?

The main reason you should try using the cardboard developer is so you stop wasting other developers time when you could resolve the problem yourself.

Developers need to concentrate for a prolonged uninterrupted section of time (hours) to create a coding solution, this process involves concentrating on a problem with lots of trial and error.  Breaking this concentration for a developer to come and stand by you whilst you resolve the problem yourself can be frustrating for the developer who you have walked round the office and embarrassing for yourself for wasting the developers time.

To avoid wasting developers time I would advise getting up from your desk, going for a walk at lunch, making a cup of tea.  The act of stepping away from your computer will allow you to look at the problem with fresh eyes.

Make sure you use the Cardboard developer to go through a problem first before asking someone else.  I’m not advocating you sit and suffer with a problem but you should make sure you can’t resolve the problem yourself first.

This blog describes why Developers should not be disturbed

Why programmers work at night

or this graphic shows the process which I got from here

Today I used the Cardboard developer

Everyone has to use the cardboard developer and today I should have used the cardboard developer but instead I brought over Sir Les (senior CRM Developer) over to my desk.

I was creating a new development organisation.  I had imported a number of managed and unmanaged solutions.

The next stage was to import some data, I selected the file, press next a few times but then was puzzled why the entities weren’t in the drop down list?

I couldn’t think of any reason why entities don’t appear in drop down lists for importing?

So I got senior developer over.

The act of having someone looking over your shoulder suddenly gets your brain working with more focus.

Have you guessed the problem yet?????

Yes, suddenly it came to me,  I had imported some unmanaged solutions.  Unmanaged solutions need to be published (managed solutions are published automatically).  To understand the intricacies of solutions read my blog post – Understanding how CRM solutions work

Sir Les of CRM Shire was thanked and sent back to his desk, he helped me resolve the problem without doing anything.

Next time I will try explaining it to the cardboard developer before wasting a real developers time.

Check out the Dando the box man adventures

Here and here