Dotfuscator Pro cant read licensing information under Jenkins buildserver

Question

I'm trying to get Dotfuscator Pro 4.13 to run between the unit tests and creation of installation package. The buildserver that we use is Jenkins 1.487 on Windows Server 2008 R2.

The command line for dotfuscator is very simple, i use /q and point out an xml configuration file. it works like a charm when i manually run the exact command from the commandline.

But when the same commands are executed by Jenkins the following error is logged:

Use of this software implies acceptance of accompanying license agreement. LICENSED TO: SERIAL #: You must first accept the end user license agreement before using Dotfuscator.

For some reason Dotfuscator cant read the licensing information when it's ran by Jenkins. I cant find any information about this but something tells me that this is related to the user that Jenkins is executed under. What am i missing?

Musset

Answer 1

As i thought it was something user related. this problem comes from that the user the Jenkins job is ran under has never accepted the Dotfuscator user agreement. There are two ways to resolve this:

Either you log into the machine with the user that is running the automated build and launch the Dotfuscator GUI and accept the license agreement

Or you can copy the following files:

C:\Users{user that installed/accepted agreement}\AppData\Local\PreEmptive Solutions\Dotfuscator Professional Edition\4.0\dfusrprf.xml
C:\Users{user that installed/accepted agreement}\AppData\Local\PreEmptive Solutions\Dotfuscator Professional Edition\4.0\dotfuscator.cfg
C:\ProgramData\PreEmptive Solutions\Dotfuscator Professional Edition\4.0\dotfuscator.dat

into the installation directory of dotfuscator (default is C:\Program Files (x86)\PreEmptive Solutions\Dotfuscator Professional Edition 4.13.0).

Musset

I had the same problem, but with TeamCity. This fixed it. Also noteworthy: for some reason there were two accounts of the same name -- one local and one on our domain (e.g. buildserver\buildUser and also CORPORATEDOMAIN\buildUser). This was killing me because I remoted in using just the "buildUser" username (the domain was implied), and when I ran the same cmd it worked fine. I finally noticed I was running the agent service as ".\buildUser". At any rate, this answer was the solution. Hope this saves someone in the future. – Everrs

Glad it could help someone else! @JayQuerido – Musset

Not sure if it is Dotfuscator Version specific but in my case I only had the *.xml and *.dat file as mentioned in the answer by Hubert. – Sternlight

Answer 2

I had a similar problem using Team Foundation Build Service running under Windows Server 2012.

According to Dotfuscator's tech support:

To resolve this you will need to move the following files:

C:\Users{User that installed dotfuscator}\AppData\Local\PreEmptive Solutions\Dotfuscator Professional Edition\4.0\dfusrprf.xml C:\Users{User that installed dotfuscator}\AppData\Local\PreEmptive Solutions\Dotfuscator Professional Edition\4.0\dotfuscator.cfg

Into the same folder on the user account that is running the automated build.

I was running my build service under NT AUTHORITY\NETWORK SERVICE. After some searching I found their home directories:

%systemroot%\ServiceProfiles\NetworkService

which usually translates as:

c:\Windows\ServiceProfiles\NetworkService

Meteorology

Hi Hubert , i don't see the pre emptive folder structure under "c:\Windows\ServiceProfiles\NetworkService" , do i need to create the folder structure ? c:\Windows\ServiceProfiles\NetworkService\AppData\Local\Pre... ? – Galvin

Also you mention the files have to be moved, just to be clear they have to cut and pasted in the network service folder right ? – Galvin

Thanks Hubert , i recreated the same folder structure and now the build is progressing. :) – Galvin

Please note that this worked for myself under an Azure build. I had to copy this PreEmptive folder from my own user appdata\Local into the NetworkService AppData\Local folder – Lammond