Slow startup with Web Service Client due to XmlSerializer

[kennethxu]

As we knew the slow startup problem caused by the XmlSerializer, is there anyway to pre-compile the serializer for spring generated the web proxy client? With sgen.exe or XGenPlus?

Any input is much appreciated.

-kennethxu

[Bruno Baia]

Hi,

I don't see any problems with this.
Spring.NET does not generate dynamically domain types, only the proxy type.

Cheers,
Bruno

[kennethxu]

We are using SGen.exe to create pre-compiled XmlSerializer. It works for our domain object. But doesn't do it for those httpsoap proxy generated by spring.net. If we creates the .NET web service client. SGen sees it and pre-compiles them. I'm guessing may be related to those soap request and response objects. I'll try to get more information.

[kennethxu]

As promised, although a bit late as this was not my top priority, I'm now back with more detail information as well as a solution for this.

http://kennethxu.blogspot.com/2008/0...springnet.html

[kennethxu]

Originally Posted by Bruno Baia

Hi,

I don't see any problems with this.
Spring.NET does not generate dynamically domain types, only the proxy type.

Cheers,
Bruno

Hi Bruno,

SGen indeed generates the serializer for classes implement SoapHttpClientProtocol with WebServiceBindingAttribute set. When web service client is generated by the Spring.Net dynamic proxy, the temporary assembly was created by XmlSerializer in runtime. So the Spring.Net web service client indeed starts up much slower. See the link in my previous post for detail.

I guess the server side would have same problem but it is not such a big deal as the server is more tolerable to startup performance.

I'm looking into a solution to generate the source code at compile time instead of emit dynamic proxy at runtime.

Cheers,
Kenneth

[swalters]

Kenneth,

I've very glad to see you working on this. We just released v1.0 of our clickonce application with Spring.Net Web Service proxies and I am seeing the same thing. What's worse is that our v1.1 introduces more features with more webservices which will slow it down even more.

I'll keep a close eye on your progress.

-Shane

[kennethxu]

Swalters,

Glod to know that I'm not along here. I was able to create the code generator, still trying to fiigure out a way to integrate with Visual Studio. Suggestions are welcome. See my blog for more detail:

http://kennethxu.blogspot.com/2008/0...b-service.html

Cheers!

[.ben]

I'm confronted with this as well, for now I've just been using a splash screen to get around it .

[kennethxu]

Hello swalters and ben,

Sorry for keep you waiting. I had to take care my sick discuses that I just got from a local pet store by trading in our two huge 10 inch blood parrot cichlids. The blood parrots were too big to be in our 55 gal tanks.

OK, finally, I have an open source project setup at CodePlex (http://www.codeplex.com/WSCodeGen). You are very welcome to download the source code there and try it out. I have also updated my blog to include a step by step instruction with an example VS.Net solution.

Cheers,
Kenneth

[kennethxu]

This problem is now resolved by replacing spring.net web service client proxy with http://www.codeplex.com/WSCodeGen. Our application used to create over 300 temp files by 43 web service client if I turn on the XmlSerializer diagnose. Now it generates 0 files.

There is a bug in ClickOnce deployment so that you shouldn't put the generated source file in the executable project. I had to create a special project to hold the generates source file and it worked fine for me. I'll write the detail in my next blog post.

I'm maintaining the XML manually now and looking into transforming from the spring config file. I won't update this thread form now on, but will post any future update in my blog.