HowTo: Building the vSphere Web Services SDK 4.1 for .NET
One of my gripes about the vSphere Web Services SDK (formerly VI SDK) is that the process to generate .NET web services stub files has always been a bit of a mixed bag. This is especially true if you like to operate on the cutting edge of technology and use modern IDEs. Microsoft released Visual Studio 2010 in April (of 2010) and VMware released their latest version of the vSphere Web Services SDK (4.1) two months later, and the latter offers no support for the former. You might argue that two months isn’t enough time to support a new product the size and scope of Visual Studio, but I call shenanigans for three reasons:
- Development versions of Visual Studio 2010 have been available in some form or fashion since last fall.
- Which is besides the point, because building the web services stub files and the sample projects does not require Visual Studio!
- I put together a Visual Studio-less compatible version of the vSphere Web Services SDK 4.1 build process in about 30 minutes.
Here is how to build the vSphere Web Services SDK 4.1 without Visual Studio 2010 and for .NET 3.5 and 4.0.
The vSphere Web Services SDK 4.1 package includes a DotNet directory that contains batch files for building the web services stub files using Visual Studio 2005 or 2008. Using the 2008 files, Build2008.cmd and genvimstubs2008.cmd as starting points, I created Build2010.cmd and genvimstubs2010.cmd (ripping out all references to Visual Studio). Download the files and place them in the same directory with the older versions.
From a command prompt (it doesn’t haven’t to be a Visual Studio command prompt, because Visual Studio is not a requirement for building the web services stubs — although you will need the Windows SDK) you can now run the command following command to generate the vSphere 4.1 web services stub files:
The above command will generate assemblies dependent upon the .NET 4.0 runtime. If you want to generate assemblies using the .NET 2.0 runtime with the .NET 3.5 framework and its tools (and I recommend that you do), simply execute the same file with a single parameter of 1 like so:
This will cause the stubs and examples to be built using the .NET 3.5 compiler against the .NET 2.0 runtime (the same runtime that the vSphere4 client uses — that means you can use these assemblies from within vSphere4 plug-ins, if you depend on the .NET 4.0 runtime you cannot). You can view the output of this command here.
You may be asking why do the outputted assemblies still have the “2008″ suffix? This is because all of the sample projects reference VimService2008 or Vim25Service2008 and if I updated the file names to 2010 then I’d have to update all of the “.csproj” files to reference the new names. It was simpler to leave the file names as is. If you really want to change them, you can edit two place-holder variables I created at the top of the Build2010.cmd file.
Oh, and if you’re wondering how the samples are built without Visual Studio. Simple — I employ the msbuild program — which ships with the .NET framework and does not depend on Visual Studio. The other tools the Build20xx.cmd files depend on, wsdl.exe, sgen.exe, all ship with either the .NET framework or Windows SDK. No more Visual Studio needed!
Hope this helps!
Filed under: software development, virtualization | 9 Comments