VMware {code} Community
robertleewhite
Contributor
Contributor
Jump to solution

.Net SDK versus Web Services

Hi, the .Net SDK that comes with the PowerCLI downloadable seems quite robust, and is what I'm planning on using when designing my .Net application to manage vCenter Server. However, before I get started, I was wondering if there would ever be any reason for me to directly connect to the vCenter Server web services. Does the .Net SDK encapsulate all the functionality of the bare web services, or is there a scenario where I might need to connect directly to the web services?

Basically, what I'm asking is if one is designing a .Net app to manage vCenter Server, is there any reason to ever directly connect to the vCenter Sever web services instead of simply using the .Net SDK DLL?

Thanks,

-Robert

0 Kudos
1 Solution

Accepted Solutions
ToolsDev
Contributor
Contributor
Jump to solution

Hi Robert, I'll try and answer your question.

I recently stuggled like mad to get up the steep curve of learning how to interact with vSphere via web service using .Net. After reading some stuff I decided to give the VMWare.Vim implementation a second go.

From my experieces, the VIM dll adds a layer of abstraction between you, .Net and the vSphere web service API. I have yet to come across any functionality of the API that I cannot use via the VIM dll. It has greatly simplified me producing a data driven provisioning engine to setup test and development environments and for that I am thankful.

So to answer your question, from my experiece, no there's nothing you cannot do if you use the VIM dll instead of accessing web services direct.

View solution in original post

0 Kudos
6 Replies
ToolsDev
Contributor
Contributor
Jump to solution

Hi Robert, I'll try and answer your question.

I recently stuggled like mad to get up the steep curve of learning how to interact with vSphere via web service using .Net. After reading some stuff I decided to give the VMWare.Vim implementation a second go.

From my experieces, the VIM dll adds a layer of abstraction between you, .Net and the vSphere web service API. I have yet to come across any functionality of the API that I cannot use via the VIM dll. It has greatly simplified me producing a data driven provisioning engine to setup test and development environments and for that I am thankful.

So to answer your question, from my experiece, no there's nothing you cannot do if you use the VIM dll instead of accessing web services direct.

0 Kudos
robertleewhite
Contributor
Contributor
Jump to solution

Wow, thanks so much for the very helpful reply! That was exactly what I was looking for.

-Robert

0 Kudos
nikhilxp64
Enthusiast
Enthusiast
Jump to solution

Is there any reference for the API exposed by the Vim dll? I am still confused between this and the web services SDK which I am using right now.

0 Kudos
robertleewhite
Contributor
Contributor
Jump to solution

That confused me too. The "reference" for the .NET library basically just talks about the methods and objects that are exclusive to the DLL, which isn't much at all. What I am using is the "Dev Guide" (which is in the PowerCLI documentation folder along with the reference file) plus the web services API reference. I've found that there's almost always a 1-to-1 match between the .NET method and the web services method, so the web services API reference mostly suffices.

Hopefully that helps!

0 Kudos
ToolsDev
Contributor
Contributor
Jump to solution

Yeah, forget the documentation that comes with the PowerCLI stuff.

Just use this guide below.

http://www.vmware.com/support/developer/vc-sdk/visdk25pubs/ReferenceGuide/index.html

The most confusing part for me to begin with using the VIM dll was the fact that I had to get an object before I could do anything with it.

So for example, if I wanted to manipulate a VM, I needed to get it first using (I code in VB.net):

  • Dim Filter As New NameValueCollection
  • Filter.Add("name", "MyVMName")
  • Dim myVm as VirtualMachine = Client.FindEntityView(GetType(VirtualMachine), Nothing, Filter, new string() {"name"})

This would bring back a pretty naked object as I only specify the name as a the property to return. This provides me with little info on the VM's object, but it's enough to allow me to manipulate it (which is good as less properties returned means less load on the vCenter web service).

Then I could use that object to do stuff like:

  • myVM.ShutdownGuest

If I wanted to get my VM with all info populated I'd do this:

  • Dim myVm as VirtualMachine = Client.FindEntityView(GetType(VirtualMachine), Nothing, Filter, Nothing)

If I wanted to get my VM with just other specific properties, I'd just add them in to the string array for properties:

  • Dim myVm as VirtualMachine = Client.FindEntityView(GetType(VirtualMachine), Nothing, Filter, new string() {"name", "config.hardware.device"})

The same goes for any other managed object references. If you want to manipulate a hostSystem, just grab the object using the VIM dll:

  • Dim myHost as HostSystem = Client.FindEntityView(GetType(HostSystem), Nothing, Filter, Props)

If you need to get multiple objects, use FindEntityViews instead, which will always return an IList(Of EntityViewBase).

  •      Client.FindEntityViews(GetType(HostSystem), Nothing, Nothing, Props)

You then just cast each returned object in the list into it's specific type, in this case, HostSystem

FindEntityView or FindEntityViews from my understanding is only used to get ManagedObjectReference types. If you need to get DataObjectTypes, you use GetView or GetViews. This may be wrong though. Sometimes I had to use GetView if FindEntityView threw an error. Just try them out until you get the hang of it.

ToolsDev
Contributor
Contributor
Jump to solution

In answer to the original question, see slide three of the pack below:

http://www.slideshare.net/vmwarecarter/using-vi-toolkit-for-windows-from-net

Yes, all of the web service functionality is exposed by the VMWare.VIM.dll.

The slide pack as a whole is very good to getting started with using the wrapper dll and I used it myself.

0 Kudos