Comments (0)

Reducing the delay time upon first requests to a DotNetNuke or other ASP.NET website is something that I see asked quite often.  This delay is due to the ASP.NET Worker Process compling a website, this articles will discuss the solutions available to prevent this delay from occuring.   I personally find that the simplest solution is the best; the even better part is that it is free! First of all before I talk about the different solutions available let me first explain the issue and why it happens.

Depending on your specific setup and hosting environment this initial load time can be quite lengthy. I have noticed initial load times of anywhere from 4-5 seconds to over 25 depending on the server configuration and load. What is actually happening is that your DNN site is being compiled after the ASP.NET worker process has restarted. The worker process can restart for many reasons, however the most troubling one is due to site traffic. By default IIS will shut down the ASP.NET worker process after 20 minutes of inactivity meaning that the next request will restart the worker process and cause the compilation to occur. Read more »

Comments (0)

Web form pages are HTTP-Based, they are stateless, which means they don’t know whether the requests are all from the same client, and pages are destroyed and recreated with each round trip to the server, therefore information will be lost, therefore state management is really an issue in developing web applications

We could easily solve these problems in ASP with cookie, query string, application, session and so on. Now in ASP.NET, we still can use these functions, but they are richer and more powerful, so let’s dive into it.

Mainly there are two different ways to manage web page’s state: Client-side and Server-side. Read more »

Comments (0)

Introduction

Unless you have been living in a cave, or are way behind in your reading, you have probably read something about Web services. When you read the description of .NET Remoting it may remind you a lot of what you’re read about Web services. That is because Web services fall under the umbrella of .NET Remoting, but have a simplified programming model and are intended for a wide target audience.
Web services involve allowing applications to exchange messages in a way that is platform, object model, and programming language independent. Web services are stateless and know nothing about the client that is making the request. The clients communicate by transferring messages back and forth in a specific format known as the Simple Object Access Protocol, or SOAP.

Read more »

Comments (0)

Introduction

In IIS 7.0, you can create sites, applications, and virtual directories to share information with users over the Internet, an intranet, or an extranet. Although these concepts existed in earlier versions of IIS, several changes in IIS 7.0 affect the definition and functionality of these concepts. Most importantly, sites, applications, and virtual directories now work together in a hierarchical relationship as the basic building blocks for hosting online content and providing online services.

 This article provides a quick overview of applications in IIS 6.0 so that you can better understand the differences introduced in IIS 7.0. It then explains the concepts of sites, applications, and virtual directories in IIS 7.0 and introduces the <sites> section in configuration.

 This article contains: 

• About Sites, Applications, and Virtual Directories in IIS 6.0
• About Sites, Applications, and Virtual Directories in IIS 7.0
• Sites
• Applications
• Virtual Directories
• IIS 7.0 Configuration: <sites> Section
• Summary

Read more »

Comments (0)

People are always confused by these two IIS concepts, especially for the new IIS7/WAS. These are not new concepts. They are available since IIS6 on Windows 2003 Server. However the terms were misused in IIS6 and they are corrected in IIS7 in Windows Vista and higher versions of Windows.

Virtual Application

What is it?

The term “virtual application” is a fundamental concept for IIS and ASP.NET. Here is the definition in my own words: a virtual application is a construction unit of a web site that participates protocol listening and process management. It can be uniquely identified by its absolute virtual path from that web site. For example, you can create a virtual application with virtual path “/foo” in the “Default Web Site”. For simplicity, we also call virtual application as “Default Web Site/foo” or simply “/foo”. Every web site has at least one virtual application, a.k.a, the root virtual application “/”. Read more »

Comments (5)

what’s the deal with sites, applications, and virtual directories?
Before you can serve a single request from your IIS7 server, you need to create a set of configuration that describes how the server listens for requests, and how these requests are then dispatched to your scripts or static files.  To do this, you need to at minimum create a site, an application, a virtual directory, and an application pool, which together provide the basic configuration necessary to serve your website (to be fair, the default configuration of the server already includes a set of these that you can use right away – more on that later).

A site is the top-level logical container that specifies how http requests are received and processed – it defines a group of bindings that determine how the site listens for incoming requests, and contains the definitions of applications/virtual directories that partition the site’s url namespace for the purposes of structuring your application content.

A binding is a combination of protocol name and protocol-specific binding information.  While IIS7  supports multi-protocol bindings (WCF’s soap-tcp, FTP, etc), we will focus on the http path only here.  So, for our purposes an http binding effectively defines an http endpoint that listens on:

• A specific interface ip address (or all interfaces)
• A specific port number
• A specific http host header (or all host headers)

