Running ASP.NET applications of various versions side-by-side
Some annoying problem I've encountered lately.
While developing on my XP machine, I have had some ASP.NET 1.1 applications and ASP.NET 2.0 applications running side-by-side, as virtual directories on the single website allowed by IIS5.1
When I've published an ASP.NET 2.0 application to a production server, running IIS6.0 (on Windows 2003 Server) with already installed ASP.NET 1.1 applications, I've found out that if the old applications are running, the new one returns "Server Application Unavailable", and vice versa.
A quick search in the Event Viewer revealed that IIS isn't fond of running applications of different ,NET runtime version, in the same process. Quite reasonable that is, yet annoying.
That's when I remembered that I've always said to myself that I should look into the reason that IIS5.0 and IIS5.1 runs each ASP.NET application in a aspnet_wp.exe worker process, while IIS6.0 uses a single w3wp.exe worker process.
A little web search and I've found this: http://technet2.microsoft.com/WindowsServer/en/Library/d0a61f24-942e-4379-adad-8232be03441c1033.mspx, and adjacent pages.
So this is a new feature of ASP.NET, that makes it possible to run a few applications in the same process. Every few applications (virtual directories) are assigned to an application pool, and each application pool runs in its own process.
There are a few settings that can be done for each application pool. Those settings are overriding the defaults in the machine.config file.
Adding an application pool is done through inetmgr.msc, by just adding a new pool to the Application Pools section. Use the option to copy settings from the default application pool, so you'd have a decent place to start from:
Assigning a pool to an application is done through the main property page of the application's virtual directory:
The solution to our problem is now obvious:
When configuring a new IIS6.0 server, we will start with an application pool for each ASP.NET version we're using (1.0, 1.1, 2.0), and any virtual directory we setup in the server will be configured to be part of the corresponding application pool. Now the applications can coexist and run together.
Enough with server configuration stuff. Now go back to coding.
Ken.
Understanding the Box Model of html elements
It's our furtune that most our clients are in Israel, where everyone uses IE, but the increasing use of FireFox, and the upcoming clients who needs an overseas working solutions, are leading me into finding best practices for cross-browser, same looking web pages design.
I'll target the most widely used (or talked about) browsers at Israel: Internet Explorer 6.0 (IE), and FireFox 1.5 (FF)
So here is a little example.
Look at the following html page:
<html>
<head>
<style type="text/css">
<!--
div
{
width: 100px;
height: 100px;
background-color: aquamarine;
border: 10px black solid;
}
#div1
{
padding: 10px 10px 10px 10px;
}
#div2
{
margin: 10px 10px 10px 10px;
}
#div3
{
border-width: 0px;
}
-->
</style>
</head>
<body>
<div id="div1">div1</div>
<div id="div2">div2</div>
<div id="div3">div3</div>
</body>
</html>
This page is sopposed to render 3 100*100 divs, the first with a 10px padding (distance between border and inner content), and the second with a 10px margin (distance between the border and other elements). The third div has no margin, no padding and no border, and is used for comparing with the first two, showing what a 100*100 sized div should look like.
Amazingly, IE and FF will render it differently:
Let's see what is the difference:
The simple 100*100 div (div3) was rendered the same on both browsers, except the default font.
In the bordered and margined div (div2) things are different:
in IE, the border is renderd in the div, so the div with the border is still 100px wide. the inner content is now only 80*80
in FF, the border is rendered outside of the div, so now the div (including the border) is 120px wide, and the inner content is still 100*100
the margin magic is done the same. it is rendering a 10px unseen border around the div, in both browsers.
Finally: the bordered and padded div (div2).
in IE, the padding space is, again (as with the border), renderd in the div, between the border and the inner content, so the div with the border and padding is still 100px wide, and the inner content is now only 60*60 !!!
in FF, the padding space is rendered outside of the inner content, so now the div (including the border and padding) is 140px wide, and the inner content is still 100*100
The IE approach is better for ppl who want to change the border and padding of elements without changing the overall page layout, while the FF approach is better for ppl who thing than the inner content of elements is too important to be covered by borders and padding space ...
which is better? let's ask the W3C.
The answer is given at http://www.w3.org/TR/CSS21/box.html, and the following diagram of a html element edges is taken from there:
as well as the next quote from just beneath the diagram:
content edge or inner edge
The content edge surrounds the rectangle given by the width and height of the box ...
That leads to the thought that it's resonable that future releases of IE will do the same as FF do now.
But what about today? how do we design in the W3C way, and making the IE understand it the way we want it to?
Well, IE can undertand pages as it's supposed to, if we'd only tell him to.
Doctyping the listed page, eiether as HTML4.01 or XHTML1.0, tells IE how to render the page, and then the expected behaviour is achieved.
HTML4.01 doctype: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
XHTML1.0 doctype: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
For those of us using Visual Studio .NET to generate webforms and webpages, the IDE is generating those doctypes for any new item. VS2003 uses HTML4.01, while VS2005 uses XHTML1.0
But there is still a need to do that manually, when you render a page manually, say using a xslt transform from xml resource.
I'd recommend using XHTML1.0 transitional as a mininum doctype, and doing your best to make your pages compliant with this standard. It's making your page look and behaviour much more expected and keeps you from angry clients with a specific browser version. It is also a best practice to program well. Web programming is is the same as any other, and the fact that browsers allow us to make mistakes doesn't mean that we have to. Imagine VB programmers using only Variant type variables - they'd probably get throwen off the nearest window during code-reviews ...
It's true that sometimes we have to make an exception and do some browser specific stuff in order to make things work, and that is exactly a perfect time for some inline remark to explain the reason for doing that. It is also true that ASP.NET 2.0 itself isn't as XHTML complaiant as it claims, but then again - we'll do our best to program well and to deliver quality and complaiant code, if only for the sake of doing things right.
be good, and remember: Winning is the science of being prepared.
Ken
Debug vs Release - Unabridged
In a lecture I've recently gave in our company, I've discussed about the differences between Debug and Release builds, and ways to change the standard VS.NET configurations to better suit our build needs.
I'll post the important stuff here during the next few days, including some links, diagrams and other things that will make the things as clearer as can be.
Please visit here again in the next days to see the post, and comment me for any mistakes I may have, or any other suggestions in that area.
Crash all the bugs (was that your auntie?)
Packing custom controls the right way - single or multiple assemblies?
We're developing a new web application at our department with rich client interface, and as part of the process we need to develop a few UI custom controls, that can and will be reusable in future projects.
I am indecision about two approaches:
1. Packing all the UI web controls into a single assembly (let's say SQLink.Web.UI), as MS did with their System.Web (which include all the UI namespaces, and all other web namespaces, too), and also with the Microsoft.Web.UI.WebControls.dll
2. Pack every single control into a different assembly.
Why 1? it's somewhat easier to maintain (a single project on VSS), it's following the path of MS (this isn't always the best thing to do, but it often is), and it's easier to deploy.
Why 2? (a) It's easier for two developers to work on different controls without "fighting" over source control privileges, and (b) if the assembly holds valuable controls not needed to a specific application, and the application is handed to a client who isn't licensed to use those controls, he still can lay his hands on it if we had packed all our controls into a single dll.
After consultation with my colleague Oren Ellenbogen, we came to conclusion that approach 1 is better, and that the downsides of it can be solved by (a) working properly (by means of not allowing the developers to keep project wide objects checked-out), and (b) relying on the legal discipline of our clients, not to use our application dlls in their or in third party solutions, without our explicit permission.
back to coding ...
Subscribe
Statistics
283
440
Tags
activerecord(23)
alt-net-israel(2)
Alt.NET UK(5)
architecture(19)
asp.net 2.0(29)
asp.net ajax(9)
aspview(60)
blog engine(16)
castle(81)
client-side(28)
c#(26)
css(8)
debugging(2)
hql(3)
html(14)
Javascript(1)
linq(5)
miscellanea(62)
monorail(72)
nhibernate(10)
personal(27)
Source Control(3)
SQL Server(10)
Testing(2)
tools(45)
visual sourcesafe(1)
visual studio(24)
visual studio 2005(12)
winfx(3)
Archive
Jul, 2008 (11)
Jun, 2008 (11)
May, 2008 (8)
Apr, 2008 (11)
Mar, 2008 (8)
Feb, 2008 (11)
Jan, 2008 (14)
Dec, 2007 (16)
Nov, 2007 (15)
Oct, 2007 (22)
Sep, 2007 (11)
Aug, 2007 (14)
Jul, 2007 (11)
Jun, 2007 (12)
May, 2007 (22)
Apr, 2007 (2)
Mar, 2007 (4)
Feb, 2007 (6)
Jan, 2007 (6)
Dec, 2006 (3)
Nov, 2006 (9)
Oct, 2006 (14)
Sep, 2006 (11)
Aug, 2006 (9)
Jul, 2006 (5)
Jun, 2006 (4)
May, 2006 (6)
Feb, 2006 (4)
Jan, 2006 (3)
Blogroll
.net and other musings
Adam Esterline
Ayende@Rahien
Brad Abrams
DamienG
David Hayden
DHH
Dror Engel (Hebrew)
Eleutian (MonoRail)
Eran Nachum
Gray's Matter
Hamilton Verissimo (Castle)
HUMAN-DEBUGGER.NET
Indie (Music, Hebrew)
Joel on Software
joeyDotNet
Jon Galloway
Justin Angel (Hebrew)
Morts Like Us
Nikhil Kothari
Oren Ellenbogen
Roy Osherove
Scott Guthrie
Scott Hanselman
Software Is Hardwork
Steve Yegge
the 'bee log
Tom Opgenorth
Udi Dahan
Yosi Taguri (Hebrew)
Related Books
Related Jobs
Related Ads