Vim25Service.dll very slow to open a channel

[chrispatrick]

I am using the latest version of the SDK and have noticed that ChannelFactory.CreateChannel is really rather slow.

I have found articles such as https://stackoverflow.com/questions/172095/slow-soaphttpclientprotocol-constructor which indicates that this is a problem with .NET's XmlSerializer stuff and the Serialization attributes should be stripped from the generated C# code after using SvcUtil. Could that be the case here?

[vinpai]

It is possible. I am adding Jobin, to see if he has any comments here and also to add this in the backlog as an improvement.

Also, if the API you are using is available in the newer vapi-client-bindings.dll, then I suggest you use it from there. We have also included the wsdls used for generating the legacy vsphere web service sdk dlls in the "wsdl" folder, so you can try following the mentioned steps and see if it resolves the problem.

[SergeyFilippov]

Hello, the same story here. Unfortunately, it's not limited only to ChannelFactory.CreateChannel, but for example the call to VimPortType.RetrieveServiceContent also takes around 40 seconds (just like CreateChannel).

6.5 version don't have those issues (built manually from sources, as it was previously).

This is really sad, since evein if credentials are wrong, one need to wait minimum 1.5 minutes to get an exception.

update I've manually generated the web services DLL as @vinpai suggested, and now it works as previously - super fast comparing to repository-dll. I've noticed, that the size of my DLL using old compilation method is 12 mb, while repository-dll is 16 mb. It looks like to me, that the step with XML serializers was skipped during compilation of repository-dll and all the delays are just a serialization overhead. It's needed to mention, I had to manually edit the serializers cs file in order to make it compilable.

Are vapi dll's also having same issues?

[vinpai]

You won't see those issues with the vapi dll.