Everyone knows PAServer (Platform Assist Server) is the easy way to deploy and debug multi device apps from Windows to Apple OS X and iOS. It handles all the bundling and deployment from your Windows development platform across the network, via a virtual machine, or even to the cloud.
Previously I showed you how to connect to a Android Emulator on another machine (or outside your VM), but did you know you can also use the PAServer to deploy and debug against a remote Windows machine? It isn’t required, so isn’t as immediately obvious, but it is supported and pretty easy to setup.
If you are already developing on a Windows machine, why us PAServer to test against a remote Windows machine? There are a lot of reasons, here are a few . . .
- Testing on machine without IDE installed
- Windows tablets
- Different CPU architectures (64-bit vs 32-bit)
- Different numbers of cores
- Utilizing specialized hardware
- Running outside / inside a virtual machine
- Deployment on a server (remote, local, in the cloud)
- Debugging on more than one version of Windows
- Debugging issue that only occurs on one machine
- Bundled deployment options
Now that we see the need, how do we do it?
Install PAServer on the target Windows computer. You can find it at C:\Program Files (x86)\Embarcadero\Studio\17.0\PAServer if you used the default install location during your original install. When installing PAServer, you either need to use a different install location (to a user writable folder), or specify a custom scratch-directory, as the default is not writable (unless you run PAServer as Administrator) and will give you an E0009 PAClient Error. Once PAServer is setup just run it.
Use the Connection Profile Manager to create a new Windows profile.
Instead of the default of OS X, choose either Windows 32-bit or 64-bit. The rest of the configuration is the same.
Then form the Project Manager, right-click on the Windows platform you want to deploy remotely, and select properties.
And then select the new connection you want.
This works with any project type (FireMonkey, VCL, Console, etc.)
Now you can also use the Deployment Manager for Windows apps as well.
11 replies on “10 Reasons to Use PAServer for Remote Windows Deployment”
Remote deployment works, but what about remote debugging via PAServer.
For me it never worked beyond running the program remotely after that breakpoints didn’t fire at all.
This should work. Do you have external debug symbols active? And is the .rsm file deployed correctly to the remote machine?
Sebastian, yep .rsm get’s deployed. I’ve tried session from Win7 x86 (dev) to WS2008R2 (PAServer). But last time I’ve tried to understand how to make remdebug work at all I’ve used loopback connection to the same Win7 x86 host and result was the same – breakpoints didn’t fired.
IMHO, this feature is unreliable and difficult to setup.
How secure is this PAServer? Isn’t it a security problem to deploy it outside of test machines in a firewalled LAN?
@John: Not sure how secure it is, I’ve not tested it in that regard (time to break out Wireshark maybe).
@IL: I thought debugging was working for me when I deployed to a tablet. If you are having issues with it though you can submit a bug report at http://quality.embarcadero.com
Jim, not a tablet. Android debugging is working since XE5 AFAIR.
Perhaps you right, but it’s not possible to make a repro b/c of too many vars in the environment.
@IL I was deploying to a Windows tablet. Try it again and if it still doesn’t work then I will look into it.
Remote debugging of Windows programs through PAServer only works on about 50% of our development machines (Delphi XE5), even though we use *exactly* the same compiler/linker/debugger settings on all of them (remote debug symbols enabled etc). On 50% of the machines breakpoints won’t fire no matter what we do. It is terribly frustrating.
We also had some issues with remote debugging and XE5. We found out that disabling the MAP file in the linker options solved nearly all strange effects. Maybe you can give that a try. And make sure to have the up to date RSM file on the remote machine.
Hi,
Great info,i am newbie so i will try this and will revert back soon. Thank you for sharing
Hi,
I did also get stuck with the breakpoint that did not fire but I found the solution. When the break point does not fire, it is because a debug process is running on the background already on the remote machine. If I remember it is something like rmtdbg.exe. Make sure that this process is not running before you compile your application! If I remember I do not deploy RSM file to the remote machine on windows , and I was able to debug???!!!!