Why CRM Developers should unit test their code

I haven’t written any unit tests for quite some time but I have decided to get back on the testing band wagon.  I will be writing more blog posts on unit testing but I thought I would start with a blog post about the benefits of unit testing.

When you mention unit tests to CRM developers or any developers is a bit of Marmite question.  Some developers love unit tests and some developers dislike writing unit tests and there isn’t much in the middle.

I believe most developers know they are beneficial but because they involve the tricky/boring setting up testing data and if you don’t write tests regularly they can seem difficult to write.

Writing Unit tests will mean you have more code to maintain but the benefits greatly out weight the negatives.

My experiences of unit testing and CRM projects is a lot of CRM practices are not using unit tests (I said this is my experience) or some of them write a few tests but this is usually down to the individual developer rather than a company process.

Why don’t CRM Developers unit test

Here are some of the common reasons/excuses

  • It takes too long
  • I haven’t got time
  • Integration tests will test the code
  • It’s too difficult to test CRM code because of PluginContext
  • The company doesn’t make unit testing compulsory

Benefits of Unit Testing

  1. You already test your code, make the tests reusable and available to others
  2. Tests prove the code works
  3. Unit Tests make you try to break and then fix your code
  4. You can make big changes to the code and test the code still works
  5. The tests can be run every time the code is changed
  6. Testing is not slower
  7. Writing code to be tested creates better code
  8. Testing reduces the number of bugs in the code
  9. Refactoring the code can be done easier and with confidence
  10. It’s great when you get a green light
  11. Unit tests make the code more readable and understandable
  12. Testing before you code helps improve the design of the code
  13. Writing unit tests stops coders block
  14. Less bugs make it out of Development
  15. Bugs unit tested stay fixed
  16. Unit Tests will help you when you have forgotten the business logic
  17. Changing code in one part of the system can break code in another part of the system
  18. You only write test for the required functionality

You already test your code, make the tests reusable and available to others

When a CRM developer writes some code he often tests the code either by creating a console app or by debugging the code (either using the plugin profiler or remote debugging on the server).

I know you are testing your code because you have to test the code before you deploy it.  A lot of CRM developers hope they will find the bugs by integration testing and testing the code from the front end (the CRM web application).

The problem with integration testing is it takes longer to test the code and you have to create the data and test the functionality again every time.

Once you write a unit test to test one part of your functionality you can rerun the test again and again, instead of having to run through the process manually.

Instead of writing a console app or debugging the code, unit tests will enable you have tests you can rerun and more importantly you will have tests other developers can read and run.  If in the future another developer has to fix some code in that area they will have tests to help document the code and will be able to make changes and test the code.

Tests prove the code works

Writing and running unit tests shows the code works and passes the tests.  This depends on you writing effective tests but most of the time you will write tests to test the functionality required.  If you are using Test Driven Development you will write the tests first and then write the code.

Unit Tests make you try to break and then fix your code

When writing unit tests developers will often try to break the code by passing in Null values or unexpected inputs.  These are easy tests to write and help reduce easy/lazy errors from entering the production system.

Often if you are not unit testing the code you don’t think to write defensive code because the main priority is to test the functionality required

You can make big changes to the code and test the code still works

One of the main benefits of writing unit tests is you have created tests to test the functionality.  This means you can change the code and run the tests again to see if it still works.  You can refactor the code with confidence you can test it.

This is an important point for developers who are scared changing some legacy code because they are not sure what code depends on what.

The tests can be run every time the code is changed

Code can get changed lots of time particularly if it’s in a core piece of functionality.  Having tests which can be easily and quickly run every time the code is changed will give you confidence nothing is broken.

When bug fixing often CRM Developers will fix parts of the code they didn’t work on or have little knowledge of.  Unit tests will give the CRM developer confidence their fixes haven’t accidentally broken the code.

Testing is not slower

It would seem logical to think writing units would make the process of writing code longer.  The truth is this isn’t true.  A lot of the time spent on code is fixing bugs after the initial development is done.  Unit testing will help you find more of these bugs up front and reduce the time spent bug fixing.

Writing code to be tested creates better code

When you write code which is easily testable it tends to be better designed and adheres to the single responsibility principle and the code is more modular and reusable.

The developer will also spend more time thinking and designing the code.  Code which is easy to test is easier to maintain and has loose coupling and dependency.

