Thursday, January 15, 2009

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

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."

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

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.

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...