July 2004 - Posts

Shared Memory Provider and Async Commands
22 July 04 12:13 PM | despos | 7 comment(s)

The following rather trivial piece of code may not work in .NET 2.0 Beta 1.

string cnStr = "Async=true;SERVER=(local);DATABASE=northwind;UID=...;";
SqlConnection conn = new SqlConnection(cnStr);
SqlCommand cmd = new SqlCommand("SELECT * FROM employees", conn);
conn.Open();

The error message you get looks like this. Shared Memory Provider: Asynchronous Operations Not Supported.

Looking at the stack trace, the error occurs within the Open method of the SqlConnection class.  This typically happens if you're using SQL Server 2000 or 7.0 in the same box as the code. In this case, the connection is made using shared memory. Now ADO.NET 2.0 doesn't support async commands over shared memory for pre-Yukon servers.

An easy way to work around this is to force TCP instead of shared memory. You can do that by prefixing tcp: to the server name in the connection string. In alternative, use localhost.

Why is it so? In SQL Server 2005, the shared memory provider has been redesigned to use a simpler shared-memory transfer protocol with queuing. Also, in Whidbey a new network layer, called SNI (Sql Network Interface) replaces the good old NETLIB. A large part of the asynchronous commands implementation relies on SNI. Now consider the following:

• SNI doesn't support the old shared-memory protocol used by SQL Server 2000 and earlier. For this reason, NETLIB is loaded to talk to these servers. 
• NETLIB doesn't know anything about async commands

As a result, async commands can't go over shared memory as long as SQL Server 2000 (local) is involved. Forcing TCP does work instead.

PS: Credits go to Pablo Castro for sharing this information.

Whidbey Watcher Here
19 July 04 07:01 PM | despos | 3 comment(s)

Want to know what's hot with Whidbey Beta 1 but have no time to spend checking out my articles? <grin>

OK, try this: the Whidbey Watcher free newsletter. Next stop: what's new in VB.NET by Francesco Balena.

PS: Italians can check it out in their native language on the Code Architects Web site.

Foil spam-bot software
19 July 04 06:57 PM | despos | 1 comment(s)

SafeMailLink is a free HttpModule -- written by Marco Bellinaso -- that encodes the mailto: links found on the HTML generated by ASP.NET pages, to prevent the action of SPAM-bot software. Links with parameters that pre-fill the mail's subject and body fields are also supported and encoded correctly. E-mail addresses used as text for the e-mail hyperlink are protected as well. Click here to download the full C# source code, together with a test page and configuration file. 

Whidbey (Web) object browser
19 July 04 06:42 PM | despos | 1 comment(s)

Just a few lines to let you know about an online tool that I think you'll find interesting: DotNetBrowser. The author is my friend Francesco Balena (no blog--shame on him).

Francesco wrote the tool for his own use, then he realized that it would have been useful to others; so he made an ASP.NET version. (What a sweet and noble heart ...)
 
In a nutshell, it is an object browser for .NET 2.0 that is also able to highlight all the types/members/attributes that have been added, removed, or changed since version 1.1. All its pages can be bookmarked, so you can easily point to them from inside your articles, blog, etc. You can even make some sophisticated searches that can't be done with the VS.NET browser. For example, click here to see all the 743 items that are marked with the Obsolete attribute in .NET 2.0 Beta 1. The URL you clicked looks like the following:

http://www.dotnet2themax.com/DotNetBrowser/SearchType.aspx?asm=mscorlib&ns=System&type=ObsoleteAttribute&progress=0&search=3

We will be happy to get comments and suggestions ... 

You can call it remoting... :-)
14 July 04 08:08 PM | despos | 3 comment(s)

You can say I'm old-fashioned and even outdated but still it's hard for me to figure out what is, and how it works, the so-called virtual, Internet-based sex. That's enough. Now I know it and I've got the big picture at least. Get one of these devices and, most important, make sure you read the FAQ. The FAQ is a required reading...

Murphy's Web Services Law
13 July 04 05:20 PM | despos | with no comments

Yesterday during a class I was introducing WSE 2.0 and talking about the importance of WS-* specs for Web services development. A student asked to exemplify why WSE 2.0 should be used, or at least considered for use.

 

I had no next slide with the answer written. So I had to improvise (or just answer <g>). It said it straight off and probably started a new thread in the never-ending saga of Murphy's laws. 

 

