Marius Gheorghe

Building software : make it work, make it good, make it fast

RewritePath issue on ASP.NET 4

  Ported a app from ASP.NET 2 and 4 and had a interesting issue with HttpContext.RewritePath.  Basically I was doing url rewriting using to ashx handler to get nice urls on 2. When I moved the app to 4 all postbacks on pages with rewritten url were broken (even if I was running the app with the backward compatible settings).

Found a workaround (not perfect but it gets he job done). Basically RewritePath has a parameter called “rebaseClientPath” which “updates” the path after url change. This rebase doesn’t seem to work anymore on ASP.NET 4 so make sure it set the param value to false.

Hope this helps someone.

Prevent web.config inheritance

As you probably know by default web.config inheritance is on. This can create problems even in very simple situations (for instance registering the same user control in both applications). To disable inheritance just modify the root web.config file like this :

<location path="." inheritInChildApplications="false">



Use Telerik/Infragistrics over build in controls

Jeffrey Palermo has the following gem :" use Infragistics/Telerik over in-the-box controls" .
I strongly disagree. 3rd party controls are usually awful...they spit our crappy large html and javascript which doesn't work on all browsers. Better stick with the default ones (not that they are perfect but they suck less). I had once made a test with a tab control : a "hand made" tab control (html and css) placed on a empty aspx page resulted in a 3kb html. Same thing with a Telerik tab control resulted in a whooping 12kb.
The idea is that if you can accomplish something with a HTML control then DO IT. Use server side controls only when you absolutely need them.

Nasty bug in Server.Transfer

I was working on a URL rewriter (implemented as a IHttpHandler) and i stumbled on a nasty bug in the runtime. After you Server.Transfer, in the resulting page you can't access the session anymore (HttpContext.Current.Session is always null). That pretty much makes Server.Transfer worthless.


Web services woes

Yikes. I discovered (the hard, lots of swearing way) 2 awkward things related to web services usage:

- the first occurs when you must include a certain type that can be return from WebService (most common example is DBNull). Although the documentation say to use SoapInclude it doesn't work. Use XmlInclude instead.

- the second one is related to the use of custom SoapHeader. I was using a custom SopaHeader for authentification (no WSE for me thank you very much). The problem was that the public instance of the SoapHeader always had the properties null. Checked the types, check the names, look on sample on the net. I couldn't discover any problem with my code. Double check everything. Triple checked everything. Until i small detail caught my eye : as a good old 'listen to Microsoft coding guidelines' kind of guy i was using properties instead of public fields. All the samples were using public fields.....changed to fields worked. There are , of course, 2 problems : this proves, once again if ti was necessary, that it's REALLY stupid that the reflection API makes a difference, API wise, between and fields and properties. And that the guy who wrote that code was lazy.

I'm posting this hoping that might help somebody who will find itself in my situation.

Skinning : ASP.NET skins vs CSS

There's seems to be a little misunderstaning between ASP.NET developers on what to use for skinning : ASP.NET skins or CSS ? The answer is, of course, both. That's because each each of them is good at it's own thing. ASP.NET can be used to give the same look to server side controls while CSS is used for the rest of the design.

Here's a simple, yet very effective, tip for integrating these 2. Create a theme (let's call it "spring") and inside the folder create a CSS file with the same name as the theme (spring.css). Now if the theme is associated with the site pages (you can do that from we.config) the spring.css is applied automatically without referencing it from the master page.

IronPython and ASP.NET

There is a CTP for IronPython integration with ASP.NET (see here). I have been playing with it since last week and i think it's really really great. Although the CTP is not really for production use yet, i can finally ditch the inadequate C# language for web development and go with a interpreted language instead( here's hope that the new compilation model will enable other languages like Boo or L# to follow). Once this is out of CTP stages i'll switch. Good time ahead.

Web application projects versus Web sites

