I am trying to get Finalbuilder (FBCMD.exe) run inside a Windows Docker Container. On my server there is a Jenkins master that uses the Docker Containers as slaves. As a Build Step I want to start a FB8 Project inside the Container via FBCMD.exe (I know about the licenses I need for the virtualization, got a site license).
I installed FB8 with a /VERYSILENT Install inside the container. The Docker Container has .net framework > 4.5 and Powershell Version 5.xx. ans the license key is located in the correct path. “C:\Program Data…”
But everytime I try to run the FBCMD.exe inside the container it does absolutely nothing. The same command works on my desktop pc.
Gave the container a Volume to easily copy files from my host (Win Server 2016) to the container.
Checked Powershell and .net Framework Version
Copied the FB8 installer to the container
Installed it via “.\FB800… /VERYSILENT” and checked if the files are existent in “…Program Files (x86)”
Moved the license key from my host to “C:\Program Data\VSoft…”
Stopped the container and created a new image using the “docker commit” command
Started a new container with the recently created image and tried to start the FBCMD.exe
and thats the point where I got stuck. Parallel to the steps mentioned above I installed Java and copied the agent.jar into the container. They are working correctly in the newly created image.
Thanks for the additional information. We set up a similar docker container today and had the same result when running fbcmd.exe - no output and no event log entry. Something is missing but we’re not sure what. We’ll investigate further on Monday.
Further investigation shows us that fbcmd is failing to start with $C0000135 (“the program can’t start because %hs is missing from your computer. Try reinstalling the program to fix this problem.”) - not very helpful from windows at all (no more details, nothing in the event log).
I set up a server core vm to test with, and made some progress, in that it shows a messagebox with the name of the missing dll - copying opengl32.dll, glu32.dll and oledlg.dll from c:\windows\SysWOW64\ on my up to date W10 machine allows fbcmd to run.
Unfortunately, that doesn’t seem to work in the docker container, using this dockerfile
# escape=`
# Use the latest Windows Server Core image with .NET Framework 4.8.
FROM mcr.microsoft.com/dotnet/framework/sdk:4.8-windowsservercore-ltsc2019
# Restore the default Windows shell for correct batch processing.
SHELL ["cmd", "/S", "/C"]
# Default to PowerShell if no other command specified.
CMD ["powershell.exe", "-NoLogo", "-ExecutionPolicy", "Bypass"]
ENV chocolateyUseWindowsCompression false
RUN powershell -Command iex ((new-object net.webclient).DownloadString('https://chocolatey.org/install.ps1')); choco feature disable --name showDownloadProgress
RUN choco install -y finalbuilder
COPY FB800-0001-000001.license c:\programdata\vsoft\finalbuilder8
ARG target="C:/Program Files (x86)/FinalBuilder 8/"
ARG src=fbcmd.exe
ARG src2=test1.exe
COPY ${src} ${target}
COPY ${src2} ${target}
COPY opengl32.dll ${target}
COPY glu32.dll ${target}
COPY oledlg.dll ${target}
Now these missing dll’s are statically linked from either the delphi runtime packages or from third party libraries, even though they are probably not used in fbcmd.
We’re continuing to look into this, as we’d really like to see fb running in docker.
Hi Vincent,
thanks for your investigation and an information about the status quo.
Right now I am on vacation so I won’t work on the project either. But i am checking the forum to see the progress you make. Looking forward for further results. Best of luck.
right now i am back from vacation. How is the status quo? Did you manage to run the FBCMD.exe somehow? I will take a look into this from now on as well.
Nope sorry. I got it running on Server Core by figuring out which dll’s were missing, however it would not run on docker.
The problem is that the action packages reference other packages that statically link to ui windows dlls, even though it’s not used by fbcmd.
That has worked fine on windows and never been a problem, however for docker it’s obvious that needs to change.
It’s a major bit of work, splitting each action package into a design and a runtime package. It’s too risky to do for FB8 as it may break things, so we will do this as part of the work for FB9 which is currently under development - I can’t give an ETA on this at this time.