Archive for September, 2013

Getting up and ruinning with the vSphere SDk for c#

September 25th, 2013 No comments

Getting up and running with vSphere webservice APIs to code custom tools for VMware automation

if you are anything like me, this is something you have weanted to play with . . but every time you tried, you get stuck in the myriad of partisal information on the web. alwaysd specific to a particular version of Visual Studio, or copy of the Vmware SDKs.

This is how I got up and running:


To set up a development workstation to use C#

1 Install the Microsoft Visual programming environment, such as Microsoft Visual C# or Microsoft Visual Studio.
Use Microsoft Visual Studio 2008 or later, which includes the required .NET Framework.

2 Obtain the Microsoft .NET Framework, if it is not included in the Microsoft Visual programming environment.
Use .NET version 3.5 or later, according to your Visual Studio version.

3 Download and install the Microsoft .NET Framework 2.0 SDK (x64) from
Note Virtual Studio includes a version of .NET version 2.0, but that version does not contain the tools needed to build the DLLs.

4 Find the location where the Microsoft .NET Framework 2.0 SDK (x64) files were installed. Verify that the installation directory contains a subdirectory named Bin, which contains a file named wsdl.exe. Typically, the Framework SDK is installed at C:\Program Files\Microsoft.NET\SDK\v2.0 64bit.
5 Edit your Windows registry to identify the location where the Microsoft .NET Framework 2.0 SDK (x64) was installed. Under the key HKLM\SOFTWARE\Microsoft\.NETFramework, verify that there is a string value named sdkinstallRootv2.0 with a string value of the full path name to the installation directory. If sdkinstallRootv2.0 is not present, add it.

6 Download and install Microsoft Web Services Enhancements (WSE) 3.0 from
Note The default option for the WSE installer includes only the runtime, not the WSDL tool. Select another option to include the Tools directory.