Testing reduces the number of bugs in the code

When a developer writes unit tests they test their code in a more systematic approach and testing various different scenarios.  When CRM Developers manually test their code they usually go follow one or two successful paths through the code.

Refactoring the code can be done easier and with confidence

Refactoring the code can be a lot more confidence when the developer can test the code with unit tests.

It’s great when you get a green light

It’s a great to write a test and then get the green light.  Not only is it a small win it’s great to see how many tests you have running against a piece of code.

Unit tests make the code more readable and understandable

Unit tests

Testing before you code helps improve the design of the code

Writing tests before you have written the code will help the developer think about the design of the code, what they are trying to achieve.

When thinking about writing tests for code the developer will try to simplify the code to make it easier to test.   This process will make the code easier to maintain, debug, extend and understand.

Writing unit tests stops coders block

Writing unit tests stops developers suffering from coders block.  Coders block is when a developers gets overwhelmed by the task of designing the code and doesn’t know where to start.  Writing units tests gets the developer writing code and gives the developer an easy place to start.

The developer can refactor and improve the design of the code later and will be able to test the code works with the unit tests.

Less bugs make it out of Development

CRM Development is complex and the code can contain many bugs.  The aim is to squash as many in the development environment as possible.  Unit testing is one of the tools used to find and fix bugs.

Code reviews and integration testing are the other two main bug detectors.

Unit testing won’t find all the bugs and doesn’t mean you don’t have to do code reviews and integration testing but it will help the CRM developer to find some bugs in his code.

Finding bugs in the development environment is quicker than finding bugs in a production environment, logging the bug, recreating the bug, debugging the code, fixing the bug, retesting and pushing the bug all the way back up towards production.

Bugs unit tested stay fixed

When you fix a bug and unit test the fix, it’s more likely to stay fixed and if it isn’t fixed it can quickly be tested again.

Unit Tests will help you when you have forgotten the business logic

Unit tests are a great way to document the code because you it’s easy to see what the code should be doing by looking at what the test is testing.

Business logic fades (quicker than you think) so a developer has a bug to fix the unit tests will help the developer understand what the code should do.  The CRM developer will be able to quickly test the code with the unit tests.

Changing code in one part of the system can break code in another part of the system

I call this “accidental bugging,” and
it seems to occur a lot near the end of a software project, when developers
are under pressure to fix existing bugs. Sometimes they introduce
new bugs inadvertently as they solve the old ones. Wouldn’t it
be great to know that you broke something within three minutes of
breaking it? We’ll see how that can be done later in this book.

You only write test for the required functionality

You only write unit tests to test for functionality required.  This is a good way to stop developers adding in extra functionality which might be needed in the future.

More reading on why you should unit test

Is Unit Testing worth the effort? 

I Pity The Fool Who Doesn’t Write Unit Tests

Top 12 Reasons to Write Unit Tests

Write Maintainable Unit Tests That Will Save You Time And Tears

Advertisements

Hosk’s Top CRM Articles of the week – 27th March

Article of the Week

Building multi-tenant web apps talking to CRM
Great post from CRM MVP David Yack

Best of the Rest

Microsoft Dynamics CRM 2015 – Global Navigation UI Changes

Have a look at the new CRM 2015 navigation changes

Why developers need to be organised and stop wasting time

A Hosk Developer article about why developers should be organised and structured just like the good code they write

no code alerts from Leon Tribe

I like it when bloggers put codeless or no code solution in the title because I know what I’m going

Tip #349: Bulk delete in bulk over multiple entities

You can bulk delete over multiple entities, I never knew that

CRM 2013 – Error using Plugin Profiler – Could not load file or assembly ‘Microsoft.Xrm.Sdk, Version=5.0.0.0

Interesting error about debugging using the plugin profiler.  The plugin profiler used to debug must match the CRM dll

the CRM chart guy – Add Key Figures to Dashboards in MS Dynamics CRM

Another great blog from the king of CRM charts

CRM 2015 – Workaround for bug: “managed solution cannot be deleted”

Good article about deleting a managed solution which refused to be deleted

CRM 2015 – Understanding the plugin profiler and a puzzling error

A Hosk article about the plugin profiler

CRM 2015 SDK and the CRM 2013 developer toolkit

Getting the CRM 2015 SDK and CRM 2013 dev toolkit to play nicely.  Hey Microsoft where is the CRM Developer toolkit for CRM 2015, it’s been ages

