ASP.NET peut être utilisé pour héberger plusieurs applications Web, chacune identifiée à l'aide d'un préfixe d'URL unique au sein d'un site Web (où un site Web est représenté sur un serveur Web en tant que combinaison HostName/Port unique). Par exemple, un serveur Web Microsoft Internet Information Services (IIS) unique avec deux adresses IP mappées (l'une portant l'alias « www.msn.com » et l'autre l'alias « intranet ») et trois sites logiques (http://intranet, http://www.msn.com, http://www.msn.com port 81) peuvent exposer les six applications ASP.NET suivantes.

Remarque : L'URL de l'application de compensation mentionnée dans le tableau est associée à une racine au sein de l'espace de noms de l'URL de l'application RH. Cependant, cette notation de hiérarchie d'URL n'implique pas que l'application de compensation soit contenue ou imbriquée dans l'application RH. Par contre, chaque application gère un jeu indépendant de propriétés de configuration et de résolution des classes. Ce sont toutes les deux des sites enfants homologues logiques du site intranet.

Chaque application ASP.NET Framework exposée dans un espace de noms d'URL est sauvegardée dans un répertoire du système de fichiers situé sur un partage de fichiers local ou distant. Les répertoires de l'application ne doivent pas être situés à un emplacement central au sein d'une partie contiguë du système de fichiers. Ils peuvent être dispersés sur un disque. Par exemple, les applications ASP.NET mentionnées précédemment peuvent se situer dans les différents répertoires énumérés dans le tableau suivant.

Les assemblys constituent l'unité de déploiement des classes dans le Common Language Runtime. Les développeurs écrivant des classes .NET Framework qui utilisent Visual Studio.NET version 7.0 produisent un nouvel assembly avec chaque projet Visual Studio qu'ils compilent. Même s'il est possible de répartir un assembly sur plusieurs fichiers exécutables portables (PE) (plusieurs DLL de module), Visual Studio.NET compile par défaut tout le code assembleur dans une DLL unique (1 projet Visual Studio.NET = 1 assembly .NET Framework = 1 DLL physique).

Vous pouvez utiliser un assembly sur un ordinateur en le déployant dans un cache d'assembly. Le cache d'assembly peut être soit global pour un ordinateur, soit local pour une application particulière. Seul le code destiné à être partagé entre plusieurs applications doit être placé dans le cache d'assembly système global. Le code propre à une application particulière, comme la plus grande partie de la logique d'application Web, doit être déployé dans le cache d'assembly local de l'application. Le déploiement d'un assembly au sein du cache d'assembly local d'une application présente l'avantage que seul le code de l'application peut y accéder. (Cette fonctionnalité est utile pour les scénarios impliquant des fournisseurs de services Internet.) Cela facilite également le versioning côte à côte de la même application, car les classes sont propres à chaque instance de version de l'application.

Un assembly peut être déployé dans le cache d'assembly local d'une application en effectuant une copie, une copie XCOPY ou un transfert FTP des fichiers appropriés dans un répertoire marqué comme « emplacement du cache d'assembly » pour cette application particulière. Aucun outil d'inscription supplémentaire ne doit être exécuté après la copie des fichiers appropriés et aucun redémarrage n'est nécessaire. Cela élimine certaines difficultés actuellement associées au déploiement de composants COM au sein d'applications ASP (à ce jour, un administrateur doit ouvrir une session localement sur le serveur Web et exécuter Regsvr32.exe).

Par défaut, une application ASP.NET Framework est automatiquement configurée pour utiliser le sous-répertoire \bin (situé immédiatement sous la racine de l'application) comme cache d'assembly local. Le répertoire \bin est également configuré pour refuser tout accès au navigateur afin qu'un client distant ne puisse pas télécharger et dérober le code. L'exemple suivant illustre une arborescence de répertoires possible pour une application ASP.NET, dans laquelle le répertoire \bin se situe immédiatement sous la racine de l'application.

Les applications ASP.NET Framework sont construites en différé la première fois qu'un client leur demande une ressource d'URL. Chaque application ASP.NET Framework est lancée au sein d'un domaine d'application unique (AppDomain), c'est-à-dire une nouvelle construction Common Language Runtime permettant aux hôtes de processus d'assurer une isolation poussée du code, de la sécurité et de la configuration au moment de l'exécution.

ASP.NET est responsable de la création manuelle d'un domaine d'application lors du démarrage d'une nouvelle application. Au cours de ce processus, ASP.NET fournit des paramètres de configuration pour le Common Language Runtime à utiliser. Ces paramètres sont les suivants :

• Les chemins d'accès des répertoires constituant le cache d'assembly local. (Remarque : C'est l'architecture d'isolation des domaines d'application .NET Framework qui permet à chaque application de gérer son propre cache d'assembly local.)
• Les restrictions de sécurité de l'application (éléments auxquels l'application peut accéder sur le système).

Comme ASP.NET ne possède pas de connaissances, au moment de la compilation, de l'existence d'applications qui viennent se superposer à lui, il ne peut pas utiliser de références statiques pour résoudre et référencer le code d'application. ASP.NET doit plutôt utiliser une approche de résolution classe/assembly dynamique pour effectuer la transition du runtime de ASP.NET vers le code d'application.

Les fichiers de configuration et d'activation de page de ASP.NET vous permettent de référencer de manière dynamique une classe .NET Framework compilée en fonction de la cible en spécifiant une combinaison de noms d'assembly et de classe. Cette union utilise le format de chaîne suivant :

Les assemblys .NET Framework sont généralement compilés et déployés dans un format PE basé sur les DLL Windows. Lorsque le chargeur du Common Language Runtime résout une classe implémentée dans ce type d'assembly, il appelle la routine Windows LoadLibrary sur le fichier (qui verrouille son accès sur le disque), puis mappe les données de code appropriées dans la mémoire en vue de l'exécution. Une fois chargé, le fichier DLL reste verrouillé sur le disque jusqu'à ce que le domaine d'application qui le référence soit détruit ou recyclé manuellement.

Même si ASP.NET ne peut pas empêcher le Common Language Runtime de verrouiller une DLL d'assembly chargée sur le disque, il peut vous aider en garantissant que les DLL physiques du cache d'assembly propre à l'application Web ne sont jamais chargées par le runtime. Des copies en double des DLL d'assembly sont plutôt créées immédiatement avant leur utilisation. Ces assemblys en double, et non les fichiers d'origine, sont ensuite verrouillés et chargés par le runtime.

Comme les fichiers d'assembly d'origine restent toujours déverrouillés, vous êtes libre de les supprimer, de les remplacer ou de les renommer sans être obligé de parcourir le serveur Web ou d'utiliser un utilitaire d'inscription. FTP et les méthodes similaires fonctionnent correctement. ASP.NET gère une liste active de tous les assemblys chargés dans un domaine d'application d'une application particulière et utilise le code de contrôle des modifications apportées au fichier pour détecter les mises à jour éventuelles des fichiers d'origine.