CRM 2013 Tool Review – Dynamics CRM Organisation Settings Editor

I was getting a timeout error when importing a solution (actually a whole bunch of errors but I won’t go into that now) and I searched the internet for the answer and came right back to my own blog, thanks Marvelous Hosk for writing that blog post

CRM 2011 – A time-out occurs when you import a solution in Microsoft Dynamics CRM 2011

The blog and KB article link said I should update the OLEDBTimeout value.  It jogged my memory to try out the The Dynamics CRM Organisation Settings Editor or OrgDBOrgSettings as it is known.

The tool was created by seanmcne who is a CRM Premier Field Engineer on the Dynamics PFE Team (I refer to as the A Team) and he has been working with CRM since 2004 and Microsoft CRM 1.0!!

The first thing I will add this tool has some great simple documentation.

What does it do

I will quote from the codeplex site for the project

This is a utility allowing admins of Dynamics CRM (2011/2013 – online & onPrem) to edit their organization database settings otherwise known as OrgDBOrgSettings

This utility allows you to edit your settings without the use of the command line utility in the KB article documenting “OrgDBOrgSettings.” The utility is written using the CRM SDK as a reference and currently all changes and retrieval of settings are done via the CRM’s OData Endpoint. The utility is provided as a managed webresource that can easily be installed and uninstalled from your CRM environment.

How is it setup

The project is a managed solution and only adds a few files.  You may add it, change the values and remove it

How do I use it

once you have imported the solution, go to solutions, click on the solution

Organization Settings Editor

Then here  click on configuration and this is where you can use the solution to change the DBOrg settings

Below is the screen you will see

What version of CRM

It will work with CRM 2011 and CRM 2013 and I should think it will continue to work with CRM 2015

Why is good

The reason why it is good because it means you can Add/Edit OrgDBOrgSettings without using a command line tool.

A really great piece of functionality is it links to the KBArticle, so you can understand what the change will do and why you might need to do it.

I also think it’s good it doesn’t have its own site map button because it means it just hides itself away.


For those of your sharp-eyed folk you will of course notice the OLEDBTimeout setting isn’t in the database – OrgDBOrgSettings it’s actually in registry of the CRM Server.

My article didn’t help because the timeout was already set to a large number and the web config httpRuntime maxRequestLength had been increased, so it’s back to the drawing board for this error

More CRM 2013 Tool Reviews

How to add your CRM 2013 server name to your hosts file

In your Dev environment/internal CRM environment you will often have big server names


it could be something like this


So then your CRM url is something like this


to make life a bit easier for yourself you can add the computer into your hosts file which will mean you can then use a smaller friendlier name




which would come out like this


first you need to get the ip of the server


type cmd on your start menu

open the command line tool

type ping and the name of the server


this should return the ip address


Now you need to edit the hosts file.  This is a proper old windows file and on Windows 7 I found it here

if you can’t see the hosts file you might need to make some files not hidden, follow this guide
Then edit the hosts file
ip SPACE new server short name
111.22.333.44 HoskDev01
You may need to open and save the record as administrator.  or copy the file to your desktop, change it and copy it back over
now you should be able to access crm using your friendly, shorter name

CRM 2011/2013 – System.InvalidCastException: Unable to cast object of type ‘Microsoft.Xrm.Sdk.Entity’ to type

I had an odd error today whilst developing and it turned out to be a very frustrating few hours.

I was writing a plugin which would work for Lead and Contact and because of this I was using a mixture of late binding and early binding.

The late binding was used because I was writing a plugin to fire on update and create of a lead/contact. It was working out the salutation. It was different entities but the same field names.

So I used Entity object and late binding to get the values of a 2 field, I was using these values to retrieve the data from another entity which was early bound.

My personal preference is to use early binding because I find the code is easier to read, it’s also a lot easier to  write because you can use intellisense to get the fields rather than looking at the exact field name.  The other benefit of early binding is you remove any syntax errors from run time and casting/conversion errors are found whilst compiling.


Casting error

It was working fine, my queryexpression was returning some records but when I tried to cast the records from Entity to my early bound entity I was getting

System.InvalidCastException: Unable to cast object of type ‘Microsoft.Xrm.Sdk.Entity’ to type…

Now this is a common problem people have had with early bound types

Usually to resolve the problem you need to add one of the lines below to say, yes – enable ProxyTypes for my CRMService (IOrganizationService)

_serviceProxy.ServiceConfiguration.CurrentServiceEndpoint.Behaviors.Add(new ProxyTypesBehavior());

