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.
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.
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.
This error message is not specific to just Dynamics 365 when trying to view entity records within Internet Explorer put any server application depending on how it publishes the ATOM feed XML information and the browser settings when it comes to display.
Organisation Data Service
For the purposes of this article showing this based on a Dynamics 365 organisation but to be clear this service has been deprecated and the service should not be used. Use the Web API for all such calls.
To fix this uncheck the “Turn on feed reading view” option
Then VOILA
Now that you have made this change you will also get more verbose information too when querying the EntitySet directly example ContactSet sometimes this can be useful when looking for a quick reference to other other lookup GUID’s etc.
Google Chrome
This behaves in the same way automatically so there is nothing more to say here.
How about Web API?
So if using the Web API, Chrome will automatically give you the JSON output in the browser and is much more readable as seen below.
Whilst the Organisation Data Service supports both ATOM and JSON, Internet Explorer by design does not output JSON in the browser window and instead will prompt you to download the response.
This is standard behaviour and the basic recommendation is to associate .JSON files on your system with Notepad/Notepad++ and then open when prompted from within IE. There are other ways around it but none of them ideal such as:
Change the response mime-type header to text/plain (not ideal at all)
Change your registry settings (not ideal at all) as means all server responses treated in this way
The only really viable options are:
Associate JSON extension with notepad
Use Fiddler and the JSONViewer plugin to see the JSON format
Dont use IE and use Chrome/Firefox instead!
After reading all of that! The best option is to use CHROME! lol. Funnily enough it reminds me of a similar article I wrote here.
Give me strength.
JSON Formatters
If you working with raw JSON format it is often useful to easily be able to convert this to a more readable view so this:
{“@odata.context”:”https://internetschoolofbusinessdev.crm11.dynamics.com/api/data/v9.1/$metadata#accounts(name)”,”value”:[{“@odata.etag”:”W/\”1247998\””,”name”:”Fourth Coffee (sample)”,”accountid”:”98f219f0-6bd4-e911-a815-000d3a0b81d4″},{“@odata.etag”:”W/\”1247999\””,”name”:”Litware, Inc. (sample)”,”accountid”:”9af219f0-6bd4-e911-a815-000d3a0b81d4″},{“@odata.etag”:”W/\”1248001\””,”name”:”Adventure Works (sample)”,”accountid”:”9cf219f0-6bd4-e911-a815-000d3a0b81d4″},{“@odata.etag”:”W/\”1248002\””,”name”:”Fabrikam, Inc. (sample)”,”accountid”:”9ef219f0-6bd4-e911-a815-000d3a0b81d4″},{“@odata.etag”:”W/\”1248003\””,”name”:”Blue Yonder Airlines (sample)”,”accountid”:”a0f219f0-6bd4-e911-a815-000d3a0b81d4″},{“@odata.etag”:”W/\”1248004\””,”name”:”City Power & Light (sample)”,”accountid”:”a2f219f0-6bd4-e911-a815-000d3a0b81d4″},{“@odata.etag”:”W/\”1248005\””,”name”:”Contoso Pharmaceuticals (sample)”,”accountid”:”a4f219f0-6bd4-e911-a815-000d3a0b81d4″},{“@odata.etag”:”W/\”1248006\””,”name”:”Alpine Ski House (sample)”,”accountid”:”a6f219f0-6bd4-e911-a815-000d3a0b81d4″},{“@odata.etag”:”W/\”1248007\””,”name”:”A. Datum Corporation (sample)”,”accountid”:”a8f219f0-6bd4-e911-a815-000d3a0b81d4″},{“@odata.etag”:”W/\”1248008\””,”name”:”Coho Winery (sample)”,”accountid”:”aaf219f0-6bd4-e911-a815-000d3a0b81d4″}]}
Now just unzip and copy the JSMinNPP.dll file into your notepad++ Plugin folder and start the application. Its now accessible from menu.
JSONTool Plugin for Notepad++
JSON Viewer
If working within Visual Studio you can install the Extension which will allow you to paste in Raw JSON and reformat plus compare JSON. It’s useful if you doing work in VS. Once installed it is accessible from the Tool menu.
Fiddler JSON Viewer
If all you are doing is wanting to see JSON responses in a friendly format then using Fiddler just for that purpose may be a little overkill! It all depends on what you are debugging or working on at the time. Issue yuor get request in browser, double-click the session and then click on the JSON menu header
Recently a user reported that a workflow had failed to execute. Upon review there was a load of missing steps with the error icon next to them. The exact error was “Invalid condition expression” and appeared against all steps that referenced a Custom workflow activity step.
At first this was confusing because there had been no recent deployments to the test organisation. It is suspected that the root cause of this error was due to a failure several days ago to Import the “assembly” solution which hanged on the platform probably due to fact that the solution DLL’s are over 18MB in size. We did an IIS reset before trying to re-import the assembly solution and then the solution import worked fine through the application.
The current theory is that previous solution import caused the workflows to become out of sync with the referenced CWA DLL steps. Following another IIS reset days later the workflow designer window showed all custom steps and the workflows executed as expected.
I suspect information is missing here for what actually caused the issue but at least it was easily resolved in this scenario though accept a full IIS reset seems a little extreme here? Perhaps there was a better way of handling it.
If anyone has a more comprehensive explanation feel free to share and will update this post accordingly! Thanks.
Antony Ellis Dynamics 365 CRM 