ASP.Net: Application Pools, Application Domains and/or processes

Hi all.

Today I just wanted to bring some light on the way ASP.Net handles requests. So let's start from scratch.

What is ASP.Net itself from OS perspective ?
ASP.Net is just a process called aspnet_wp.exe. How in that case it's stable against application crashes - read further.

In the last question we've mentioned something called Application.What is that ? Ok, Application is an atomic unit of the ASP.Net process - it's the type of the objects, which are responsible for processing client requests. But there is a good and important trick here, which ASP.Net process takes care of - the Application Domains. In fact, for each application (which is represented by a vritual directory in IIS) ASP.Net creates a separate AppDomain, and everything related to specific application happens in the boundaries of that domain. This makes one Application be resistant against others' crashes.
So for each request coming from the client, ASP.Net "creates" (I will cover this a bit later) a separate Application type instance (Application object) to handle that request. Why I've quoted the creates word, is because that's not the case and there is a nice optimization done under the hood: as soon as the application being started (AppDomain for that application being created), ASP.Net creates a pool of up to 100 instances of Application classes to not spend time on heavy object-creation operation on each request. So, finally, what we get, is that for each request a "random" existing Application instance processes that request.
This brings us to one important point: Never keep state in Application instance, or even if you need to take into account the fact that the instnace you've written some state to most probably will be chosen to process request from other clients as well.
All this is great, but seems we're missing something: where do the Application Pools stand in whole this architecture ? Ok, time to change your understanding about Application Pools, because those are just number of settings, which can be applied to different applications. Applicaiton Pools are just a conveniet way to group important settings alltogether and then be able to apply them to any application you'd like to.

I think this is all for this post.
Good luck in your development.

Better Work Environment: Bigger Screens

It's almost 5 years I used to work on two monitors, and now sometimes feel the need of the third one. Yes, it's very handy to work on several, but there is a drawback as well: you get used to it and its getting harder and harder to work on a single one at home.
Today, I had to spent some time on my WP7 game (which is in the Marketplace from february), and suddenly thought about moving from 22" Samsung (monitor) to 32" Samsung (TV). And you know what - that's amazing - clear picture, wide area to work and you can see every long line of your code (I'm not fan of splitting lines by enters).

Silverlight: Control visibility based on several properties' values

Hi there.

During last few months I've noticed that many people are struggling with problems like object visibility based on parameters.
And here I will try to make this more easy for some of them.
So, let's begin. First of all let me make a not about the IValueConverter interface, introduced in silverlight framework. That's really a very usefull contract, especially when you get used to converters. You now ask about converters ? Sure: A converter is there to help you to convert a value to match the expected result and vice-versa. That's a mechanism, which adopts the input to output, assuming that the output is fully depending on input.
So, how does it work ? Let's assume we have the following XAML:

    <TextBlock Text="Dummy text" Visibility="{Binding Path=DummyTextVisibility}" />

Most of the developers will go this way - trying to match the properties to the UI expectations. But this is NOT CORRECT ! Just think - You're trying to bend your logic to match the View ? Everywhere, in every study about UI development you read that separation is something everyone is trying to achieve (I mean presentation and logic separation). And here you try to adopt the logic based on presentation.
So which is correct ? The correct way to handle this is to not think about the presentation layer at all, when you're developing the business layer. And as soon as you think this way, you see, that it would be much natural to have something like this:

    <TextBlock Text="Dummy text" Visibility="{Binding Path=IsDummyTextVisible}" />

But wait... will this work ? Sure not, cause the Visibility property expecting something of type System.Windows.Visibility, and you've just passed in a bool.
Here the Converter comes in: it lets you to bind to anything logical, and then get what you want to get from it, so it will let us write the following, assuming that we have defined BoolToVisibilityConverter:

  <cnv:BoolToVisibilityConverter x:Key="boolToVisibility" />
   ...
   <TextBlock Text="Dummy text" Visibility="{Binding Path=IsDummyTextVisible,Converter={StaticResource boolToVisibility}}" />

We assume here also that the xmlns:cnv was imported in the root tag, and that the <cnb:BoolToVisibilityConverer ... was defined in the resources section.
And here is the code for the BoolToVisibilityConverter:

public class BoolToVisibilityConverter:IValueConverter
{
    public object Convert(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture)
    {
        try
        {
            return (bool)value ? Visibility.Visible : Visibility.Collapsed;
        }
        catch (Exception ex)
        {
            return Visibility.Collapsed;
        }
    }

    public object ConvertBack(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture)
    {
        /// some logic here if you're going to use this
    }
}

Great. Now we have everything in place except the thing, that in some cases you will need to make an object visible depending on two parameters - control is going to be visible if both those parameters are visible. Don't waste your time looking for some complex solutions, just wrap your control in a Panel control, and bind its visibility to the other parameter you'd like to:

<Grid Visibility="{Binding Path=SecondParameter, Converter={StaticResource boolToVisibility}}">
    <TextBlock Text="Dummy text" Visibility="{Binding Path=IsDummyTextVisible,Converter={StaticResource boolToVisibility}}" />
<Grid>

So, that's it. Enjoy :)