GIT Introduction

Starting from the top and in the context of this article SCM is the acronym for Source Code Management. The purpose of this article is to give a high-level introduction into the area of SCM and in particular how this can be setup for working on Dynamics 365 implementations.

If you are interested more in Git specifically there probably is no better resource than the free eBook written by Scott Chacon and Ben Straub available on the main Git website. The rest of this post is more of a high-level comparison between Git and DevOps in the Dynamic 365 world.

The tools we can use vary from open source like GIT to commercial products like TFS and even the once very popular visual source safe product. These tools are effectively version control systems for code repositories so that we can track and make changes to files.

Perhaps the two most common version control products we see today for software development are GIT and Team Foundation Version Control (TFVC) aka. TFS. The latter now being referred to as DevOps for the rest of this article. These two are not in direct competition, in fact Microsoft state that GIT should be used for version control not TFVC unless you need the centralised features included within TFVC. GIT is the default repository type in DevOps.

Microsoft has embraced GIT to the point where in 2013 it was introduced within DevOps as a repository type and within Visual Studio 2013 where it was integrated within the IDE. This means we can do our extensions/coding as normal within Visual Studio and use this when we wish to check in code to a GIT repository rather than using perhaps other tool options:

• TortoiseGit
• GIT Bash
• GIT GUI
• GIT Command Line

Ultimately, that decision typically comes down to the developer preferred tool, as they all will achieve the same end result which is to clone a repo locally from the server, view history, revert code changes, make branches, commit changes, pull requests and everything in between. Though remember with GIT, every developer is in fact its own GIT server instance because it a decentralised approach which means if the master code was ever lost on the server, both the code and change history can be recovered from the developer clone.

The most basic difference between the two is that TFVC is centralised and GIT is distributed. The advantage of distributed is that developers only need access to the centralised repository to sync changes. All other operations like branching, commits, merging can be done locally on the developer machine with no internet connection.

The purists out there will no doubt say that the Command Line and GIT Bash (Unix type shell) are the best option over using GUI tools. The general consensus when learning GIT is to at least start out with the command-line then move to GUI tools later if you wish as that gives a deeper understanding of the process. Ultimately there are some operations that can only be done by command line/Bash especially if you get conflicts or other errors. I’ll leave this decision with you.

DevOps and Git Perfect Combination

By combining DevOps with GIT we get the very best of both worlds:

• Excellent Version Control System
• CI/Build Automation
• Project Management Tool/Sprint Planning
• Ability to link code changes to a specific story

Whilst we could use DevOps as the code repository and version control system, it is now mostly discouraged as the version control offered by GIT is far better. Of course, unlike previous versions of Visual Studio where you could only use the version control IDE with TFS this has now been opened up which means that Visual Studio can work with other GIT servers such as hosted GitHub or your own dedicated Git Server. DevOps doesn’t even have to be used if you don’t need or want to use it.

CRM Dynamics Setup

Whether on-premise or online all we have to do is setup GIT as the version control repository type within DevOps and then browse to this URL from within Visual Studio as normal. The typical DevOps scenario:

• Setup a GIT Repository for version control within TFS

For the .NET code and unpacked CRM solution XML files

• Use DevOps for the sprints, user stories and for the continuous integration (Build definitions) along with being the main interface for browsing code, adding branches to sprint stories etc

Link: Managing multiple CRM solution development pipelines in parallel (change control, merging) and ALM.

If looking for setting up Visual Studio with GitHub or Visual Studio online this is a good article. This article was also a good reference on GIT.

Much more to come on this subject and more detailed articles to be written on change control within the Dynamics 365 space.

Chrome Debugger Error

Like the Dinosaur if we don’t continually learn and adapt we run the risk of becoming extinct. For most of my career I have always used the IE debugger for JavaScript despite knowing that Chrome DevTools was far better with richer features and generally quicker to use.

Why?

Guess I had a reluctance to move away from that which is familiar to me as JavaScript development has never been my favorite language though times are starting to change! I have made the move now to Chrome not only because the debugger is much nicer but for CRM there a number of great Chrome extensions to help increase my productivity and I never liked having to switch across different browsers just to develop in CRM. Every browser has its own nuances especially when working with Dynamics 365 so the less browsers I have to use the better!!.

