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.

Where is the Dynamics 365 SDK Download?

With the release of Dynamics 365 Customer Engagement 9.0 (July 2017 Update) the old downloadable SDK has been replaced by online documentation and NuGet packages. This means that we can pull the latest SDK assemblies directly from Nuget. Typically you would want the package Microsoft.CrmSdk.CoreAssemblies. You typically download the SDK assemblies directly from the NuGet Package Manager within Visual Studio and then the tools like PluginRegistration via Powershell.

SDK Old World vs. New World

Initially it may feel a little frustrating because instead of having the SDK help file, code samples, plugin registration tool and the rest in one ZIP file you will now have to familiarize yourself with the new online locations and of course will need an Online connection to browse for help. This is assuming you are working on v9+ either online or on premise. If working on an older implementation of course we still have the original SDK’s targeted at those specific versions.

D365 Help

D365 SDK Help

Dynamics 365 SDK Assemblies

Not going to list them all but essentially you will typically grab these from within Visual Studio directly through Nuget Package Manager. If you wish to automate updates and pull these as part of your build process you will need to develop your own powershell script to do it. The SDK assemblies are listed here with release notes.

SDK Tools

• CrmSvcUtil
• DataMigrationUtility
• PackageDeployer
• PluginRegistration
• SolutionPackager

You can grab them here. .

SDK Samples

There are plenty of examples in the main online help file but you can also download the SDK code samples via NuGet too.

Web API – Server Side

Download C# Samples for Web Api

Download C# Samples for using Organisation Service

Online Web API Samples Overview

Web API – Client Side

Javascript Help

Functional Training

Help Hub

Videos

Keeping Up-To-Date

As with any NuGet approach there is always the challenge of ensuring that developers are all using the same and latest versions. The update process is typically manual. The way around this is to automate via powershell to pull the latest packages as part of your DevOps Build pipeline.

Older Links

Old Tutorials and Video samples useful (though no longer supported)

Pre-365 SDK Downloads

Authentication failed because the remote party has closed the transport stream.Unable to Login to Dynamics CRM

Got this error today when connecting to Dynamics 365 using the XRM Tooling CrmServiceClient class. This solution to be fair was expecting to connect to a 2016 online instance so I knew it would need changes. I was trying to connect in debug mode using Visual Studio 2015 on an old Virtual Machine.

I added a watch to the Connection object and viewed the LastCRMErrorProperty and exception detail showed:

“Unable to connect to CRM: The underlying connection was closed: An unexpected error occurred on a send.\r\nMetadata contains a reference that cannot be resolved: ‘https://Organisation.crm11.dynamics.com/XRMServices/2011/Organization.svc?wsdl&sdkversion=9′. => The underlying connection was closed: An unexpected error occurred on a send. => Authentication failed because the remote party has closed the transport stream.Unable to Login to Dynamics CRM\r\nUnable to Login to Dynamics CRMOrganizationWebProxyClient is null\r\nOrganizationWebProxyClient is nullOrganizationWebProxyClient is null\r\nOrganizationWebProxyClient is null”

I already knew that the .NET framework had to be changed to 4.6.2 as we are targeting Dynamics 365 from the client application (which would also meet the TLS 1.2 requirement). You can read more about that is very important here and this other link was useful too.

I downloaded the latest nuget package for Dynamics 365 assemblies too as the code was last running 2016 versions. None of these logical considerations were directly relevant to my problem.

None of these things fixed the problem

As noted in the Microsoft link above this issue can occur if using Visual Studio 2015 and trying to connect to D365 in debug mode which was exactly what I was doing here and an extract is below from the Microsoft support page:

Microsoft Dynamics 365 Customer Engagement (online) to require TLS 1.2 for connectivity

Known Issue with Visual Studio 2015

When you are running your project/solution in VS 2015 in debug mode, there is a known issue where you may not be able to connect to Dynamics 365 (online) version 9.x or Dynamics 365 (online) version 8.2 Government. This happens regardless of whether you are using a Target Framework of 4.6.2 or higher. This can occur because the Visual Studio hosting process is compiled against .NET 4.5 which means by default it does not support TLS 1.2. You can disable the Visual Studio hosting process as a work around. Right-click on the name of your project in Visual Studio and then click Properties. On the Debug tab you can uncheck the Enable the Visual Studio hosting process option. 

Please Note: This only impacts the debug experience in VS 2015. This does not impact the binaries or executable that are built. The same issue does not occur in Visual Studio 2017.

Uncheck Enable the Visual Studio hosting process option. 

This was the recommended option and sure thing it fixed the error but only to introduce an entirely new problem! Whenever I did a rebuild of the code and ran the debugger it would ignore the breakpoints and run the application from start to finish on the first execution. Then quite bizarrely it would automatically open up a new debugging session. So long as I didn’t rebuild the code the breakpoints would work every time otherwise the application would execute without halting on the breakpoints.

To validate this was the cause of the problem. I started a completely new project and ensured the above behavior was repeatable. I tried with the option checked and unchecked. This proved that the issue was related to that option being turned off within Visual Studio 2015.

Final Solution

Ultimately I updated the Virtual Machine version of VS to the latest 2019 to avoid the entire problem and that’s what I recommend you do too. However as a temporary workaround and to demonstrate the point also managed to get this working by re-ticking the “Enable The Visual Studio Hosting Process” option and then adding the following code right before making the connection:

#if DEBUG
Console.WriteLine("We are in DEBUG mode so having to set security protocol to get around debugging issue with VS2015 as dont want to turn off Enable Visual Studio Hosting Process option");
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
#endif

This I believe provides best of both worlds as it means that we don’t need to worry about Microsoft recommendation:

This forces the TLS 1.2 security protocol at all times. This is not recommended as you run the risk of having to update this when there is a newer security protocol adopted by the industry.”

As this code only forces TLS 1.2 only when running in DEBUG mode this is unlikely to cause any issue if it was production level code. I have provided feeedback to Microsoft hopefully they will update there support page to reflect this issue and a resolution that actually works.