Long running web services (.Net WS)

I have some web services that I know are going to take some time to run. They are going to do a lot of stuff so the default timeouts don't apply here. Well, it's actually quite easy to do. First, don't forget to call your web services asynchronously using the provided proxy methods. Then in the web service proxy I affect the Timeout property and set the number of milliseconds I want the timeout to be. You can set -1 for infinite but I wouldn't advise this. Test your server and come up with an expected maximum and add some padding.

On the server side, the default is 110 seconds. By following the provided link, you'll see have to change this setting by adding a line into your Web.Config. Unfortunately you can't set a different timeout for each web method and it will be applied globally to your web service project.

Some help related to the configuration setting: http://msdn2.microsoft.com/en-us/library/e1f13641.aspx

Visual Studio 2008 RTM on MSDN!

Well, as suggested by Microsoft, Visual Studio 2008 is RTM today. So all of you with MSDN accounts can go and fetch it.

Speaking of MSDN downloads, expect a totally new look sometime next year. I got to see a prototype during TechEd 2007 and I must say it's much, much, much more friendly then today's version. Searching for downloads should provide more pertinent results and you will no longer need to navigate down deep hierarchies in a tree stuck in a small panel. The downloads tree will have something like two levels maximum. Plus RSS feeds will make an appearance so you wont need to hammer that page until you're favorite RTM comes around. Good stuff.

.Net Configuration & Group Policies

I have a .Net smart-client deployed in several countries and I want to change a value in the configuration file. One way I could do it would be by publishing an updated version with the configuration changes using ClickOnce but that's a bit overkill and risky to release a new version each time a configuration value changes. I could also imagine some fancy ways to get the value from a web service but if I'm getting info like the base web service URL from configuration, I'd fall in a chicken before egg dilemma.

A better alternative, when working in a single domain, is to use Group Policies (GPO). I've modified my smart-client to read from the registry the key corresponding to the GPO. That may sound old-school and with the coming of .Net we've been preached (a lot and rightly so) not to use the registry anymore and that ".config" files where the right way to do things.

Actually, using GPOs doesn't change the way we do things in .Net. It's still a great practice to save user settings in the ".config" files. But when you're managing an application distributed across geographically distributed domain and you feel that some specific settings could change, consider reading the setting from a GPO registry entry. That way before deploying your GPO-aware application, you can ask your friendly IT administrator to create a new GPO for you with your initial value, deploy your application. And when it's time to change the value, just open a ticket/email/call/wake up your IT dude and ask him to change the value.

I've found a good article on implementing GPO aware application on DevX: ASP.NET Configuration and Group Policy, Part 2: Creating and Using Group Policy-Aware Providers. Don't be put away from the title, it talks about ASP.Net but the basic idea works just fine in other type of applications. You also don't need to create a configuration provider and just write some code that fetches the registry value but that's up to you to choose.

Dynamically changing URL of a WCF proxy

A couple of weeks ago I was creating a WPF/WCF version of a very simple little application I've made that checks if all my production web services are running correctly. It's really simple, using an existing web service it retrieves the URI of all the current production services, then iterates them and calls a web service method that either returns True is the service has access to the database and all, or False if it doesn't. The little application shows the list of services with a little flag for each. The flag is green if the web service call went well and returned True, red if either the call failed ("hay caramba, time to check IIS!"), or orange if the call is pending.
Simple but very useful when the production server was going bonkers a couple of months ago.

In the old days of .Net 2.0, to change the URI of a web service proxy, you just set the "Url" property, re-set the credentials if you use them and call the method. Now with WCF, I have defined all the bindings in my configuration file, in the SOAP client's EndPoint I set the "Address" property with the URI of my server and I'm done! I don't even need to re-set the credentials that .Net 2.0 used to "forget" when I changed the URL of the proxy.

MyServiceSoapClient securitySoapClient = new MyServiceSoapClient();
for(int i=0; i<list.Count; i++)
{
mySoapClient.Endpoint.Address = new EndpointAddress(myServiceUri[list[i].Uri]);
//Call the service here
}

LINQ to SQL and Entity Model: separated at birth? Part 2

