Filed under: vmware
UPDATE: This issue has been resolved in vSphere Update 1 link: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1011329
If you are reading this you probably found out that vSphere Client 4.0 is not (yet) running on Windows 7 RC or RTM
Luckily there is a way to make it work.
The error looks like this:

Error parsing the server “name” “clients.xml” file.
First the credits. Big Thanks to FTUBIO from the VMware Communities (link) For supplying this solution.
1. Obtain a copy of %SystemRoot%\Microsoft.NET\Framework\v2.0.50727\System.dll from a non Windows 7 machine that has .NET 3.5 SP1 installed. You can find it in the vclient_on_w2k7_hack.zip file on the bottom of this post.
2. Create a Lib folder in the Windows 7 machine where the vSphere client is installed and copy the system.dll file from step 1 into this folder. Create the folder lib under the vSphere client launcher installation directory (%ProgramFiles%\VMware\Infrastructure\Virtual Infrastructure Client\Launcher\).
3. Copy (and overwrite) the VpxClient.exe.config from the zip file in the bottom of this post to the %ProgramFiles%\VMware\Infrastructure\Virtual Infrastructure Client\Launcher\ folder
note: You might have an issue with the UAC settings and are not allowed to replace files in the Program Files folders. In this case make sure that you run the explorer as administrator (Start -> All programs -> Accessories -> Windows Explorer. Right Click “Run as administrator”).
4. Create a system variable devpath with a value of C:\Program Files\VMware\Infrastructure\Virtual Infrastructure Client\Launcher\Lib
assuming your default install path is C:\Program Files
5. Reboot your machine and start vSphere client (For some people a reboot was not nescesary)
Note1 that this workaround bypasses the normal .NET Framework loading mechanism so that assembly versions in the DEVPATH folder are no longer checked. Handle with care
Note2 If you use Windows 7 64-bit replace “Program Files” with “Program Files(x64)” in all cases
4 Comments so far
Leave a comment
Thanks very much for your post and for the attached zip file. I was able to get my system up and running with your System.dll. I tried using a System.dll from a different article with the same approach and it didn’t work.
You saved the day!
Comment by Darryl 10.18.09 @ 12:49 amThanks very much for this. Every time I have to do this, I end up scouring the forums which is a good way to get frustrated. Thanks for consolidating everything in one place.
Comment by dookie 11.08.09 @ 8:14 pmGreat workaround! Thanks.
Comment by andr3j 12.29.09 @ 11:37 pmLeave a comment

(4 votes, average: 4.75 out of 5)
When you say “this workaround bypasses the normal .NET Framework loading mechanism so that assembly versions in the DEVPATH folder are no longer checked.” is this for all .NET functionality, or just vsphere?
Comment by bcweis 09.04.09 @ 4:25 pm