I have been working lately on a few ASP.NET projects and on one of them i'm stuck with the default Web Site model. When VS.NET 2005 was in beta i had high hopes for this model, the ability to compile only parts of the site seemed the missing link that will allow a ASP.NET programmer to work in more "agile" manner. (and yes....i still think strong typed compiled languages are bad for web development).
Unfortunately it doesn't really work because you forced to do things in a certain way now (put shared code in App_Code folder and so on). So the fact that you can compile individual pages separately in the "Web site" model is negated by the fact that compiling a page actually compiles half of the project (your page has references to App_Code files which have references to other parts of the code on so on). So ....honestly i can't recommend the "Web site" model.
The alternative is, of course, the "Web Application" project model (which will also be a part of VS.NET 2005 SP1) which is the "old" VS.NET 2003 project model. To work in a more "effective" way with this i have a small tip: try to move as much as possible from your code into libraries. Ideally you should have only aspx pages into the web project. That would both compile the project and allow you to make changes faster. The Web application project addin van be downloaded from here.


WTF moment in ASP.NET

  I was working in the weekend to localize a ASP.NET site and i experienced a WTF moment. I had a simple inline code block: BoundField bf = (BoundField) this.gridView.Columns[0]; bf.HeaderText = ..........; this.labelX.Text = .........;
The grid view stuff is executed (no exception) but doesn't seem to have any effect. But if i move the code into the code behind file (in the Page_Load event) the code simply works. The label code is ok no matter where you put it.
So WTF ?Before you point execution order....Page_Load is executed before the code blocks.

Use the VS.NET designer for ASP.NET ?

No way. With each iteration of VS.NET it seams that the gap between the VS.NET Windows Forms designer and ASP.NET designer is increasing. While the Windows Forms designer is a pleasure to use i can't really say the same thing about the slow and buggy Web designer. The fastest way to churn out markup code is still by hand. I'm personally not really affected by this but it's still a striking difference to switch between them. long as i'm here i was thinking to write about a feature i would like to see in VS.NET someday. For instance...if we have this :

ID="textBoxNumber" runat="server" CssClass="myClass"

it would be really nice to have a "Go to class" command that would go to the CSS class definition if the referenced CSS file is part of my solution.
On the bright least the Web designer does not overwrites out code anymore.:D

User controls vs web controls

" Most people i have worked with tend to think that you should write only web controls because they can be compiled in a dll and thus more """"reusable"""". I'm on the other side. If you sell controls it's natural that you should packaged them in a dll. Not so with """"in house"""" build controls. I think it's perfectly ok to create user controls and use them across multiple projects. There's a big time difference between building user controls and composite/web controls due to the presence of designer in the user control case. Instead of debuggin web controls you can easily write a user control and spend the remaining time improving the application itself.


Type.GetType in ASP.NET

  It doesn’t work with the new ASP.NET compilation model (although it might work with Web Application projects). You must use

System.Web.Compilation.BuildManager.GetType() instead.


Now playing: Cruachan - The Butterfly

ASP.NET HttpModules paper

   I wrote a paper about extending the ASP.NET processing pipeline using HttpModules. You can read it here. The SessionCleaner module presented in the paper is part

of a nifty library of http modules i wrote and which i intend to open source soon.

ClickOnce - death of ASP.NET applications ?

At least ASP.NET applications for the intranet. I confess that i worked
on both Windows Forms and ASP.NET apps. As a user(and also as a programmer)
i prefer the first ones.The usability of the ASP.NET gives a lot to be desired.
The are slow and cluncky.I would choose a normal Windows Application over the
ASP.NET equivalent any time.
  In the intranet scenarios the only advantage of the ASP.NET apps is the deployment.
Deploy on server and forget about it. Update on server and everyone has the latest version.
Not so with Windows apps. It looks like ClickOnce is set to change some of that. I am
saying "some" because i'm not sure that ClickOnce will work in complex deploying
scenarios (for instance installing COM+ applications, adding assemblies to GAC etc).
The only demonstrations for ClickOnce i've seen were some "dinky single window form
app" on Channel9. Btw MS guys, when you do demos, it will give you a WAY better credibility
if you demo with more "Real life" apps instead of toys.
  So, it seems that with .NET 2.0, we will be able to deploy/update Windows Forms apps as
easy/fast as ASP.NET. Will this be the death of ASP.NET apps for intranet ?

I certainly hope so.