This way, you can configure many sites on your server that listen on different ip addresses, different ports, or on the same ip address / port but with different host headers. 

It’s important to note that the url of the request has no part in determining which site the request is routed to – only the bindings do.  All requests received on a binding are sent to the site that owns the binding, so effectively each site owns its own full url namespace starting with “/”. 
This url namespace is then partitioned further into applications, and then further yet by virtual directories.

An application is a logical container of your website’s functionality, allowing you to divide your site’s url namespace into separate parts and control the runtime behavior of each part individually.  For example, each application can be configured to be in a separate application pool, thereby isolating it from other applications by putting it in a separate process, and optionally making that process run with a different Windows identity to sandbox it.  The application is also the level at which ASP.NET applications / appdomains are created.

Each application has a virtual path that matches the initial segment of the url’s absolute path for the requests to that application.  A request is routed to the application with the longest matching virtual path. 
- Each site must have at least the root application with the virtual path of “/”, so any requests not matching other applications in the site will be routed to the root application.

Finally, a virtual directory maps a part of the application url namespace to a physical location on disk.  When a request is routed to the application, it uses the same algorithm to find the virtual directory with the longest virtual path matching the remainder of the request’s absolute path after the application path.   
- Again, each application must have at least the root virtual directory with the virtual path of “/” to be functional.
Read more »

Comments (0)

Here is detail explaination about the IIS 7.0 and IIS 6.0 user and group account from IIS team.

Introduction

In previous versions of IIS, we had a local account created at install time called IUSR_MachineName. The IUSR_MachineName account was the default identity used by IIS whenever anonymous authentication was enabled. This was used by both the FTP and HTTP services. 

There was also had a group called IIS_WPG, used as a container for all the application pool identities. We made sure all the appropriate resources on the system had the correct permissions set for the IIS_WPG group during IIS setup so that an administrator only needed to add their identity to that group when they created a new application pool account.

This model worked well, but had its drawbacks: the IUSR_MachineName account and IIS_WPG group were both local to the system it was created on. Every account and group within Windows is given a unique number called a SID (security identifier) that distinguishes it from other accounts. When an ACL is created only the SID is used. As part of our design in previous versions of IIS, we had included the IUSR_MachineName in the metabase.xml file so that if you tried to copy the metabase.xml from one machine to another, it would not work–the account on the other machine would have a different name.

In addition, you could not just ‘xcopy /o’ ACLs from one machine to another since the SIDs were different machine to machine. A work around was to use domain accounts–but that required adding an active directory to the infrastructure. The IIS_WPG group had similar issues with permissions. If you set ACLs on one machine’s file system for IIS_WPG and tried to ‘xcopy /o’ those over to another machine, it would fail. The IIS team heard this feedback and improved this experience by using a built-in account and group in IIS 7.0.

 A built-in account and group are guaranteed by the operating system to always have a unique SID. IIS 7.0 has taken this further and ensured the actual names used by the new account and group will never be localized. For example, regardless of the language of Windows you install, the IIS account name will always be IUSR and the group name will be IIS_IUSRS.

 In summary, IIS 7.0 offers:

• The IUSR built-in account replaces the IUSR_MachineName account
• The IIS_IUSRS built-in group replaces the IIS_WPG group Read more »

Comments (0)

Pre-compilation For Deployment

Pre-compilation for deployment creates an ‘executable’ (no source code) version of your web application. With pre-compilation for deployment you give the aspnet_compiler the path to your source code, and the path to a target directory for the compilation results, like below.

aspnet_compiler -p "C:\MyDevelopment\WebSite1" -v / C:\Staging

  Read more »

Comments (0)

When a client requests an ASPX page from the Web server, the request travels through many steps before ultimately ending up as HTML displayed by the client’s browser. First, the request is processed by IIS and routed to the appropriate ISAPI extension. The ISAPI extension for ASP.NET (aspnet_isapi.dll) routes the request to the ASP.NET worker process.

Comments (0)

Any useful executable program involves either reading input, writing output, or both. Regardless of the source of the data being read or written, it can be treated abstractly as a sequence of bytes. .NET uses the System.IO.Stream class to represent this abstraction. Whether the data involves characters in a text file, TCP/IP network traffic, or something else entirely, chances are you will have access to it via a Stream. Since the class for working with file data (FileStream) and the class for working with network traffic (NetworkStream) both inherit from Stream, you can easily write code that processes the data independent of its origins. Here’s a method for printing out some bytes from a Stream to the console:

Copy Code public static void PrintBytes(Stream s)
{
    int b;
    while((b = fs.ReadByte()) >= 0)
    {
        Console.Write(b + ” “);
    }
}

  Read more »