7 Download and unzip the VMware vSphere Web Services SDK package from the VMware Web site at (actually –

Assuming default locations for Above installs, (again more info in above doc), launch your Visual studio command prompt (not a normal Dos / Powershell Shell, as these don’t have access to all the VS tools)

Create the WSE_HOME environment variable, setting its value to the absolute path to the directory where WSE was installed. For example:
set WSE_HOME=C:\Program Files (x86)\Microsoft WSE\v3.0
(Note the doc linked above has a spelling typo in the path – programe, not program)

Add the WSE tools directory to the PATH environment variable:
set PATH=%PATH%;%WSE_HOME%\Tools

Create the SDK_HOME environment variable, setting its value to the absolute path to the directory containing all the SDK files extracted from the zip file you downloaded. For example:
set WS_SDK_HOME=D:\vSphere5.5_SDK\SDK

Create the WSDLHOME environment variable, setting its value to the absolute path to the directory where the WSDL files were stored when you uncompressed the SDK download file. – Assuming you used the same folder as me to extract tghe SDK to (D:\vSphere5.5_SDK) you need to do the following:
set WSDLHOME=D:\vSphere5.5_SDK\SDK\vsphere-ws\wsdl\vim25

If your Microsoft development and .NET software has not been installed using default paths, create and set the VSINSTALLDIR environment variable

Now, I only wanted to manage vSphere and use the sample programs, however, it seems that the samples need a DLL created in the SSO step of this doc. so next step as follows:

### Building the vSphere DLLs
You have some automated samples available on the web here to create the DLLs:

Scripted (more or less what I’ll do below)

Extraction from PowerCli (this is quick and easy)

Navigate to the .NET subdirectory for SSO client samples.
cd %WS_SDK_HOME%\ssoclient\dotnet\cs\samples

Generate a test certificate and STSService stubs using the build.bat script.

Copy the SSO DLL to the %SDK_HOME%\vsphere-ws\dotnet\cs\samples\DLLs directory.
copy lib\STSService.dll %WS_SDK_HOME%\vsphere-ws\dotnet\cs\samples\DLLs\.

# Now for the vSphere Dlls

Navigate to the .NET subdirectory for vSphere client samples.
cd D:\vSphere5.5_SDK\SDK\vsphere-ws\dotnet\cs\samples

Generate the VimService.cs file from the WSDL, using the following command syntax with the WSE WSDL tool:
wsewsdl3.exe /n:Vim25Api /type:webClient /l:CS "D:\vSphere5.5_SDK\SDK\vsphere-ws\wsdl\vim25\vim.wsdl" "D:\vSphere5.5_SDK\SDK\vsphere-ws\wsdl\vim25\vimService.wsdl"
This command generates VimService.cs, the default output file, in the current directory, using the Vim25Api namespace.

Compile VimService.cs into a library, using the following command syntax:
csc /t:library /out:Vim25Service.dll /r:"C:\Program Files (x86)\Microsoft WSE\v3.0\Microsoft.Web.Services3.dll" VimService.cs
This command generates a serializer assembly, a DLL.

Use the sgen tool to pre-generate and compile the XML serializers, using the following command syntax:
sgen /p Vim25Service.dll
This command outputs the Vim25Service.XmlSerializers.dll file in the current directory. This DLL file contains pre-generated XML serializer code.

Using a source code editor (notepad++ for me – Hit Ctrl H and do a search and replace), find occurrences of the following string in the VimService.cs file that you generated 3 steps ago (D:\vSphere5.5_SDK\SDK\vsphere-ws\dotnet\cs\samples\VimService.cs)
Replace occurrences of the string with:
// [System.Xml.Serialization.XmlIncludeAttribute
This will prevent .NET from processing the Xml.Serialization.XmlIncludeAttribute attributes that are the main cause of the slow instantiation of the Vim25Service class.

Annotate the VimService class in the VimService.cs file that you generated, adding this XmlSerializerAssemblyAttribute to point to the location of the XML serializer assembly:
[System.Xml.Serialization.XmlSerializerAssemblyAttribute(AssemblyName = “Vim25Service.XmlSerializers")]
The result should look something like the following example:
// ... Some code here ...
[System.Xml.Serialization.XmlSerializerAssemblyAttribute(AssemblyName = “Vim25Service.XmlSerializers")]
public partial class VimService : Microsoft.Web.Services3.WebServicesClientProtocol {
// ... More code here.

Save the modified VimService.cs file.

Regenerate the Vim25Service.dll library with the following command syntax:
csc /t:library /out:Vim25Service.dll /r:"C:\Program Files (x86)\Microsoft WSE\v3.0\Microsoft.Web.Services3.dll" VimService.cs

Copy the generated files Vim25Service.dll and Vim25Service.XmlSerializers.dll to the “D:\vSphere5.5_SDK\SDK\vsphere-ws\dotnet\cs\samples\DLLs” directory.
copy Vim25Service*.dll DLLs

### Generate the DLL for SSO:
In the Visual Studio command shell that you have open:

Navigate to the .NET subdirectory for SSO client samples.
cd "D:\vSphere5.5_SDK\SDK\ssoclient\dotnet\cs\samples"

# Building the samples:
Launch Visual Studio and load the solution file, Samples2008.sln.
The solution file is found in the D:\vSphere5.5_SDK\SDK\vsphere-ws\dotnet\cs\samples directory.
If you are using a version of Visual Studio later than 2008, the Visual Studio Conversion Wizard will prompt you to convert the 2008 solution file to the newer version. If you also have Visual Studio 2008, you should select Yes when the wizard offers to save a backup of the original solution file.

If you are using a version of Visual Studio later than 2008, convert each project to use .NET Framework 4.
The projects in the 2008 solution file are configured to use .NET Framework 3.5. To convert a project to use .NET Framework 4, right-click its name in the Solution Explorer and select Properties. In the Properties panel, change the Target Framework from .NET Framework 3.5 to .NET Framework 4.

From the Visual Studio menu, select Build > Build Solution.
All the sample programs build. The Output pane at the bottom of the Visual Studio window shows build errors, if any.

Correct any errors in the build, and repeat the build.

At this point, you should be able to import the solution contain all the projects from the sameples folder.

These are command line apps, but should allow you to get started,

Categories: Uncategorized Tags: