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 asp.net 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.
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">
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.
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.
Anyway....as 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 side.....at least the Web designer does not overwrites out code anymore.:D
It doesn’t work with the new ASP.NET compilation model (although it might work with Web Application projects). You must use
Now playing: Cruachan - The Butterfly
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.
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.