This blog will be moved to Mount Gellert. Please update your favorites. The new RSS URL is RSS. Feel free to continue reading me on my new place. There the amount of technical articles will be presumably higher than now

In the forthcoming weeks I’m dealing with the 2 new branches of Mii, so don’t expect too much from me till february. Till that, there are a ton of things happening of course (final atlas, final entlib 3, etc), but don’t be afraid, I’ll be back!

I swallowed it. Probable this blog will be reorganized due to this, details will follow.

New branches of the main trunk has been released from the software ‘Mii’, named Branch A ‘Adam’ and Branch B ‘Thomas’. Feel free to poke around in the screenshot gallery!

Martin Luther King
Martin Luther King
Martin Luther King
Martin Luther King
Martin Luther King
Martin Luther King
Martin Luther King
Martin Luther King
Martin Luther King

It’s a common problem, that your viewstate is bloating up under heavy usage (complex data editing scenarios with multiple grids enabling editing, etc). ASP.Net 2.0 comes up with a handy solution for such cases by letting you easily redefine your PageStatePersister in your page with (under .NET 1.0/1.1 this could be done using  LoadPageStateFromPersistenceMedium and SavePageStateToPersistenceMedium):

    protected override PageStatePersister PageStatePersister
    {
        get
        {
            return new SessionPageStatePersister(this);
        }
    }

After changing this (and applying a custom base page for all my pages with:

(for this to work it is needed to derive all your aspx pages from that page!)

I got the result from ~3500 viewstate bytes to ~1500 viewstate bytes. But what can I do with that 1500 bytes? What is in it? I started ViewStateDecoder 2.1, and checked into it, what I saw was surprising: all usual viewstate data was wiped out, but there were still the controlstate! So it’s not the same as the PersistanceMedium calls as they were formerly… How to get rid of that 1500 byte? After using the Reflector a bit I found out, that all depends on a browser capatibility called RequiresControlStateInSession, when it’s set to true, than the controlstate is persisted into the session as well. Last question was: how to let the system know, that my browser has the RequiresControlStateInSession capatibility? It’s easy with the new syntax for browserCaps:

  <system.web>
    <browserCaps>
      <case>
        RequiresControlStateInSession=true
      </case>
    </browserCaps>
  </system.web>

And the day is saved, now I have a viewstate of a 57 bytes, which contains a pair of a boolean and an ID

For those who are living under a rock - Oracle has betad it’s new DB backend.

<system.diagnostics>
<switches>
<add name=”System.Workflow.Activities.Rules” value=”All” />
</switches>
</system.diagnostics>

• aspnet_regiis -lv Lists the different ASP.Net versions
• aspnet_regiis -lk Lists the ASP.Net versions for the directories
• aspnet_regiis -ga <user> Sets a user account to have rights for metabase and directories of ASP.Net

If you want to see design time themes in ASP.Net, add this to web.config:

<system.web>
         <pages styleSheetTheme=”Theme1″ />
<system.web>

You will be still able to set the theme by each page or in PreInit, but you will have design time theme, even for master pages. 

To make people picker pick only from existing users on the site do:

Stsadm.exe -o setproperty -url http://server -pn “peoplepicker-onlysearchwithinsitecollection” -pv yes