Chrome Debugger Broken

Unfortunately, I was caught out by an issue recently which frustrated my adoption of it. I’m unsure of the cause is down to CRM, Chrome or a combination but when trying to debug some code Chrome would not highlight the line both when it went to the break point and afterwards when trying to step through the code. It only happened when I included this line within a HTML web resource.

<script src="ClientGlobalContext.js.aspx" type="text/javascript"></script>

Yet the IE debugger worked fine and as expected (makes a change!).

Here is what it looked like!

Not working the code line is not highlighted

Then we remove the JS include and everything is fine:

Current line is highlighted in Chrome debugger

Ar first I thought a workaround was to place the code in a separate JS file. That works fine for when calling functions in that library but if the web resource has JS code within it too that you need to step-through you are out of luck my friend. At time of writing I don’t have an older VM available to test but I am sure this issue only occurs in the following scenario:

D365 Online v9.1.0.9228 + Chrome (v77.0.3865.90) + HMTL Web Resource and trying to include the Global Context library.

Otherwise how would anyone be able to debug there web resource code using Chrome if the JavaScript is inline with the HTML? Then the light bulb moment finally arrived… it would be highly unlikely in a real world scenario that it would be done this way in first place! If you look at the SDK samples (E.g. JavaScriptRESTDataOperations) the HTML web resource has no inline script it is all done via other libraries namely

• SDK.REST.js
• JavaScriptRESTDataOperationsSample.js

Plus, now that I come to think about it I have always avoided inline JS code where possible and favored reusable / encapsulated code within appropriate libraries.

What’s the lesson

I have spent a serious amount of time trying to understand a problem, that is highly unlikely to ever actually be a damn problem in the first place. Well done me! Take a bow Antony Grrr.

CRM 2016 -Problems after renaming the CRM Server

Big, big, major caveat here this article talks about stuff that is unsupported by Microsoft regarding the Dynamics platform just so we are clear from outset. Recently I stumbled across an old article from The Hosk concerning how changing the server name in 2011 broke the deployment.

It got me thinking whether the same would be true for CRM Dynamics 2016 so I had a play with one of my local virtual machines and committed the Sin of changing the server name. Actually, committed many sins one of them was not taking a backup of my VM first and thereby rendering it useless at this point in time.

Anyways, as I should have expected this completely buggered up the Dynamics CRM application. Now before I get into what I did to fix it, it’s worth pointing out that the safest approach is to uninstall Dynamics CRM and then re-install after you have changed the server name. In addition would not recommend the approach I took either especially on a commercial server. So following the server name change the following were broken:

• CRM Deployment manager
• CRM application
• SQL Server (Configuration)
• MSCRM_CONFIG database
• SSRS
• Registry Settings!

Ouch.

Concerning Active directory

• PrivUserGroup
• SQLAccessGroup
• ReportingGroup
• PrivReportingGroup

 

In my case didn’t need to change anything here or mess about with domain GUID’s/entries because the organisation was still on the same domain and active directory therefore had the same GUID’s as before and new that the server was the same server so it just updated the member list automatically using the new server name. This may not be the same behaviour for older versions of Active Directory.

Fixing Deployment Manager (Connection Error)

This was completely buggered to point where it could not connect to CRM. The deployment manager is mostly dependent upon the registry for its settings at least when it comes to making the connection and of course MSCRM_CONFIG database. When trying to run the deployment manager it came back with an error stating the MSCRM_CONFIG database was not available and/or removed.

1. Rename the server and don’t tick restart at this point
2. Close all browser windows/crm tools
3. Go to registry and update
   1. HKEY_LOCAL_MACHINE/SOFTWARE/MICROSOFT/MSCRM
   2. Change the old server name to new server name in keys (configDB key, serverURL)

Update the MS_CONFIG DB tables and change any reference to old server name with the new server name you will need to check each of the fields to be safe in these tables:

• Server
• Organization
• SystemUserOrganizations

At this point if you were to restart the server you would find the CRM application will be working again however other things will still be broken for example the end point URL’s displayed in the organisation still have old server names and the deployment manager is broken when you try to create a new organisation.

Fixed Yet?