My second question to the ADO/LINQ/C# panel was "Why is there LINQ to Entity Model queries and eSQL queries?". Before I go into the answer, let me introduce eSQL to those that, like I, didn't know about it. First, it is not Embedded SQL. What eSQL is in the Entity Model context, is a very SQL-like query language that you can use to manipulate Entity Model well, eh, entities. Just like the not-so-good old days before LINQ, eSQL queries are stored in strings and should allow you to do most stuff you do in SQL. The big difference is that instead of querying real SQL tables, you query your Entity Model objects.

The answer the panel gave was that, despite the fact that you can dynamically generate LINQ using expression trees, it is a lot easier to generate a SQL-like query in a string, just like we have done for eons with real SQL. So you can use LINQ to Entities for your static, in-code queries, and eSQL for dynamically generated queries. All that sounds good to me.

eSQL aims to have as many of the T-SQL features as possible so we don't feel out of place when generating those complex queries.

LINQ to SQL and Entity Model: separated at birth? Part 1

I've been hearing and reading about LINQ to SQL from some time now. Last year at TechEd 2006 something called Entity Models was hinted at and a CTP came out spring 2007. The promises are the same: you extract from your database a object model that you can modify and voilà, you have a data/business layer for your project.

Until recently I must have got things mixed up in my mind because I was thinking that Microsoft was going to make it's entry in .Net ORM with a new product. Instead I discover they are making their entry with two products. So we have LINQ to SQL coming with Visual Studio 2008 and ADO.Net Entity Model coming sometime Q1 2008, probably coinciding with the release of MS SQL Server 2008.

Oh, and to give it a real twist, you can do LINQ to Entities to do LINQ-style queries on Entity Model objects. Well, this at least proves that LINQ itsefl is getting some serious backing, the question will be whether LINQ to SQL will get such good backing when Entity Model comes out.

Life is all about choices and I like to have alternatives but there I was in Barcelona looking at very cool demos of Entity Model and LINQ to SQL and wondering if in some schizophrenic episode someone at Microsoft decided to do the same thing, twice... and differently!

So I decide to follow the sessions that discuss these things and the perfect occasion shows up: a "Interactive Session" very aptly titled LINQ to "X", ADO.Net Entity Model Framework, DataSets & Co - What is it with all these Data Access Technologies?. Kudos to Microsoft for such a daring title and putting such a great panel of experts.

The session started by explaining the two cheats of papers that where left on each seat. So, we get paper to write down our questions and send them to the panel for answering. With a grim I immediately start witting down two questions:

1. Why are there both LINQ to SQL and Entity Model?
2. Why is there LINQ to Entity Model queries and eSQL queries?

When this questions made their way to the panel, the first one was introduced as "the million dollar question". Paraphrasing Luca Bolognese's answer, and as I was starting to suspect, LINQ to SQL is to be a RAD oriented tool. It'll let you quickly build up a data layer for non-industrial applications in a similar way then DataSets do today. With the big advantage of letting you do that without a single line of SQL if desired/necessary.

On the other hand, Entity Model is going to be LINQ to SQL's bigger, more mature brother. Capable of more complex mappings (like several tables mapped to a single object) and better customization.

Back from TechEd 2007

Just got back from TechEd 2007 last night. One week of brain cramming with all the "what's next" from Microsoft. It aches but it's good. No pain no gain they say. I have to say that compared to TechEd 2006, things are even better this year. Less consultants doing the talks and more people from Microsoft. The same guys managing the teams working on C#, ADO.Net. Now that's what I call "from the horse's mouth"!

I specially enjoyed (more like abused) the "Ask the experts" part of the conference. I had a lot of questions about Microsoft's future entries in ORM solutions for .Net and the more I learned, the more I asked. I'll talk more about that some other time.

Now, the question I've been evading to answer, why I blog? Well, I can no longer keep count of how many times some post or blog or code sample on some site saved me from certain death so maybe it's time for me to reverse my "I'm never getting a blog" position and try miserably to give something back. Well, good luck to me.

I'll post more post-TechEd 2007 info soon. In the meanwhile, expect Visual Studio 2008 RTM for around November 19th 2007 on MSDN.