So one of my SnapShot! customers in Switzerland was unable to connect to an instance for one of their customers. Here is the error we were recieving:
Unable to login to Dynamics CRM, Error was : Metadata contains a reference that cannot be resolved: https://xxxxxxxx.api.crm4.dynamics.com/_common/error/errorhandler.aspx?user_lcid=1033&ErrorCode=
&RequestUri=%2fXRMServices%2f2011%2fDiscovery.svc%3fwsdl%26sdkversion%3d9&BackUri=&Parm0=%0d%0a%0d%0aError Details: The service ‘%2fXRMServices%2f2011%2fDiscovery.svc’ cannot be activated due to an exception during compilation.
The exception message is: Could not load file or assembly ‘Microsoft.Crm.Site.Services%2c Version%3d9.0.0.0%2c Culture%3dneutral%2c PublicKeyToken%3d31bf3856ad364e35′ or one of its dependencies. The system cannot find the file specified..’.
It turns out, that this was not at all what the problem was.
Technically, I was the problem.
I still use a connection string to connect to the Dynamics instances and in this one case, the customer had a Dynamics 365 password that contained a double-quote. I had never anticipated that would ever happen because that is not normally something that people use in their passwords. But for those of use that use a password-generator, it is indeed a valid password character.
And it has only taken me seven years to find this…..
Troubleshooting
At first I thought there may have been an issue connecting to a D365 instance on CRM4. I thought this strange because I have never had an issue before, but just be safe, I reached out to my friends to see who had an instance I would log into and my friend Joe Gill, created a trial on CRM4 that I could connect to.
So I did, and it worked. Now I was really confused.
I did a screen-share early this morning with the customer and indeed, we could not connect. I had him try a different customer’s instance, and it worked fine.
What is the world was so special about this instance?????
The Solution
After examining the connection string, character by character, it occurred to me that maybe the makeup of the password itself was doing something strange. I was using double-quotes to encase the password and this password happened to have a double-quote in it.
That was the problem, it would seem. When the connection string parser hit that “unpaired” double-quote, did something strange, like ignore the remainder of the connection string or something. This cause it to not have all of the information needed to property log into D365.
Just a single search later, I found an article by my friend Guido Preite, that offered a very simple solution.
I switched from using double-quotes to single-quotes and implemented Guido’s solution to replace any single-quotes found in the password with a double-single-quote.
This solved the issue completely and made for a more robust application.
Conculsion
I am honestly shocked that it took so long for this bug to surface, but the resolution was pretty simple, now that I know what the problem was.
And this is a perfect reminder that sometimes, the problem is not what you think it is – even though you have an error message.
