Hello Ruud,

Configure Xenocode to spawn child processes outside of the VM.  The .Net Framework 2.0 or above will need to be present on the client.

The Application Directory should already be the physical location of the running application on your clients.  If this is not the physical location of the virtualized Xenocode host file, is it consistently relative to it?  You can move up and down the client file system hierarchy with the Location property. (e.g [ApplicationDirectoy]\..\..\Higher Folder)

If that doesnt work, you can use the OverrideHostProcessInfo method of the update controller.  Call this method, passing in your application process name and the location of your virtual host file before you call ApplyUpdate. The path that you pass in will map to the ApplicationDirectory of your update project. 

Application.StartupPath returns the path of the exectuable that started the application, not including the executable name.  It looks like this is returning a program files directory from within the virtual application, which is the same directory the Update Controller thinks your application starts from. 

You need to be able to locate the Xenocode file from within your application code.  I can't tell you how to do this as I am not familiar with Xenocode.  I know we have other customers who update Xenocode virtualized applications so there must be a way to do it through a Xenocode library.

When you use the OverrideHostAssemblyInfo method, the Process Name should exclude the extension, and the assemblyLocation should include the full location including the file name.  Your application will close once you exclude the .exe extesion on the ProcessName.  You will still need to be able to determine the location of your original Xenocoded file.