Nope. To finish off we need to update SQL Server, Deployment manager settings and the Reporting Services configuration manager.

Fixing SQL Server

This was needed for both the create New Organisation and the CRM Diagnostic check (Run within the new organisation and repair, remove CRM setup application) to work, otherwise you will get errors saying that the Instance name must not be the same.

Firstly … check what the server name is at the moment concerning SQL Server

SELECT @@Servername

This returned old Server Name In SQL Server

Even though we have updated the CRM settings, the SQL Server instance still has references to the old server name. In order to resolve this we need to go into SQL Server and run the following T-SQL:

use master

go

SELECT @@Servername

exec Sp_dropserver ‘Value returned by @@ServerName’

exec Sp_addserver ‘The current server name’,local

Restart the SQL Server instance after executing the above T-SQL.

Fixing the SSRS Configuration

If the SQL Server Name is still showing the old server name you need to click on Change Database and redeploy the reporting database either to a new database or overwrite the existing one.

Fixing Deployment Manager (New Organisation and Web Service End Points)

To fix the browse link going to wrong (old server) and to ensure end-points displayed in CRM organisation application is correct you need to the update the following which you get to by right-clicking on the top node in deployment manager (Microsoft Dynamics CRM Server) then editing the properties:

After which the Deployment Manager new organisation functionality should work. It is worth noting the above was also needed to fix the CRM diagnostic checks which are done by both deployment manager or when you try to change the CRM installation via add/remove programs.

Finally: Restart the Server.

Did it work?

For me it appears to be working ok.

Should you do it?

Nah absolutely not! It is best to do a clean re-install. The moment I encounter a strange issue within this dev environment you can bet money on it that I will do a clean install of CRM 2016 because it will always be in the back of my mind “could this be related to that time I changed the server name!” however for academic purposes thought would share the experience.

How to setup a Dynamics CRM Development Environment

Start Your Engines

By the end of this article you will have a working development environment with all the core tools required to extended the functionality of Dynamics CRM.

Before we get started it is important to highlight some of the fundamental approaches to CRM Development. Microsoft Dynamics CRM is full of features and capabilities that should be utilized in the first instance, simply put, we don’t go and try to re-invent the wheel when we can leverage stuff already out of the box (OOB). There are a  host of reasons for why we take that approach and something to talk about in a separate article.

An example: Once I was working for a client and they had customised the application ribbon (command bar) to provide “Quick Call” functionality. This involved not only modifying the ribbon XML but also creation of custom Icons, along with JavaScript events and code so that a Phone Activity could be created (how many hours/maybe days wasted??). Wow. The developers at the time clearly were not familiar with Dynamics CRM Quick Create feature it was there all along within the system.

This is not uncommon, the truth is there are so many features within Dynamics CRM and typically (at least) two significant updates every year to the product that it is easy, even for experienced CRM developers to accidentally create some level of customisation that already exists within the platform. Not only does Dynamics CRM have one of the steepest learning curves but is constantly being improved, therefore keeping yourself up to date with each release should be high on your priority list.

Ok, generally when we talk about customising Microsoft Dynamics CRM it falls within two main categories:

• Customisation and Configuration (aka. Out of the box)
• Extending CRM (Development of Plugins, Custom Activity Workflows, Client and server side API’s, System Integrations)

This article is concerned with the latter and for that you will need to not only build a development environment but also download and configure a number of different tools.

 

Anatomy of a CRM Development Machine

So what would a typical development machine contain?

• Windows 10 Pro
• Visual Studio 2015 (or earlier)
• CRM Developer Toolkit (How to get CRM Developer Toolkit working with Visual Studio 2013 this also covers 2012 and 2015 versions of  Visual studio)
• XRM Toolbox
• .NET Frameworks
• Internet Explorer 11
• Google Chrome (often quicker and easier than IE! – what the hell?)
• Notepad ++
• 7-Zip

Depending on requirements you may even take it a step further and have CRM Dynamics 2016 running locally on your machine (On Premise) along with SQL Server 2014. That may seem like a crazy idea for a “thin client” but thanks to Virtualization technology we are able to do this and actually most of my development environments are virtualised running on a laptop without any kind of performance issue. In a commercial environment where we have multiple developers, the dev tools are on a shared virtual machine server. I will write a separate article on how to setup Virtualised development environments along with the pro’s and con’s of such an approach at some point.