But looking at my code I could see I already had this


Duplicate Entities Reference

Then whilst building the project I was getting this error

Duplicate ‘Microsoft.Xrm.Sdk.Client.ProxyTypesAssemblyAttribute’ attribute

What the heck does this mean, more internet searching

This brought me to this page

and an answer from CRM MVP Gonzalo

Reference assemblies are not supported in CRM (at least officially) and they can always cause headaches, I strongly discourage them. What you can do is include the generated code from crmsvcutil.exe into each of your plugin assemblies and that should work. You can also include this line of code in your plugin assembly (which is included in the generated code):

It seems the problem was due to someone trying to reference Entities class from inside a dll and this doesn’t really work and a better solution is to add the entities class, so it’s included in the plugin dll (and you don’t need to go outside to another DLL to get the entities.class)

Visual Studio pointed me to this line with it’s error

[assembly: Microsoft.Xrm.Sdk.Client.ProxyTypesAssemblyAttribute()]

I then noticed I had two references to Entities (early binding file)

using Hosk.Dynamics.Crm..Entities;
using Microsoft.Xrm.Sdk.Query;
using Hosk.Dynamics.Crm..ContactLead.Entities;


Now things started to become clear, when I looked at the entities file before it didn’t have the entity I wanted so I regenerated the entities file using the CRM Developer toolkit.

The downside of using the CRM Developer toolkit to do this is it creates an entities file for all of them.  I did notice before there only seemed to be a small selection of the entities.

I then found there was a separate project with the crmsvcutil.exe, for those of you who don’t know what this is, it’s the command line tool Microsoft has created for creating the early bound Entities file.

I have used and written about this before


Only Create the Entities you need

The crmsvcutil.exe takes some config values which allows you to specify which entities you want to create early binding for.

You can pass some variables to the exe

<?xml version=”1.0″ encoding=”utf-8″ ?>

<add key=”o” value=”Entities.cs“/>
<add key=”url” value=”http://<CRM Server url/>CRMORGNAME/XRMServices/2011/Organization.svc“/>
<add key=”namespace” value=”Hosk.Entities”/>
<add key=”codewriterfilter” value=”BasicFilteringService,CrmSvcUtilExtensions”/>


Then a text file called EntitiesToBuild.txt and in this file were all the entities we wanted to build early bindings for.

This is great stuff, it’s efficient because it creates early bound data only need the early bound entities you use in the code.  Limiting the entities you create the early bound entities file will save you time creating/refreshing the entities file and reduce the size of plugin dll’s.

Missing References

I added in my entity, ran the crmsvcutil.exe but then suddenly I got loads of errors.  A previous developer had created the entities file but hadn’t updated the EntitiesToBuild so I was missing a bunch of entities which used early binding.

I added these entities in and then I got some error with fields missing.

One of the plugins was no longer being used and many of the fields it was using had been deleted.


Finally it compiled and I was up and running again, I had forgotten what I was actually doing.


Early Bound Generator

The solution for creating the early bound classes worked, there is now a tool which can do it for you, so you don’t have to spend any time using the crmsvcutil with the command line.

The tool is the Early Bound Generator and has a nice GUI interface for you, I have reviewed it on a previous blog/video

here is a link to the codeplex site


The tool has been  improved since my initial review.  I will also proudly add the Hosk CRM blog is the link which brings the most traffic to the codeplex site and mentioning it here may even send a bit more traffic towards over that way, not to mention I love CRM tools.

If you want to see the other CRM tools I have reviewed click the link below


Why should I care about this error

It’s true you probably won’t get the error in the same scenario as above but it’s useful to know about this casting error and the cause.

If you ever see errors about casting Microsoft.Xrm.Sdk.Entity type to a custom entity type then you know there is some problem with the entities file.

Often the problem is the entities file is not up to date/not the latest version as I discussed in the blog post below earlier this week

Error – the source file is different from when the module was built

So as soon as you see this error, you know it’s an early bound/Entities problem.

CRM 2011/2013 – use the debugger console to enabled/disable controls on a form

I was trying to fix a small bug but I was getting bogged down with the business logic (which I didn’t need/want to change) on the form.

The problem was there was lots of business logic which kept disabling the fields I wanted to change.

I tried briefly to understand the business logic but it was complex and detailed and I wasn’t really interested in understanding the form logic and/or briefly amending the JavaScript onload.  All I needed to do was to enable an optionset on the form, which would enable a ribbon button.

So it’s time for a bit of off the cuff hacking

