While testing importing of several small managed solutions I was able to create what is known as a circular reference in software engineering. Take it from me this is bad! When referencing assemblies in Visual Studio it prevents you from creating the circular references, however in MSCRM 2011 it doesn’t seem to prevent and if it does I managed to create a situation where it allows you to create the circular reference. So for MSCRM 2011 I am going to dub this as a circular dependency. Once the circular dependency was created I couldn’t delete or update either solution because they were dependant on each other!
Sometimes you may find yourself in a situation where a CRM system user record is no longer pointing to your Active Directory user. This broken link basically prevents the user from accessing CRM! Not good! In my experience this occurs due to the infrastructure IT bods not being fully aware of CRM and how it is tied to AD. So while managing AD they may delete users to keep things nice and tidy. While doing this, for example, they may accidentally delete the wrong AD account, recreate it and think everything will be OK, or they may delete someone who has left the business and a few months later the person is recruited back in to the business. I’m sure you can think of other reasons why the link between CRM and AD users might become broken but the effect is always the same… The user can’t access CRM anymore! So lets fix this with an example.
This statement holds true whether you are updating attributes through the SDK dlls or over web services. It doesn’t matter whether you’re coding for a plugin, workflow assembly, Silverlight app or some external custom application like a windows application or web application. The potential outcome in all the scenarios will be the same! What’s the outcome? Triggering other automation unwantedly!
I have had a excellent week working on my toolkit. I feel like I’m really starting to make progress on my main application. This week I have been working hard on the foundations again but things are really starting to take shape. Features are becoming easier to reuse and the development is starting to speed up because of it. The best part about the development is that because its following the MVVM design pattern theres a nice separation between UI and Logic. For the developers reading I have no code behind in my views, and my views contain little XAML! Happy Days! For you none developers that means when the new version of MSCRM comes out it will be easier for me to adapt the toolkit to interface with it!
Since I have been a CRM developer I have used a whole host of tools to aid me in customising CRM. A lot of these tools you guys will more than likely have used yourselves! Now I’m never going to complain about free tools that other developers have kindly poured a lot of time and effort in to developing. But, when using them I can always see improvements and want to implement those changes. Now some of these tools come with source code, so you could say why not just extend what’s there. Well the truth is I don’t really like working with other people’s code. I’m not saying their code is bad but I like my style and want to stick with it for the time being! So inspired by all of these wonderful tools I have started to develop the CRM Codex Toolkit as a hobby. Well that’s what I am calling it at the moment
This caused me some headaches today, so to save you the cost of a box of paracetamols i thought I’d shout it out! If you ever find yourself writing code to perform your own mail merges based on CRM mail merge tags watch out for how CRM shortens mail merge tags when involving related entities. What do I mean by this? Well let’s say we create a mail merge that is based on case. In this merge we include the primary contacts name and address. In doing this we basically add a related field in to our mail merge.