CRM 2013 – How to change the field label size

The settings for changing field label sizes are hidden in the section!

Tip #351: Tracing for plugins and custom workflow activities

Tracing for CRM online

Using the Configuration Data Migration Tool with non-unique display name values

Scott Durow helps people understand and get round this gotcha

Turbo forms in CRM 2015 – interesting article from CRM MVP Mitch Milam

Great blog post from Mitch about the new turbo forms

Rollup fields

CRM MVP Jukka explains how rollup fields work

 

Last Weeks Top CRM Articles

Hosk’s Top CRM Articles of the week – 20th March

Useful Hosk Links

Hosk list Of CRM 2013 Tools

A list and review of CRM 2013 tools, this will probably work in CRM 2015 as well

Hosk’s CRM Developer Articles

A collection of my favourite CRM Developer articles I have written

MB2-703 – CRM 2013 Customization and Configuration Certification Information

All the CRM 2013 content to help you pass the exam

HoskWisdom – Hosk Developer Quotes

 Words of Wisdom from the Hosk.  I have written over 900 articles, surely I should have said a few memorable things

Why developers need to be organised and stop wasting time

In this blog post  I will tackle the subject of being organised in your CRM development.

CRM developers may not think being organised and structuring their development environment is very important and are already starting to think BORING.

Cluttered and unstructured development environments will contribute to a CRM developer wasting time on a daily basis.  Read more to find out why and how you can organise yourself.

It’s OK to be messy outside of work  but when developing you should have a professional mindset and be focused, organised and structured in your work.

Why are some people messy and some people tidy?

The brain is a mystery inside a riddle riding on the back of a conundrum, whilst sitting in the ear of a problem.  – Hosk

There are thousands of articles on the topic of being tidy/messy, what this says about your personality, how to be tidier.  Here is a little brain food snack on the subject

Unfuck Your Habitat: tidy advice for messy people

A messy (or tidy) desk may reveal personality traits, such as creativity, generosity: U.S. study

The Psychology Behind Messy Rooms: Why The Most Creative People Flourish In Clutter

Personally I am a messy person, I seem to enjoy clutter.  Maybe I am viewing this the wrong way, Tidy people cannot seem to be comfortable in an untidy/messy room.

If I were to guess I would imagine this must be linked to the brain and perhaps creative people are more comfortable with clutter, maybe due to creativity being an inspirational, unordered processes.

I am not yet persuaded either way with regards to the effects of tidy/untidy desks on a person, I believe tidy people write articles promoting tidy desks and people with untidy desk write articles about the boost in creativity of untidy desks and somewhere in between is a tidy desk with messy drawers full of stuff.

Tidying is a habit

I have trained myself (a bit) and have been trained (nagged) into being tidier and I have found this is a habit.  I read this book Level Up Your Day: How to Maximize the 6 Essential Areas of Your Daily Routine which had some interesting

  • Tidy up the plates after dinner
  • When you have finished lunch
  • put the clean washing directly into the drawers and cupboards
  • make your bed in the morning

You can also link the habits into a small chain

This article from the excellent Farnham street blog shows tidying and decluttering is a state of mind

The article is excellent (as is the blog), it made me think differently about clutter and why people persistently refuse to throw items away, despite knowing they are unlikely to use them.

I assume it’s part of getting older but I have become less attached to items/things in recent years and I enjoy getting rid of things.  Why hoard films, CDs, books I don’t plan on using again.  Decluttering is a by-product of having children when you have to get rid of all your stuff to make room for loud plastic toys.

Another article not about actual CRM Development

You might be wondering why is Hosk writing another article which doesn’t contain examples of code or customizations.

If you think how much time you spend actually writing code.  In my blog post Should you hire a Rockstar developer for your CRM project?

I mention what non-coding writing tasks developers have to do, not to mention the rule the more senior you become the less code you get to write.

  • Gathering/understanding requirements
  • Documentation
  • Meetings
  • Learning
  • Code reviews/mentoring/explaining
  • Code Design

Being a developer isn’t just about creating code and customizations, there are lots of other skills and knowledge you need to become a great developer.

Messy developers are wasting time

I said earlier I was an untidy person with a messy desk, my desk could be described

  • untidy
  • messy
  • disorganized
  • inconsistent

Having these traits as a developer will make your life harder not easier.