I loaded the form

Press F12 to bring up the debugger window

You can use the console to manipulate the fields and enable/disable certain fields.

You have access to the CRM JavasScript objects

So I used the Xrm.Page, selected the control (not the field attribute) and did a setDisabled(false); which enables the control.
This didn’t enable the ribbon button because although the JavaScript function which is used by the ribbon button (e.g. the enable rule for the Ribbon button) the ribbon hadn’t been refreshed.

So I used the console to do a Ribbon Refresh


Fantastic, now my field was enabled and the ribbon button was enabled and ready to be pressed.


Other uses for F12 JavaScript debugger is to get the guid of the record, which I did on this blog post


Browser bookmark

An alternative to bringing up the F12 debugger is to create a bookmark, this will enable you to pass javascript into a form before loading it.

The blog post below created a God Button, which enables all fields—don-t-let-your-users-see-this


This blog post will talk you through the logic and is the first part in a series of blog posts on the subject


CRM 2013 – Understanding Business Rules

What are business rules

Business rules were added to CRM 2013 and a way to provide client side scripting/validating/field or section hiding without having to write any JavaScript.  For context server side customization’s are plugins/workflows (e.g. code written in C# is executed on the server)

Business rules are also known as portable business logic (although I don’t know anyone who calls them that) because they also work on the mobile app.

What can business rules do

  • Set field values
  • Show/hide fields – Visibility
  • Enable/disable fields
  • change the requirement levels on fields (e.g. business required, recommend)
  • Show error messages

All the features above were usually done using Javascript in CRM 2011.

I have written a quick guide to business rules here

Why are business rules useful

Business rules are useful because they allow non developers to provide the functionality mentioned above on forms.  Business rules can be used on Main and Quick Create Forms.


Are there any Business Rules Gotcha’s

You bet there are, here are the main ones

  • Fields updated using business rules do not trigger the fields on change event!
  • Business rules run only when the form loads and when field values change. They do not run when a record is saved.
  • Business rules only work with fields on the form (and the first 75 for tablets)
  • Business rules run only when the form loads and when field values change. They do not run when a record is saved.
  • Business rules are run in order of activation
  • Business rules only work client side, so won’t be triggered when data is changed server side (plugins, workflows, import)
  • Logic in business rules is appliedWhen there are multiple business rules, they are applied in the order they were activated, from oldest to newest.


There is also a big logical error which can be added using business rules and this is when you have either

Conflicting business rules

JavaScript and Business rules conflicting

Business rules will now mean there is an extra area to check when things are working in an usual many.  Entities could have Javascript, multiple business rules, Workflows and plugins all updating the same fields.  The possibilities are endless and so are the potential bugs.

As a general rule I would advise people not to mix JavaScript and business rules because it will make the solution more complex for developers to understand and maintain.  Developers will also need to understand JavaScript will run first and then business rules (if the condition is true)


How do business rules work

Business rules are created on an entity basis

Business Rules

Business rules come in two parts, the condition and the action.

The condition is the criteria for the business rule to test to see if it runs.  Currently business rules can have more than one condition and they work on an AND basis (e.g. all conditions have to be true).

If the condition is successful, then the action will execute.

Business Rules 1

You can view business rules a bit like real time workflows, but the actions can show/hide, enable/disable fields and show error messages etc.

Business rules also run only on the client side (e.g CRM FORM), which means they can only be triggered when adding/editing data on the CRM form.


Schoolboy error

Business rules usually have to be created in pairs and most people when they first use business rules they only create one.

You don’t need two but you usually do.  If you hide a field/section with a business rule then you need another business rule to show the field/section otherwise it’s always hidden

To read more about this, read the blog post below

CRM 2013 – Business Rules work in pairs because the condition is AND and not IF


Running Order

You could have a lot of things running on a form such as JavaScript and numerous business rules so you need to understand in what order things will run.  It’s possible you could have JavaScript and numerous business rules all running against one field, so the order things run can have a dramatic effect on the outcome.

According to this MSDN article on business rules

The logic included in your business rules is applied together with other logic in the form that could include system scripts, custom scripts, and other business rules. The order in which this logic is applied will affect the outcome. The order is as follows:

  1. Any system scripts are applied first.
  2. Any logic in custom form scripts is applied.
  3. Logic in business rules is applied.When there are multiple business rules, they are applied in the order they were activated, from oldest to newest.

This means that to control the order in which business rules are applied, you must deactivate and reactivate the ones you want to be applied last.


I guess there isn’t any real way of knowing what Systems scripts are running or what they are doing so I will ignore those.

Javascript will run first

Business rules are run in order of activation.  This sounds like a painful process of having to deactivate business rules and activate them in the order you want them to run (surely there must be an easier way), I can see some very tricky bugs to find


Business rule Scope

A bit like workflows, business rules have a scope but business rules are only concerned with forms.  The scope choices are

All Forms

Choose one of the main forms


If you choose all forms, the business rule will run on the main form and Quick Create form but you cannot individually choose a Quick Create form.

Interesting thing to understand

Business rules get converted in JavaScript by CRM and then applied to the form.  Business rules only work client side (not server side like workflows and plugins).  The downside to this is business rules only get triggered on the form and not if the data is updated by any other means (bulk update, plugins, etc)


CRM 2015 – Business Rules enhanced

Business rules are going to be upgraded in CRM 2015 and I have seen it nicely put as Business rules enhanced

 IF, THEN and ELSE Conditions

The biggest enhancement to business rules will be the adding of if statements.  At the moment conditions must all equal true, this means you have to create two business for most functionality (e.g. one business rule to show a field and another business rule to hide a field)

Here is a good article on the new IF, THEN

And/or support

Conditions in business rules CRM 2015 will all combinations of AND or OR, with the limitation of only using them in one/single condition, so it’s a bit better.

Set Default Value

A business rule to set default values for fields

Server side

Business rules will be able to work server side.   The reason this is important is because it means business rules won’t only work when the entity and fields are updated using the CRM form but also when bulk updates, imports or plugins changes those fields.


What hasn’t been fixed in CRM 2015

CRM 2015 business rules will be enhanced but they won’t be totally awesome yet, there will be a few errors which could still do with some improvement.

Complex conditions

Conditions have been improved but they are limited to one If/Else in a condition.

Hide/Show Sections and Tabs

I don’t think you can hide/show sections and tabs in the CRM 2015 enhanced business rules.

Cannot clear a field

You can set a default but you cannot null or clear a field using business rules

Related entity fields

One of the great things about work flows is you can update related entities specified in a lookup field, this would be great in business rules and save people do this using OData calls in Javascript.


Formula’s could be enhanced.  E.g. dynamic dates can only be created by adding on days (not hours)



Further reading for CRM 2013 Business rules


Visual Studio 2012 keeps crashing

Visual studio has kept crashing for 3 developers over the last few weeks.

What makes it worse is there doesn’t seem to be any consistency to the cause of the crashing, it sneaks up suddenly and POW, freezes and crashes before kindly offering to reopen for you.

What made it more confusing/annoying was no could reproduce the crashing constantly, some days you would have a few days without crashing and then one day it could crash 10 times and ruin your day.


We found a solution which seems to work

(backup first) – ALWAYS

then delete the ComponentModelCache folder, which you should find here



The solution doesn’t seem to shed much light on what was causing the crashing, particularly the fact it was happening to different developers on different computers.



Error – the source file is different from when the module was built

This error in the title was very frustrating because it was stopping me test my code.

I had a console app to test the plugin code.  I was building the plugin in a separate project and referencing the dell in my console app.

I would then step through the code but when it got to the point of stepping through the plugin code I was getting the error

the source file is different from when the module was built


I understood what is was saying, which is basically the DLL and PDB file were not the same in my console app as the latest file.

This forum has a few answers (they didn’t help)



So my understanding of the error was my console app wasn’t using the latest dll, pdb file but why.  If you are wondering what the pdb file is, it’s basically the dll file in a code which a debugger can use.

this explanation is a bit better

A pdb file contains information for the debugger to work with. There’s less information in a Release build than in a Debug build anyway, but if you want it to not be generated at all, go to your project’s Build properties, select the Release configuration, click on “Advanced…” and under “Debug Info” pick “None


So I looked in the build folder and then I noticed the dll hadn’t been updated since this morning.  I rebuilt the project but it the dll wasn’t updating.

A bit more poking about and I found the DLL was going to a completely different folder.   So I changed the reference in my console app and pow, it worked.

Why was I looking in the wrong folder

When any project but Plugin project gets build you specify a build output path.  You can check this by right clicking on a project and clicking properties

Usually this is


output path

but for some reason (I’m pretty sure this was me) the output path had changed to \…\…\…\…\…\BuildDLLs

So the reason why my console app had stopped picking up the correct DLL because the DLL had moved from the directory





I changed the output directory to bin\Debug and then it all started to work again.

How this had changed was quite beyond me