VMware (my version is 5.5) has botched the path it uses for accessing files on the host. If your guest is Windows XP (among others), you can “share folders” from your host operating system to the guest operating system using vmtools. The shared folders are accessed under the network path:

\\.host\Shared Folders\folderName

Having the name of the computer start with a period completely messes up a lot of functionality in Windows when it’s trying to work with the shared folder. You can access \\.host from Windows Explorer, but I think that’s somehow aided by vmtools. You can’t access \\.host from the CLI, which seems to indicate that windows doesn’t handle \\.host-like paths and that vmtools has to intervene to make it work. Which makes me wonder why they made the shared folder accessible under a weird name like \\.host in the first place…

If you run a .NET application that sits in a shared folder, it’s going to get totally confused if it tries to decipher where it’s running from (e.g. by opening a file using a relative path, or calling System.Windows.Forms.Application.ExecutablePath). You’ll certainly get a System.UriFormatException, because the .NET framework can’t tell where the heck it’s running from.

You can always copy the shared folder to your desktop and access the files in there, but that grows tiresome and is usually not feasible. The most elegant solution is to use mapped network drives. Just map the weird \\.host path to something intelligble — a drive letter in Windows. You can do this from Explorer by accessing Tools -> Map Network Drive. You can make \\.host\Shared Folders show up as the drive letter Z: Then CLI commands like copy will be happy, and so will your .NET apps!