Our team has been having issues with DataObjects.NET licenses. The problems started about a week ago, and each day one more developer would encounter the problem. We use two different versions of DataObjects.NET in two different product / version branches, one uses 4.4.2 and the other uses 4.5.3. When attempting to build solutions using the 4.4.2, we get a licensing error. I assume this is due to the hardware IDs for our machines changing due to our recent (in-place) upgrades to Windows 8 (the message we got was something along the lines of "Hardware Key Invalid").

We've managed to work around the issue by deleting our Program Data\DataObjects.Net files and reactivating our licenses, but in doing so we've encountered another annoyance / error: if the license manager from 4.5.3 manages to automatically register and take out a hardware lock, it does so against v4.5, and the solutions that use 4.4.2 will refuse to build. Once a hardware lock is registered we are not allowed to delete them or modify the version they are for through the admin interface, so such users are stuck not being able to build against 4.4.2. However, if we manually create the hardware lock against the older version, download the key and install it manually, we have no problems and can build against 4.4.2 and 4.5.

Is there a reason we're not allowed to delete or modify hardware locks through the admin interface? Do you think it's safe to automatically register a non-backward-compatible lock when using a new version for the first time?

(As an aside, we only had one developer unlucky enough to get locked out due to a 4.5-locked registration, and your support team has already fixed that for us).

asked Oct 25 '12 at 00:26

Matthew%20Burnell's gravatar image

Matthew Burnell

2 Answers:

Hello Matthew,

let me clarify current situation with license activation.

DO 4.4 takes MAC address of network adapters into account when calculating hardware id. This breaks DO when you switch on VPN networks for example, because adding virtual network adapter is considered changing hardware.

To resolve this MAC addresses are not longer used since DO 4.5.

Some users (like your team) might need to use 4.4 and 4.5+ side-by-side. To make this possible license manager from newer versions of DO stores hardware locks separately. Also it uses separate API of a license server.

You can inspect all installed licenses in %ALLUSERSPROFILE%\DataObjects.Net. Typically it's C:\ProgramData\DataObjects.Net:

DataObjects.Net.license is a main license for DO (both versions).
XXXX.hwl is a hardware lock for DO 4.4
XXXX.hwl3 is a hardware lock for DO 4.5+

So it's generally safe to have hardware locks for both versions. Order of activation is irrelevant because they are stored independently. However you need to activate twice using different license managers. Second time you should activate only hardware lock because license is already installed.

answered Oct 25 '12 at 02:33

Denis%20Krjuchkov's gravatar image

Denis Krjuchkov

edited Oct 25 '12 at 02:34

Hi Denis,

Thanks for the information regarding how the hardware IDs are generated. To the best of my knowledge the team has not been adding and removing NICs (virtual or otherwise), nor connecting to / disconnecting from VPNs, so I'm not sure what caused the licenses to start to fail in the first place.

Regarding the separate license files and automatically activating them, we tried for hours to get the license managers to do the registrations themselves, and in only one case did it work. Attempting to activate over the internet led to the "invalid hardware license" errors. If I look at my own Program Data, I have only a .hwl file (no .hwl3), and I'm able to compile against both 4.4 and 4.5. Is this likely to change? i.e. will my 4.5 version run into licensing issues in the near future because I'm missing the .hwl3 file?

answered Oct 25 '12 at 03:10

Matthew%20Burnell's gravatar image

Matthew Burnell

"invalid hardware license" might happen if you have firewall that filters access to license server. In this case it's better to use license management site.

Since DO 4.5 hardware locks are not required if you have Ultimate edition thus there is no .hwl3 file in such case.

(Oct 25 '12 at 05:40) Denis Krjuchkov Denis%20Krjuchkov's gravatar image

Assuming that is what happened in our case, some confusion could have been avoided if the message was something along the lines of "could not contact license server". Thanks for taking the time to explain how the mechanism works. We'll stick to manually activating our licenses for now (we never had a problem with automatic activation in the past, but the network is not under my control and I have no idea if firewall rules have changed).

(Oct 25 '12 at 19:06) Matthew Burnell Matthew%20Burnell's gravatar image

I should note that we can still get into trouble by accidentally registering a hardware lock against the wrong version of DO (because we cannot delete it or change it to the correct version). If we could simply update/save the version on the lock there would be no chance of us getting into a state that would require the intervention of support. Would the ability for us to change this field cause potential problems with license abuse?

(Oct 25 '12 at 19:08) Matthew Burnell Matthew%20Burnell's gravatar image

I agree license manager message could be made better. I've added a record in our issue tracker for this task. As for manual hardware lock removal: we disabled that feature for regular users defensively. It requires some investigation before we can enable it.

(Oct 29 '12 at 07:27) Denis Krjuchkov Denis%20Krjuchkov's gravatar image

Thanks again for the information; I'll mark your previous answer as accepted.

(Oct 29 '12 at 18:27) Matthew Burnell Matthew%20Burnell's gravatar image
Your answer
Please start posting your answer anonymously - your answer will be saved within the current session and published after you log in or create a new account. Please try to give a substantial answer, for discussions, please use comments and please do remember to vote (after you log in)!
toggle preview

powered by OSQA