Some of the traits mentioned above are signs of a unprofessional\poor development and are mentioned in the article – The problems with complex code and complex CRM Customizations

Here are some of the main culprits of complex code
  • Large methods – Monster methods
  • confusingly named classes, methods and variables
  • methods which do lots of things
  • not consistent
  • tight coupling
  • dependent code
  • poorly structured code

The result of complex code is to make the code/customizations hard to understand, modify, debug and extend.

If you were to replace the word method with folder you can see how being disorganised is making your development environment more complex and harder to use.  The harder your own development environment is to understand and use the longer everything takes.

Let’s take some points and translate them to the development environment

  • Large folders which have lots of different documents in
  • No structure to anything
  • Poorly named folders, documents
  • Internet browsers with lots of disorganised bookmarks
  • No Standard approach to Documents
  • Ad Hoc approach to TFS projects

The goal of being organised is to make things simplier, easier to understand and use, the same as the goal of writing good customizations – Why your CRM code and customizations should be simple

The concepts can be used when thinking about your development environment.

Manage complexity and make your development environment simplier

Examples

I was helping some junior developers set up some project code on their computer.  This involved checking some code out of TFS and then doing a bit of configuration.

They started off putting the projects in different locations

My Documents

C:\

Then we needed to get some DLL’s from the CRM SDK, we looked in 3 or 4 locations before we found the right folder.

The problem is only going to get worse the more projects the developer works on and the more versions of CRM which are released.

You might believe I am being picky but consider finding projects, SDK location, CRM tools/solutions, customer are very common tasks a developer will perform multiple times a day.  If the developer doesn’t know where these things automatically they will be wasting time every time.  This will add cumulatively over time and all these little bits of time will add up to a lot.

Why being organised/structured important for developers

I remember when England won the rugby, Jonny Wilkinson was like the David Beckham of English rugby, always delivering a brilliant performance on the big occasions and indeed kicking the winning drop-kick.

Like David Beckham Jonny Wilkinson was a prodigious practicer, he would spend hours kicking, kicking and then some more kicking.

Wilkinson had a distinctive technique which would involve going through exactly the same steps for every kick, one part of preparing for the kick is putting his hands together

you can read about his technique

It’s all in the hands

How Do I Kick Like Jonny Wilkinson? A serious kicking regime

Wilkinson himself breaks his regime down into four parts – ball position, measuring the run-up, visualising the ball flight and striking the sweet spot on the ball.

The process Wilkinson goes through during every kick is aimed to focus just on the action of kicking the ball and blocking out all the distractions.

If you compare this to CRM development, there are lots of distractions trying to take your focus away from doing the CRM development

  • People
  • Where have I put that file
  • The internet

You need to block out the distractions and focus on the CRM Development, e.g block out the noise.

What can CRM developers learn from this

In my article Good CRM design should not make users think 

A well designed CRM system is where users use the system instinctively without needing to stop and think – Hosk

If a user stops to think, the user experience goes down and ease of use drops right off, whilst the user searches for clues for where to go or what to do next.  This is time wasted thinking about what to do rather than doing it.

A similar experience can happen to developers if they have not organised their development environment.

A disorganized development environment will lead to the developer searching for files/tools/documents/source code instead of developing.  If this happens on constant basis the developer can not only have their concentration broken but they can waste lots of time.

Consider the effects of disrupting your focus, developers often need to focus for blocks of hours and disruptions can break you train of thought.

What should be ordered in the developers environment

There are lots of areas of your development environment which should be order the

Folders

I believe it’s important to have consistent folder structures on your computer for each of these areas

Projects

CRM versions

Documentation

I put  my projects in a folder C:\Projects, I know where to look for each project I have checked out of TFS.

I have a CRM  year number (CRM 2013, CRM 2015) off the project folder.  Inside the CRM version I have a folders

  • SDK
  • Tools
  • Solutions
  • Books
  • Documentation

Servers

You will have lots of CRM servers (front end, back end), SQL servers and maybe some other servers.

Have a consisten folder structor and include the same tools on each server.

C:\Company name

you could have folder for tools, documentation, config, 3rd party software, Release

It will will help to have a consistent deployment process, this will not only help with the deployment process but will also help you see what has been deployed and older solution files which might be needed to rollback changes.

Internet Browsers

Don’t have an ever growing list of bookmarks, which slowly grows bigger and bigger.

