This article covers the most common causes of "Unable to reach the server for license validation" errors when running an application built on Eyeshot.
The Eyeshot licensing model is subscription-based and requires the Eyeshot control to periodically contact our licensing server at https://id.devdept.com/. When that contact fails, the control falls back to an offline grace period; once the grace period expires, the control reports the license as invalid, and the application can no longer initialize the viewport.
For a general overview of how the subscription model works (license assignment, trial period, behaviour at expiration), see the Licensing Definitions article.
If you are hitting this error, one of the three causes below is almost always responsible. They are listed in order of frequency.
1. Proxy or firewall blocking the licensing server
This is by far the most common cause on corporate networks. The browser on the same machine can usually reach https://id.devdept.com/ without problems, because the browser is configured to use the corporate proxy with the user's credentials. The Eyeshot control runs inside your application's process and does not have those credentials, so the licensing request is silently dropped or rejected by the proxy.
What to check. Ask your IT department to confirm that outbound HTTPS traffic from your application's process to https://id.devdept.com/ is allowed. Verify both that the domain is reachable and that no TLS-inspection appliance is rewriting the certificate chain.
Fix. Add https://id.devdept.com/ to the proxy whitelist (or bypass list, depending on how your proxy is configured) so that the licensing traffic is not intercepted. Once the domain is whitelisted, restart the application, and the license should be validated within a few seconds.
2. TLS 1.2 not enabled in the application process
Communication with our licensing server requires TLS 1.2. Applications targeting .NET Framework 4.8 (and earlier) sometimes start with a ServicePointManager.SecurityProtocol value that does not include TLS 1.2, which causes the TLS handshake to fail with an error like "Authentication failed because the remote party has closed the transport stream".
There are two ways to make sure TLS 1.2 is used.
Preferred fix: make sure your project file does not contain <GenerateTargetFrameworkAttribute>false</GenerateTargetFrameworkAttribute>. If it does, remove it or set it to true. This attribute controls runtime initialization of the target framework context, including the default security protocol.
Alternative fix (when the project file cannot be changed): force the protocol explicitly at the start of your application, before any Eyeshot control is created:
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12 | SecurityProtocolType.Tls13;
This is particularly relevant for C++/CLI projects, where GenerateTargetFrameworkAttribute is not exposed in the Visual Studio project settings UI.
3. System clock not synchronized
The licensing system uses the local system clock to validate the offline grace period and to check the freshness of cached credentials. When the clock is significantly out of sync with the actual time, the validation runs more checks than usual and can fail intermittently, typically a few times out of every 10 application starts.
What to check. Open Date & Time settings on the affected machine and verify that "Set time automatically" is on and that the time is actually correct. On domain-joined machines, the clock is normally synchronized through the domain controller; if it is drifting, your IT department needs to check the time service.
Fix. Resync the system clock against a reliable NTP source. After the clock is correct, restart the application; no further action is needed on the Eyeshot side.
When none of the above applies
If you have ruled out all three causes and the error persists, open a ticket on our support portal with:
- the .NET target of the application (Framework or .NET 6/8, x86/x64/AnyCPU),
- a short description of what changed before the error started (new machine, new VPN, new antivirus, OS update),
- and the output of
https://id.devdept.com/opened in a browser from the same machine.
We will follow up with the appropriate diagnostic steps for your case.
Comments
Please sign in to leave a comment.