2

Context:

I'm trying to set up a Jenkins (2.223) build server (build using msbuild in this case) on Windows Server 2012 R2. Jenkins is set up as a service and runs as Local System.

Problem:

I've run into a problem where I can run a build script when RDP'd in as the Administrator user, but cannot run the same script through Jenkins. After some digging, I've found that the directory with the required build references (C:\Windows\System32\config\systemprofile\.nuget\packages) is not being found by Jenkins. With a little more investigation, I've found that the directory C:\Windows\System32\config\systemprofile appears to be inconsistent.

I can run the command dir C:\Windows\System32\config\systemprofile through my Administrator account and I get:

     Directory: C:\Windows\System32\config\systemprofile


Mode                LastWriteTime     Length Name
----                -------------     ------ ----
d----         3/11/2020   9:43 AM            .dotnet
d----         3/11/2020   2:27 PM            .nuget
d----          3/9/2020   1:49 PM            .ssh
d----         8/22/2013   6:36 AM            AppData
-a---          3/2/2020   3:41 PM     262144 ntuser.dat

I can run the same command (dir C:\Windows\System32\config\systemprofile) through Jenkins, and I get:

    Directory: C:\Windows\System32\config\systemprofile


Mode                LastWriteTime     Length Name                              
----                -------------     ------ ----                              
d----          3/9/2020   1:49 PM            .config                           
d----          3/6/2020   2:50 PM            .groovy                           
d----         8/22/2013   8:39 AM            AppData

I need the references within ...\systemprofile\.nuget\packages\ to be seen by Jenkins in order to complete the build (the references are put there by a nuget restore command run by the Jenkins service, so this seems reasonable to me). And to be honest, I'm not familiar with the concept of dir giving different results. I suspect Windows shenanigans, but I'm curious as to what's actually going on - why am I getting different results based on the user running the command?

Additional Info:

  • I was able to get this working on my local Windows 10 desktop without any hassle. I do still get different results when executing the dir command as my user versus the Jenkins service, but they both happen to have the systemprofile\.nuget\packages directory available.

  • On the 2012 server, my Admin user's $env:UserName and $env:ComputerName are Administrator and WIN-64VG7CF1QK3 respectively. The Jenkin's local system $env:UserName and $env:ComputerName are both WIN-64VG7CF1QK3.

axbin
  • 41
  • 3
  • 3
    The symptom suggests that one process is a 64-bit process and the other a 32-bit one. Such processes see distinct directories as `C:\Windows\System32`, though you can technically access the respective other one as `C:\Windows\SysWOW64` (the 32-bit dir. from a 64-bit process) and `C:\Windows\SysNative` (the 64-bit dir. from a 32-bit process). – mklement0 Mar 12 '20 at 17:29
  • 2
    I recommend to replace the default 32-bit Java runtime of Jenkins Windows version by 64-bit one to avoid these hassles. [See this answer](https://stackoverflow.com/a/60398437/7571258). – zett42 Mar 12 '20 at 18:47
  • @zett42 - thanks you two! Very helpful information. I'd upvote your comments but yet do I have that privilege. – axbin Mar 13 '20 at 17:58

1 Answers1

2

The two comments on my question (mklement0 and zett42) answered this pretty well, and using them I was able to better understand and resolve my issue.

It turns out that Jenkins does install 32-bit JRE by default - which ends up silently looking at SysWOW64 instead of System32 (but only during the msbuild command and not the nuget restore command?).

Anyways, the solution is to configure Jenkins to use a 64-bit JRE as suggested by zett42. See this answer.

axbin
  • 41
  • 3