Use the favourites bar and use folders

Staying up to date with CRM

This isn’t really the development environment but I will add it.

Get an RSS reader software (feedly, Netvibes, outlook, pulse).  Subscribe to popular CRM blogs.  If you want a list of CRM blogs check out step 1 on the blog Tips to boost your career in Microsoft Dynamics CRM

Twitter

You can get windows applications but Tweetdeck is a fantastic chrome extension.  I would then setup a list to follow some great CRM tweeters.

CRM Admin

Create a CRM admin users for each CRM organisation, make this user a deployment administrator.  This stops the potential problems which can arise when you lock this functionality to individual users.  When the CRM admin, deployment administrator is a single user

The Benefits of an ordered and structured environment

Your development environment should be structured and organised so you can use it quickly, efficently and without thinking.

Your development environment should be consistently structured, so when you switch between projects you know exactly where to look.

The benefit of an organised development environment is it doesn’t slow you down or make you stop to think where to put or where to find items.

Like code you will need to refactor your development environment to ensure it doesn’t get too messy and complex.

Unstructured development environment seems like a small sin but due to the high usage, slower usage will be multiplied many times during a day/week/month/year and could cost a developer a great deal of time by the end of the year.

CRM developers spend enough time on non-coding tasks, don’t reduce the time you have by wasting it on navigating your development environment.

CRM 2013 – Error using Plugin Profiler – Could not load file or assembly ‘Microsoft.Xrm.Sdk, Version=5.0.0.0

I was working on a project and one of my plugins was throwing an error, so I fired up the Plugin profiler to debug it.  This is the second article I have written about the Plugin Profiler this week

CRM 2015 – Understanding the plugin profiler and a puzzling error

If you want some step by step instructions for debugging with CRM 2013 Plugin Registration tool, this article is pretty good

Debugging online plugin in CRM 2013

Error whilst debugging

I loaded up CRM 2013 plugin profiler, oohed and ahhed at the spruced up appearance.

I installed the profiler

I triggered by plugin by creating a record

This gave me the serialized error, I downloaded it.

Debugged in the Plugin registration tool, choose my dll and downloaded txt.

Attached to the process in Visual Studio and started debugging.

The code instantly threw an error

Could not load file or assembly ‘Microsoft.Xrm.Sdk, Version=5.0.0.0

I have seen many CRM error in my time and they are usually a bit misleading but this error told me it couldn’t load the Microsoft.Xrm.Sdk version 5.0.0.0

The CRM SDK has versions which are different from the CRM release, it is what CRM would be if it used sensible numbering instead of years.

e.g.

CRM 2011 – Version 5.0.0.0

CRM 2013 – Version 6.0.0.0

CRM 2015 – Version 7.0.0.0

You can see the CRM SDK versions if you go to this page

CRM SDK 2013 Release History

CRM SDK 2015 Release History

The zero’s will go up as service releases and patches are released by the important number is the first digit.

I was debugging a CRM 2013 instance but it was complaining about a missing CRM 2011 SDK dll!

Let me try something

I had a thought, why don’t I try using the CRM 2011 plugin registration tool but surely this wouldn’t work.

So I connected the CRM 2011 Plugin registration and used it to debug my plugin.

Now I have to admit I wasn’t expecting it to work but

What has happened

It seems I am working with a CRM 2013 project but the DLL’s used in the plugins are CRM 2011, I went off to check the dlls being used by the plugins

version 6

I’m guessing someone created a new CRM project and copied the DLL’s from a CRM 2011 project.  This will work fine unless you need to use any of the new functionality in the CRM 2013 SDK.

It might also bring up an unusual error sometime in the future.

It’s interesting to note the core plugin functionality is the same between version CRM 2011 and CRM 2013.

 

CRM 2013 – How to change the field label size

I had created some new fields, I put them onto the form and I found I couldn’t see half of the text, GRRRR

resizing labels

This was very annoying, annoying like The most annoying type of airline passenger is 

There must be a way to resize fields

I clicked on the field but couldn’t find anything useful

resizing labels 2

resizing labels 1

 

Engage Critical thinking

I was sure somewhere you can change this setting.  I was sure I have set the labels to be above the fields.

Thinking critically I thought the next possible place to set fields will be the section and there it was

You Label width for all the fields in a section is held in Display – Width

resizing labels 3

