Nouvelles Chroniques d'Amethyste

Penser au Sens, pas au Verbe


Poster un commentaire

Déployer dans le GAC sous Windows Server 2012

Il y a 3 méthodes pour déployer une dll dans le GAC:

  1. L’utilitaire Gacutil
  2. PowerShell
  3. Copier/coller depuis l’Explorateur Windows

 

Je viens de découvrir dans le cadre de mon projet actuel, que sous Windows Server 2012 la dernière méthode n’est plus possible, du moins au delà de .Net 4.0:

http://blog.adnanmasood.com/2014/09/18/gac-changes-in-windows-server-2012/

Puisque gacutil n’est pas non plus installé par défaut il n’est peut être pas inutile de savoir le faire via PowerShell.

 

On trouve des exemples un peu partout, en voici un:


Set-location "c:\Folder Path"
[System.Reflection.Assembly]::Load("System.EnterpriseServices, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a")
$publish = New-Object System.EnterpriseServices.Internal.Publish
$publish.GacInstall("c:\Folder Path\MADLL.dll")

On peut compléter par un appel à iisreset si IIS est installé sur le serveur.

 

L’opération inverse est bien sûr possible:


Set-location "c:\Folder Path"
[System.Reflection.Assembly]::Load("System.EnterpriseServices, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a")
$publish = New-Object System.EnterpriseServices.Internal.Publish
$publish.GacRemove("c:\Folder Path\MADLL.dll")

 

 

Publicités


Poster un commentaire

Premier contact avec Windows Server AppFabric partie IV

Lors de mes essais, presque rien n’a fonctionné du premier coup.

Dans cet article je vais indiquer quelques unes des astuces qui m’ont permis de comprendre la nature de mon problème.

Ce sera le dernier article de la série sur AppFabric. Le premier se trouve ici:

https://amethyste16.wordpress.com/2014/07/20/premier-contact-avec-windows-server-appfabric-partie-i/

 

Start-CacheCluster plante

Le cluster de l’hôte courant démarre sans problème, mais pas moyen de démarrer les nœuds distants.

Il est normal de soupçonner un problème d’accès au serveur distant, par exemple une histoire de credentials ou bien une histoire de pare feu. Pour en savoir plus, direction les logs!

 

Lancez l’explorateur Windows

Saisissez %temp% dans la ligne de commande:

2014-07-16_09-44-39

Nos fichiers sont là, il n’y a plus qu’à les analyser.

Il ne faut évidemment pas hésiter à faire appel à son moteur de recherche favori.

 

De part mon expérience, le principal problème à affronter est:

  • oublié de remplir le fichier host
  • l’adresse IP du serveur a changé lors d’un reboot
    Il est alors utile de savoir que AppFabric a ses fichiers de configuration ici:
    %windir%\system32\AppFabric\

 

Le cache client ne marche pas

 

Lors de mes premiers essais, j’ai été confronté à ce message d’erreur lorsque je tentais d’accéder aux caches:

Message=ErrorCode<ERRCA0017>:SubStatus<ES0006>:There is a temporary failure. Please retry later. (One or more specified cache servers are unavailable, which could be caused by busy network or servers. For on-premises cache clusters, also verify the following conditions. Ensure that security permission has been granted for this client account, and check that the AppFabric Caching Service is allowed through the firewall on all cache hosts. Also the MaxBufferSize on the server must be greater than or equal to the serialized object size sent from the client.)

Ce message est un message générique qui en pratique nous aide assez peu.

Vous trouverez ici un petit truc qui peut aider à obtenir un message plus complet:

http://blogs.msdn.com/b/akshar/archive/2011/05/01/azure-appfabric-caching-errorcode-lt-errca0017-gt-substatus-lt-es0006-gt-what-to-do.aspx

 

 

 

 


Poster un commentaire

Premier contact avec Windows Server AppFabric partie III

Cet article est la suite d’une série qui a démarrée ici:

