I've recently blogged about Compriz - the new Linux window manager. What really caught me there, was the great possibility to have different desktops with different applications on them. Well, today I occasionally ended up on the PowerToys for Windows XP page, where I found a similar tool that I've fell in love from the very first minute :-). It's name is "Virtual Desktop Manager" and can be found here. I really welcome the idea to have different desktops for different things I do and this tool allows me to accomplish this. I am usually with so many items opened and it's so hard to navigate between them. Definitely having different desktops for the different things I do will help me better organize my computer and work. On this page you will find some other useful tools like "Command Prompt From Here" and the famous TweakUI.
Hey, I know that this post is not very techy, but this tool really got me. I hope that it will give you a little bit of satisfaction and joy (as it did with me) :-).
Monday, May 15, 2006
Friday, May 05, 2006
Debugging OneWay Web methods
Damn, today I lost like 3 hours debugging for this one - I was not able to debug a Web method declared as OneWay. For those of you who are not aware, OneWay method is like calling a regular Request/Response Web method asynchronously. However, with OneWay Web method the ASP.NET will not wait for any return value from the Web method.
Well the first lesson learnt is: while debugging from the client side code, you cannot step into the server side code! Indeed, if you have a nice-and-tidy Request/Response Web method, you can step into the server side implementation right from the client side proxy. But taking into the account that the OneWay methods are executed asynchronously, obviously you can't do it in this way. What is your solution then? Well, you have to attach the target Web server's ASP.NET worker process (aspnet_wp.exe), set the breakpoints into your OneWay Web method and finally run the client side code (usually it is a Web form which calls your Web method). Simple as that! End of lesson 1.
And this is the place, where I am approaching the second lesson (in debugging XML Web services :-) ): in order to be able to debug your OneWay Web methods, your Web service should be compiled with ".NET" platform setting (not mentionting at all that the configuration MUST be DEBUG!). The case that I had was that there were couple class libraries included in the solution, which contained the business logic. The same class libraries were called by the Web methods. So far so good. The problem is that the build platform for these libraries is "Any CPU", which somehow is not compatible with the .NET debug configuration of the WEb services. So if I do NOT set the ".NET" platform to be active for the whole solution, then I am not able to hit my breakpoints in the OneWay Web method, otherwise - it is working nicely!
Ah, I am using Visual Studio 2005 Team System and of course, Microsoft .NET framework 2.0 - to give you an idea what is the development environment.
Well that's all folks - I hope that if someone of you ends up in the same problem, this could give him/her a solution! :-)
Well the first lesson learnt is: while debugging from the client side code, you cannot step into the server side code! Indeed, if you have a nice-and-tidy Request/Response Web method, you can step into the server side implementation right from the client side proxy. But taking into the account that the OneWay methods are executed asynchronously, obviously you can't do it in this way. What is your solution then? Well, you have to attach the target Web server's ASP.NET worker process (aspnet_wp.exe), set the breakpoints into your OneWay Web method and finally run the client side code (usually it is a Web form which calls your Web method). Simple as that! End of lesson 1.
And this is the place, where I am approaching the second lesson (in debugging XML Web services :-) ): in order to be able to debug your OneWay Web methods, your Web service should be compiled with ".NET" platform setting (not mentionting at all that the configuration MUST be DEBUG!). The case that I had was that there were couple class libraries included in the solution, which contained the business logic. The same class libraries were called by the Web methods. So far so good. The problem is that the build platform for these libraries is "Any CPU", which somehow is not compatible with the .NET debug configuration of the WEb services. So if I do NOT set the ".NET" platform to be active for the whole solution, then I am not able to hit my breakpoints in the OneWay Web method, otherwise - it is working nicely!
Ah, I am using Visual Studio 2005 Team System and of course, Microsoft .NET framework 2.0 - to give you an idea what is the development environment.
Well that's all folks - I hope that if someone of you ends up in the same problem, this could give him/her a solution! :-)