In formatting you can also set the alignment and label position

resizing labels 4

 

I changed the width to 200 and bam I could see all the text

resizing labels 5

CRM 2015 – Understanding the plugin profiler and a puzzling error

I am a big fan of debugging my plugins using the plugin profiler, it’s easy, quick and you can do it on your own computer without adversely affecting any fellow developers

The alternative for debugging plugins is to debug on the server, I usually don’t like doing this because if the plugin is not in the sandbox is can stop the whole server and I have personally found remote debugging doesn’t always work with the debugger dropping off after 30 seconds.

Puzzling problem with the plugin profiler

Recently a CRM developer was debugging using the plugin profiler and he had a puzzling problem

He was creating a plugin which fired on post event of creating  which when a new entity was created, it created a Task, which referenced the newly created entity.

Here is a brief description of what the code was doing

  • created a new task
  • update the description on the task
  • set the Regarding to be an entity reference to the newly created Entity

The code was erroring, the CRM developer was puzzled.

This problem is what I would call a CRM riddle and to get to the answer you need to do a bit of thinking.

When you are investigating a bug you need to reject your prejudices and biases.  You probably have an idea of the cause of the problem and it’s fine to check this first but if it isn’t the cause you need to make sure you are systematic and logical in your investigating.

I have written a blog post recently where I have investigated a bug, you need to investigate bugs like Sherlock holmes looking for clues – Sherlock Hosk and the case of the annoying bug

When debugging, eliminate what isn’t causing the problem and whatever code or customization is left must be the culprit. – Sherlock Hosk 

When testing your code I alway feel it’s just as valuable to find out what isn’t causing the problem because you are narrowing down the list of potential causes for the bug.

This highlights the process you should use, methodological, changing one variable at a time.

In the article Why all developers should be friends with a cardboard developer,  I suggest, you get the cardboard developer to stand next to 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

For debugging I would add these points

  • change one variable
  • Test to see if problem is resolved
  • repeat

A mistake a lot of CRM developers make when testing for a bug is changing lots of variables and then not knowing what change has resolved the problem. If you do this you are now in a pickle because it means you have to change all the variables again or get the customer to change all of the variables to resolve the problem.  The other choice is you test again, changing one variable at a time.

Understanding the plugin profiler

To understand the problem you need to understand how the plugin profiler works.

Here is a good step by step guide

Debugging online plugin in CRM 2013

When you turn on profiling the profiler works by capturing all the data being sent and serializing it all into a file and then throwing an error.

This is why you see the error message

#exception (Recommended)

When the profiled component is triggered, an exception will be thrown with the compressed profile in the error message

Below is a picture from the step by step guide above

This is really like adding some code at the end of your plugin throws a InvalidPlugInExecutionException, which would roll back the transaction and not save those changes to the CRM database.  (I’m not sure it does throw an InvalidPluginExecutionException but I am saying it acts as if it does)

This allows you to keep running the test without the plugin creating/updating any records in CRM.  It means you can trigger the plugin multiple times.

Back to the Problem

We know when using the Plugin profiler to debug records don’t get updated or created.

This plugin was being triggered on the create message of a record. Let’s say it was the contact record.

The user put in the contact details, pressed save to create the contact record. This action was captured by the plugin profiler and saved to a serialized file with the InvalidPlugInExecutionException so the record was not being created.

The CRM developer was stepping through the code using the plugin profiler.  The plugin was creating a task, the next step tried to set the regarding to the newly created record.

The problem was being caused by the plugin profiler.  The CRM Developer was running the code in the plugin profiler the on the create of the contact record, the code was creating a new task record and attempting to set the regarding on the task to the newly created contact record but it was throwing an error because the contact record didn’t exist.

When the CRM developer turned off the plugin profiler the code worked fine but this left him confused for a while.

Understanding the how CRM works is important

I am often saying in blog posts

Always start with the CRM SDK

When I say this I mean CRM Developers should first look in the CRM SDK to see if they can understand how this part of the system is working, try to understand the underlying logic of CRM.

Most developers find example code by taking the easy option and searching the internet, finding a code example which someone has written, copying and modifying and using it.

The problem with this is you don’t learn how or why the code works and the CRM developer will not understand the process behind the code.

When you try to create the code yourself, you will experience lots of small errors but overcome them.

CRM Developers first find out how things don’t work to understand how CRM customizations do work – Hosk

