Rob Gillen's WebLog

Web Service Studio

Those of you who interact with and develop XML web services on a regular basis are probably very familiar with this tool or have other tools that you have purchased/developed to provide similar functionality, but I came across the Web Service Studio (http://www.gotdotnet.com/Community/UserSamples/Details.aspx?SampleGuid=65a1d4ea-0f7a-41bd-8494-e916ebc4159c) last night while working on a little web service project and I think it is great… It is straight-forward in its operation, and doesn’t have alot of “jazz” to the UI, but it does what it is designed to do… which is providing you with a means of interacting with Xml web services in an adhoc fashion.  I used it primarily as a testing tool, to validate that the web services I was creating worked as they should.  There are many other tools that one could use for performing such a validation… the built-in test page (only works on the local machine), building a custom client such as a winform app (this works, but requires a custom build for each web service which is hardly efficient), using a tool such as InfoPath to quickly build a test form (again, very effective, but requires a new form for each web service).  Web Service Studio allows me to simply point to a url after which it will read the WSDL, enumerate the methods available to me, generate the proxy, and let me test/probe each request right there… better yet, it allows me to see the raw XML request being sent back and forth for each “post” so I can see what the request/response needs to look like for non-webservice-friendly (i.e. you have to hand-craft the XML) SOAP clients.  Anyway, if you are working with Xml Web Services on a regular basis and need a simple (and free) testing tool, this tool is definitely worth looking at.

VisualStudio.Net.2005.Beta2(firstExperience) == Really.Good;

Wow… early this morning was the first time that I was really able to spend some time with the new Visual Studio 2005 beta… and let me join the majority of the blogsphere in saying that I’m quite impressed.  My task today was a simple one… that of converting a primarily content-focused website that I had build using Dreamweaver MX to ASP.NET 2.0.  The following are some general impressions…

1. Vault and the beta work great together…. We are actually running an older version of Vault (2.06) yet it still connected up and worked like a champ… in fact, I was amazed at how fast the source control operations (checkin/out) were compared to RTM version of VS 2003 and the same Vault environment… a very nice start…

2. Project-less websites are great … no more adding files to the solution/project… VS simply “knew” about all of the files in the directories I was working on… it is very nice.

3. Master pages “just work”… As someone who has used the templating feature in Dreamweaver, and has also built an ASP.NET master-pages “engine” (capitalizing heavily on the work of Rob Howard and team, supplemented by Paul Wilson) I wasn’t “amazed” by the master pages feature… I just wanted it to work better/faster than my current tools and hopefully have a better implementation.  I was not disappointed… the Master Pages support was easy, and quick to utilize…. now if only they could get nested master pages to work in the designer…

4. XHTML compliance… finally… Some people probably don’t care so much about standards compliance, but I’ve been working pretty hard lately on some of these sites to make them XHTML compliant… this site in particular had been compliant until I added some ASP.NET controls (text boxes, buttons, validators, etc.).  I moved things over this morning, fired up the page, ran the W3C validator (thanks to the Checky extension for FireFox) and it validated (XHTML Strict) on the first run… very impressive

5. System.Web.Mail is deprecated… most of you all probably knew this already… and yes, I probably have had my head in the sand, but I was surprised when the compiler griped at me this morning about my form that sends mail based on user input… I took some time and without too much work was able to get the form processing code using the System.Net.Mail namespace which seems to be the new “right” way to do it… works like a champ.

I’m very excited… don’t have time to talk about the built-in webserver, or direct FTP support… which is great….  I’ll post more later.