If a task can be accomplished in two ways, be sure that two developers will implement it in two different ways.

 

What's that? It is the first law of Web services and explains why WS-* are important today.

 

 

 

Control State (finally loaded)
12 July 04 08:04 PM | despos | with no comments

You see that summer time is here not from the outdoor temperature (pleasantly fresh these days here), but from the silly mistakes one (me, actually) makes while programming... Just the mistakes that another one (my wife, actually) would say due to the (too) hot weather.

What did I do?

I was trying to implement control state for ASP.NET 1.x controls. Fritz Onion blogs about control state here and he does it better than I did myself here. I wrote a new TextBox control to see if there was a way to persist properties like ReadOnly and BackColor even when the viewstate for the page (or the TextBox itself) is disabled.

• I created a couple of protected methods and named them LoadMyControlState and SaveMyControlState. (Similar methods exist in 2.0.)
• The former retrieves the contents of a custom hidden field named CONTROLSTATE, parses it and maps values to the aforementioned properties
• The latter compacts the properties into an array of objects and serializes that to a string. The string is then stored in the custom CONTROLSTATE hidden field.

The infrastructure is ready but I need a couple of entry-points to make sure that the methods above are called. Here's when the temperature gets important... I thought that there was no better place to call methods than overridden versions of LoadViewState and SaveViewState. So I did and start testing the sample app.  

No way my control state handlers were called. Why?

If the viewstate is disabled (obvious test scenario), how can LoadViewState and SaveViewState be actually invoked? They are invoked anyway in ASP.NET 2.0, but because the ASP.NET 2.0 infrastructure is modified in light of control state support.

So I modified the TextBox so that LoadMyControlState is called from within OnLoad and SaveMyControlState care of OnPreRender.

It works like a champ. Now.

TechEd Europe Summary
02 July 04 10:21 AM | despos | 5 comment(s)

Yesterday I gave my two presentations here at TechEd Europe: one to overview the new features of ADO.NET 2.0 and one to show what can become of your (badly written) Web app if only a hacker hangs out around it.

Overall, I've got good scores above the average and want to thank all of the attendees who listen here. Particularly those from the Czech Rep needing some special type of comfort after the yesterday's game. Congrats instead go to TechEd attendees from Portugal and Greece. Football-wise these two countries represent a pleasant blast of fresh air. May the best win Sunday!

Back to ADO.NET 2.0, I've seen that some attendees (close to 1,000--unbeliavable) complained about the rhythm of the presentation that they judged way too slow. In particular, some of them pointed out that I spent too much time speaking of just ONE feature--the new DataSet's capability of native binary serialization.

My (strictly) personal opinion is that DataSet's binary serialization is THE feature, as long as ADO.NET 2.0 is concerned. All in all, ADO.NET 2.0 doesn't have a huge amount of changes to showcase. Sizeable batch update, factory model for providers, even the integration with SQL Server 2005 pale out (again, strictly personal opinion) compared to importance of binary serialization of DataSets. Why?

Because binary serialization of DataSets impacts thousands of existing enterprise multi-tier apps that use .NET Remoting to move data across the tiers in a disconnected manner. Let me write it out more clearly.

If you follow the best and most recommended MS practices for building effective .NET-based distributed apps, you use the DataSet to move data across tiers and Remoting to get the best of performance. If you do so, though, you bump into the limitation (to say the least... are perhaps bug or design flaw better terms?) of 1.x DataSets. They always serialize to XML diffgrams thus raising the amount of required memory, CPU, bandwidth by 10 or more times.

A blonde, nice and gentle attendee from Germany confessed she had a hard time last year figuring out what was wrong in her app and resorted to network sniffers to pinpoint the problem--DataSet serialization. As Rod Stewart was used to sing, blondes have (always?) more fun...

The chart above illustrates the end-to-end speed of a remoted DataSet as the number of involved rows grows. The yellow series (almost flat) is the performance of DataSets optimized as in version 2.0. The pink series shows the performance of DataSets in version 1.x. When the number of rows exceeds a certain threshold (1,000 records) the difference gets remarkable to become intolerable beyond 10,000 rows. (Just the size of real-world projects...)

Compared to this, even the SqlDependency class that gets you notifications of database changes that affect the results of a query command you run previously, is a sort of child's toy.

Comments?

PS: Credits go to Corrado Cavalli for the pictures.