In my blog post CRM 2013 – How to get guid of initiating record in CustomWorkflow

I couldn’t work out how to get guid of the initiating record of a custom workflow.  The reason for this was the plugin context passes in a target field and this has the initiating entity.

Custom workflows do not have a target instead they have PrimaryEntityId.

I found out this information by looking in the CRM SDK and thinking about the problem.

The puzzling plugin profiler problem puzzled the CRM developer enough to ask me what was going on, why did it work when the CRM developer stopped using the plugin profiler?

It’s important to understand how CRM works because when things go wrong and errors start popping up, this is when understanding how CRM customizations work will help you work out what the problem is but if you haven’t stopped to learn how things work then they will continue to be a mystery and resolving the errors will be very difficult.

What does the CRM SDK say

if you search the CRM SDK for plugin profiler you will probably get to this page

Analyze plug-in performance

This is a great page with lots of information, below is an excellent description of how the plugin profiler replay works

Replaying plug-in execution does not require a connection to a Microsoft Dynamics CRM server and organization. The advantage of this method is that you can obtain the plug-in execution profile from a customer and debug the plug-in remotely. A restriction of the replay feature is that you cannot change the sequence of calls your plug-in code makes in the debugger while you are debugging.

The replay feature provides the plug-in with a snapshot of the call data and event execution context from the Microsoft Dynamics CRM server. You are getting the same events, GUIDs, and so on from calls to the Organization service but no data is being modified on the server as you debug the plug-in. During the debugging procedure in the previous section, the plug-in actually connects to the server and makes calls in real time.

Whenever I read the CRM SDK I always learn something new, here is what I learned from the paragraphs above

  • The plugin profiler doesn’t need a CRM connection to work
  • You can profile on a customer production system and debug remotely
  • You get a snapshot of the data -same events and same guids
  • No data is being modified

Hosk’s Top CRM Articles of the week – 20th March

Article of the week

turn CRM green

The article of the week showcases the new themes which look awesome.

What’s new for Microsoft Dynamics CRM Online 2015 Update 1

An overview of the new functionality coming in CRM 2015 U1 and if you are not sure why shoul read it then read this – Why you should read the What’s new for developers CRM 2015 SDK 

Best of the Rest

The rest of the article are mainly around the new CRM 2015 highlights and functionality

CRM Online (Carina) API Enhancements Highlights

Tip #346: Scheduling daily bulk delete jobs

This is one of those tips which is good to know because you might need it sometime in the future

Hosk CRM DEV Tip – Always filter your queries

Why you should always filter your queries in CRM.

What’s New with CRM Online (Carina) Highlights

Why all developers should be friends with a cardboard developer

Also known as rubber ducking but this is a method to help you resolve your problems yourself without wasting your fellow CRM Developers precious time

A few interesting things I learnt from the many convergence 2015 tweets

The Hosk’s very brief twitter  highlights from convergence 2015

Release history for the CRM SDK

Interesting I have never seen this document before

get ready for the next release CRM 2015 UR 1

A General overview of the new functionality coming your way

Dynamics CRM 2015 Update 1 SDK assemblies preview (7.1)

You can get the new assemblies quicker if you tick the preview button

http://leontribe.blogspot.de/2015/03/marcs-lemonade-stand-2015.html

CRM MVP Lleon Tribe gives the low down on salesforce using a lemonade stand so everyone can understand

CRM 2015 – resizing the social tab

it is possible to resize the social tab, find out how

CRM 2015 new release has themes

you can change the colour and add a logo

Deploying a CRM2015 solution to CRM2013
Good article on deploying CRM solutions

CRM 2015 roadmap

What changes are coming down the pipe

See what’s new in the CRM2015 Online Update 1 ‘Carina’ SDK

Last Weeks Top CRM Articles

Hosk’s Top CRM Articles of the week – 13th March

Useful Hosk Links

Hosk list Of CRM 2013 Tools

A list and review of CRM 2013 tools, this will probably work in CRM 2015 as well

Hosk’s CRM Developer Articles

A collection of my favourite CRM Developer articles I have written

MB2-703 – CRM 2013 Customization and Configuration Certification Information

All the CRM 2013 content to help you pass the exam

HoskWisdom – Hosk Developer Quotes

 Words of Wisdom from the Hosk.  I have written over 900 articles, surely I should have said a few memorable things