Getting Things Setup

If only it was simple, it really isn’t, especially when you are new to extending CRM, get ready for lots of frustrated hours.However this guide should if followed precisely help to reduce your cortisol levels. The order in which you install software is important to avoid compatibility issues so below is how you should set things up:

• Install Microsoft Visual Studio (if running multiple start with the older ones first)
• Enable Windows Identity Foundation (WIF)
• Download .NET 4.5.2 developer pack (needed for CRM 2016)
• Download Microsoft Dynamics CRM 2016 SDK
• CRM Developer Toolkit
• XRM Toolbox

Install Visual Studio

The nice people at Microsoft allow us to use Visual Studio 2015 Community edition for free so long as it’s for learning and non commercial purposes which is great grab yours (Download Visual Studio Community Free Version) or if using this at work grab yourself the Professional edition from your corporate MSDN subscription. The installation is really straightforward you can pretty much use all the default settings so there isn’t much more to say on this area.

Enable Windows Identity Foundation

This is usually located within Programs and Features (Depends what Operating System you are running) and is needed primarily for the CRM Developer Toolkit to play nicely along with XRMToolbox plus other 3rd party tools.

If WIF not listed here you will probably need to use Powershell to install the feature (Add-WindowsFeature windows-identity-foundation), or if running a really old operating system will need to download the installation from Microsoft.

Get .NET Developer Pack

So I like easy, the easiest way to grab it is to fire off Visual Studio, go to new->Projects then select the option as shown here:

This will open up your browser and the one you need to download is shown here:

 

Microsoft Dynamics CRM 2016 SDK

It could be that you are targeting and older version of Microsoft Dynamics CRM perhaps 2015, 2013, 2011 or God forbid 4.0!  That’s ok, it’s important in my view to always be forward looking so being setup for the current version is always a good thing. The .NET libraries are cumulative so if you find that you need to use an older version of the framework simply Target the appropriate version that CRM was built upon from within the project Target Framework pick-list (or combo control if being technical). Grab the latest CRM 2016 SDK or if targeting an older version of CRM get the latest SDK for that version.

CRM Developer Toolkit

You might be thinking why? Well let me explain. If you have not used this before you are really missing out this includes those developers who have be extending CRM since God was a lad.

The CRM developer toolkit enables you to:

• Browse the CRM Solution/Entities without having to leave Visual Studio
• Deploy Plugins,  Custom Workflow Activities, Web Resources (Custom Images, HTML Pages, Javascript) from a single click to your target CRM solution
• Maintain all CRM code in one central place for development work
• Maintain references to all Assemblies (custom and 3rd party)
• Provide Early Binding across all your project types from one visual studio solution
• Enhances rapid development and productivity in developer teams (IMHO)

Then providing you are checking in code to a shared repository (TFS, Subversion etc), it makes work much easier when you have multiple developers all working on a CRM implementation. This unfortunately is a bugger to install with any version of Visual Studio after the 2012 edition .. but lucky for you I have wrote a guide on How to install the CRM developer toolkit with Visual Studio 2015.

XRM Toolbox and Other CRM Tools

As I mentioned at the start of the article the story does not end with Visual Studio. There are a number of tools you will need to have in your utility belt including:

• XRM Toolbox (Tools the most commonly used purpose is for Sitemap/Iconator/MetaData)
• SvcUtilFilter (A free visual studio solution that creates early binding classes automatically)
• Ribbon Workbench (CRM solution file that makes it easier to customise the application ribbon simply install within your dev CRM enviornment)

XrmToolBox is an application that can connect to Microsoft Dynamics CRM 2011, 2013, 2015 and 2016 (Online, OnPremise of IFD). It is shipped with more than 20 plugins to handle several administration, customisation or configuration tasks. One of the great points about XrmToolBox is its capability to welcome external plugins written by other developers, just by implementing specific part of XrmToolBox code. https://github.com/MscrmTools/XrmToolBox

Requires: .NET 4.5.2 and WIF

http://www.xrmtoolbox.com/download.html

Grab yourself the 2016 version

Download

Credits

Featured Image: shehan365 via photopin.com, creative license.