https://amethyste16.wordpress.com/2014/07/20/premier-contact-avec-windows-server-appfabric-partie-i/

 

Il ne sera peut être pas inutile de lire également cet article auparavant qui donne les bases pour comprendre comment héberger WCF dans IIS:

https://amethyste16.wordpress.com/2014/08/14/windows-activation-service-was/

Mais ce n’est pas indispensable pour lire la suite.

 

Windows AppFabric propose des outils pour améliorer l’hébergement des services WCF et Workflow avec WAS.

On pourrait bien entendu héberger le service directement avec WAS. Mais il n’est pas inutile de disposer de certains services tels la surveillance du service, suivi des exceptions… Surtout en production. Ce sont les genres de services justement apportés par Windows AppFabric en plus d’une simplification du déploiement.

Allons y donc!

Lire la suite


Poster un commentaire

Processus et domaine d’application

Processus

Un processus (process) est un conteneur pour un (ou plusieurs) exécutables (un programme) et ses données. Le processus fournit à l’exécutable un espace mémoire réservé par le système d’exploitation. De plus le processus est parcourut par au moins 1 thread, mais très souvent on en rencontre plus. Toutes ressources ou fichiers ouverts ou créés par le programme appartient lui aussi au processus.
Pour finir un processus embarque un contexte de sécurité qui lui est propre. Ce contexte dicte au processus ce qu’il a le droit ou non de faire sur la machine, le réseau ou toute autres ressources.

Comme on le voit, un processus agit comme une frontière pour isoler un programme des autres programmes. Le processus est la plus petite unité d’isolation d’un code sous Windows.
Une erreur, un plantage dans un processus, n’affecte que les applications qui tournent dans le processus. Les autres processus ne sont pas affectés si ce n’est pas un éventuel verrou sur une ressource, l’utilisation d’espace mémoire…

Théoriquement, un serveur voulant héberger plusieurs sites ou plusieurs services créera autant de processus qu’il y aura d’instances afin de les isoler les uns des autres.
Seulement la création d’un processus est une opération coûteuse en ressources système. On va rapidement atteindre les limites physiques du serveur.

Domaine d’application

L’environnement .Net propose une solution à ce problème: le domaine d’application (application domain).

Par certains aspects, les domaines d’application (DA) ressemblent à un processus: ils sont à la fois frontière et conteneur. Cela signifie en particulier qu’un objet vit dans un et un seul DA. Par exemple une classe avec des propriétés statiques ne partagera pas son état avec un autre DA, chaque application a sa propre copie de cache, session…

Il y a toutefois des spécificités:

  • Il ne s’agit que d’un concept .Net. Windows ne gère pas les domaines d’application.
  • Les DA n’ont pas leur propre contexte de sécurité. Ils utilisent celui du processus
  • Les DA appartiennent à un seul processus, mais un processus peut héberger plusieurs DA

Ce dernier point peut être important surtout si l’on sait que par défaut ASP.NET est lancé en full trust.

Un DA est moins coûteux à créer et a besoin de moins de ressources puisqu’ils partages celles de leur processus hôte.

Il est possible de savoir combien de DA sont chargés dans un processus avec perfmon.exe:

2014-08-09_21-03-50

Vision développeur

Les processus sont pris en charge par la classe Process. Par exemple le code suivant fournit le processus courant:

Process process = Process.GetCurrentProcess();

L’instance expose un grand nombre de propriétés comme la collection de modules chargés en mémoire, la durée de consommation de la CPU, les threads…

On peut aussi choisir d’énumérer tous les processus disponibles:

foreach (Process process in Process.GetProcesses())
{
    Console.WriteLine(process.ProcessName);
}

Chaque application .Net tourne dans un DA. On peut obtenir des informations à son sujet avec le code suivant:

AppDomain appDomain = AppDomain.CurrentDomain;

Et les états du domaine:

2014-08-09_19-06-24