Saturday, July 4, 2009

WPF vs Silverlight

Not too while ago, writing a web application meant you compromised yourself with all “the goods and bads” of a web environment. The same goes when writing a desktop application. The gap was quite obvious (it still is...).

Nowadays, WPF and Silverlight have narrowed that gap and the similarities between a web application and a desktop application are increasing. But writing a desktop application using WPF doesn’t mean you have a Silverlight web application. Despite the fact that “both are XAML based platforms, there are some important functionality and implementation differences between the two”. Having this in mind, Microsoft has asked Wintellect to write a white paper about the differences between these two technologies.

It’s interesting, here is the link:

And here’s the Wintellect post on this issue: John Robbins@Wintellect

Thursday, April 2, 2009

Binding - "The devil is in the detail"

Binding is a powerful mechanism in the .NET Framework. Quoting Chris Anderson, "Binding establishes a relationship between a source and a target. In the case of object binding, the selected item for the source is determined by a property path". To bind data to CLR objects we use properties (simple CLR properties and Dependency Property-based properties).

Take a look at the following example:

(click to enlarge)

In the above example I'm binding the Text Property of the TextBox to the Content in the Button. Now, because Text is a dependency property, the above example is the same as the following:

(click to enlarge)

Notice that I changed the path to the “class-qualified” form of the property identifier. Both the above samples will produce the same result:

However, there's actually a big difference between them. The second example will avoid using CLR reflection to resolve the name "Text" in the binding expression because there's a “class-qualified” identifier. The first example does have a performance hit that can be avoided.

"The devil is in the detail."

Sunday, March 29, 2009

Workflow Foundation Bug

The first time I embraced the concept of a workflow was about 6 years ago, when designing ASM for microcontrolers (I miss working with the MCS-51). So, when the WF appeared, I was pretty enthusiastic and quickly started to study and investigate this new feature of the .NET Framework. By now, I can't hide the fact that I'm a huge fan of the WF.

But, of course, not everything is perfect and as a software product it has bugs. I came across one of them recently (related to the delay activity), here’s a little Microsoft article from the KB that describes the problem and a few other bugs.

Monday, March 23, 2009

From double to int through the heap

Twinkling through the WCF samples that Microsoft provides, I found a line of code that captured my attention. I was organizing the samples and one of them looked interesting, so I opened it and actually found a curious line. The sample is the WeaklyTypedJson (Ajax). But let me contextualize first.

Explicit cast from an object type to an integer is valid providing that the object holds an integer.

The above code, of course, implies one box and one unbox operation:

For those VB.NET users, even automatically implicit conversion is allowed when the Strict Option is set to off:

Now, when you have the code shown below, the conversion is also allowed (loosing precision):

So, if all the above statements are true, what happens to the code bellow?

At runtime, this will throw an InvalidCastException, stating that "Cannot unbox 'BoxedDouble' as an 'int'". This makes sense, because the CLR is trying to write in the stack a Double when the expected type is an Integer, and this violates one of the corner stones of the .NET framework, Type Safety. So, this takes us to the line of code that I found:

This is an operator overload to allow implicit conversion from JsonBaseType to Integer (InternalValue is of type object). The trick is actually quite nice: The unbox operation will be made using a double and then that double value type (on the stack) will be converted to an integer (loosing, of course, precision). Applying to my example:

And looking at the generated IL, we can see that there's an unbox operation and then a conversion:

This works fine, and it's actually a nice trick. I would write it, however, a little bit different:

Thursday, January 15, 2009

Export MIME Types from IIS – C#

Last month I wrote a post on how to export MIME Types from IIS. I also provided a little gadget to “do the job”. That tool was written in VBScript. However, I’ve received a couple of e-mails asking me how the same task could be accomplished using just C#. Well, it’s actually quite simple, here’s the CS file (GitHub) with the code.

You only need to add two references to the project were you add this file:
      – System.DirectoryServices;
      – Active DS IIS Namespace provider (needed in order to use the IISOle provider). This is in the COM tab on the Add Reference dialog.

That’s it. The call to the function in the CS file should look something like:

Those of you who asked for this CS file, please give some feedback. This is for .NET Framework 3.5.

Monday, January 12, 2009

SQL CLR - Assembly.Load()

The jump from SQL Server 2000 to SQL Server 2005 was huge at all levels (fortunately, I didn’t got the chance to work with previous versions of the SQL Server). One of the many features introduced with SQL Server 2005 was the SQL CLR. The idea is to allow managed code to be hosted by and executed in the Microsoft SQL Server environment.Translating, you can write your stored procedures, user defined functions, trigger and so on in any CLS compliant language and use them in any standard SQL statement as if they were created using T-SQL. You can even define new types and they will be recognized in SQL.

Now, accordingly to Microsoft, the SQL Server itself hosts the .NET Framework runtime (resources management and so on are no longer satisfied by the undererlying OS). So, one other question arises: under what security permissions does it run?

Quoting Microsoft, "The CLR supports a security model called Code Access Security (CAS) for managed code. In this model, permissions are granted to assemblies based on the identity of the code (e.g.: signed assemblies), as opposed to the identity of the user or process running the code." When moving to a CLR hosted environment however, this implies that "the ability to generate managed code dynamically is not supported inside the CLR hosted environment in SQL Server. Such code would not have the CAS permissions to run and would therefore fail at run time."

So, translating Microsofts’ fancy words: what happens when dynamically loading an assembly? Bum...
Loading an assembly — either explicitly by calling the System.Reflection.Assembly.Load() method or implicitly through the use of Reflection.Emit namespace — is not permitted. Dynamic assembly loading is always disallowed under SQL CLR, even using UNSAFE permissions. If your assembly uses any of these features, the DMBS will yield an error message when running the code:

(click to enlarge)

This isn't a big issue, though. Mainly because the Database is one of the most important components of any system and you'll want it to be as "well defined" and secure as possible.

Tuesday, January 6, 2009

The ParallelActivity

As I mentioned before, writing high-performance, multithread, extensible, expansible and scalable software is actually very challenging. Hardware improvements can be worthless unless you know how to take advantage of them.

Now, talking about multithreading, WF has a composite activity that can execute child activities in parallel (at least, in theory). The idea is that branches execute in a “parallel fashion”:

The first thing to note is that the order in which child activities execute is non-deterministic. That is, it’s not guaranteed that all the activities in the first branch get executed before the second branch gets executed. It’s not guaranteed that the WF runtime will execute the first activity of each branch, then the second and so on. The only guarantee is that a “branch switch” won’t happen until a single activity is finished (e.g.: if you have a code activity, there won’t be a “branch switch” until the thread finishes processing all the code in the activity).

“So far so good”.

Moving on, whenever we talk about “parallel execution”, we always think of execution in a multithreaded sense. This isn’t truly the case. The WF runtime uses only a single thread from the threadpool to run all the branches. This means that the parallel execution paths do not execute concurrently, and what we have here is actually cooperative multithreading. The question is: why use only one thread? I mean, why can’t we specify that one branch should run in one thread and all the others in another? Imagine that we have an activity in one of the branches that will actually take a long time, for instance, a web request?

Looking to the basics of WF, doing what I’m suggesting will actually “break” the idea of an Activity as the basic unit of work. What I’m suggesting will allow a “branch switch” in the middle of activities execution. A code activity might be interrupted due to a context switch.

I think, though, that this would be a nice feature.

Nevertheless, you can “do it yourself”: asynchronous programming model, threadpool...