Reprise du message précédent :
Effectivement, si c'est un problème de droit, c'est un peu mal foutu l'exception

Effectivement, c'est exactement comme ça qu'il faut procéder pour tout site où la connexion repose l'authentification anonyme, qui se traduit donc par l'utilisation de l'user par défaut de IIS.
Pour ce qui est de l'exception pourrie, bravo MS...

L'exception est certe pourrÿte mais elle est indiquée dans la doc:
http://msdn.microsoft.com/en-us/library/stf701f5.aspx

Anders Hejlsberg sur le future de C# et VB.net
http://channel9.msdn.com/Events/BU [...] /TOOL-816T

La présentation est grosso modo divisée en 2 parties indépendantes donc si tu peux la regarder en 2 fois sans devoir tout recommencer du début pour comprendre de quoi le monsieur parle.

Le await/async ça déchire !
Par contre cela utilise le même thread que celui de l'UI.
Je n'ai pas vu de référence au niveau des performances. Est-ce que tous les cœurs d'un processeur sont utilisés lorsqu'une tache se déroule en arrière plan ?

 
Je ne me suis jamais posé la question, je reste adepte du bon vieux FireBug

Salut à tous,
 
Est-ce que certains d'entre vous on déjà utilisé en .NET le Reporting Services 2010 pour, par exemple, récupérer le burndown chart d'un Team foundation server ?
 
Merci d'avance.
 
Fixed

 
Avec des delegate ?
 
ou encore des class partial si les binaires sont différent pour chaque portail

 
Avec un framework d'inversion de controle genre StructureMap, et de l'interface y a moyen. L'idée, c'est que les objets qui ont des comportements différents implémentent un interface commune. Et avec structuremap chaque Portail précise quelle implémentation il veut utiliser.

Concrètement ça donne :  
 

 
Dans ton Global.asax de ton Portail1
 

 
En gros ce code va faire qu'à chaque fois que tu utiliseras IEnregistreur, StructureMap chargera EnregisteurPortail1.
 
Je viens de découvrir StructureMap récemment, c'est un peu obscur au début, mais c'est très puissant. Et ça va bien au dela de ce cas!!
 
http://structuremap.net/structuremap/QuickStart.htm

ça dépend de pas mal de critère. Si tu est dans une situation où les protails A et B ont un comportement X, les portails B et C ont un comportement Y et les portails A et C ont aussi un comportement Z le mieux c'est de mettre en place un systeme de paramétrage avec des if en fonction des paramètres. Si tous les portails ont des comportement communs et que chaque portail a d'autres comportements qui lui sont propres tu peux faire une classe abstraite qui regroupe les comportements communs et faire une classe qui en hérite pour chaque portail.
 
mais vu le peu de contexte que tu donnes, c'est assez difficile de te donner des conseils precis.

 
Jette un coup d'oeil du côté de MEF  
 
MEF - Managed Extensibility Framework - De la magie est des plugins !
 
Sur le même blog il y a un article sur l'utilisation de MEF avec silverlight.  

MEF n'existe qu'en .NET 4.0, fred82 veux du 3.5

C'est jouable en référençant la bonne DLL. Mais en fait je destinais ce liens plus à DrRobert qu'a fred82.

C'est une généralisation abusive. Si tu fais un singleton dont la durée de vie est égale à la durée de vie de l'application il prendra autant de mémoire que si tu faisais la même chose dans une classe statique.  
AMHA ce genre de conseil est contre productif étant donné qu'il encourage à suivre aveuglément des consignes plutot que de comprendre ce qui se passe en interne alors que c'est primordial pour traquer une fuite mémoire.
 
Pour répondre à ta question sur les méthode statiques, aucune inquiétude à avoir, les variables instanciées dans ta méthodes seront libérées quand son execution sera terminée comme pour une méhode de classe normale.

Je pense qu'il ne faut pas regarder les choses sous cet angle là. Il faut d'abord ma structure de données ou l'architecture qui correspond le mieux à son besoins et ensuite s'intéresser  à l'impact sur la conso mémoire. En l'occurrence, la différence de conso memoire entre une classe statique et un Singleton seront infinitésimales, il vaut mieux s'intéresser à ce qu'ils contiennent.
 
 
FindAll est antérieur à LINQ, la fonction ne s'applique qu'aux list contrairement aux fonctions LINQ qui s'appliquent à tous les IEnumerable et FindAll renvoit ses résultats dans une nouvelle list ce qu'elle doit alouer en mémoire contrairement au where qui renvoit un IEnumerable. FindAll serait l'équivalent de where().ToList().

 
Normalement c'est toi qui "map" le répertoire TFS sur ton HDD.
- Soit tu fais un clic droit sur ton projet et ouvrir le répertoire
- Soit tu vas dans ton team explorer, tu loads tes projets, double clic sur celui qui t’intéresse, ce qui t’ouvre le source control explorer, et dans la deuxième fenêtre, à droite, tu as le local path.
 
 
 
 
Si tu mets un breakpoint avant l'appelle d’une méthode de la DLL et que tu fais F11 il te propose d'essayé de rentrer dedans.

 
Oki.
Pour ça, tu vas dans ton Source Control Explorer.
Tu fais un clic droit sur le fichier qui t'intéresse, et propriété.
Tu auras :
- Latest Version : dernière version sur le TFS
- Workspace Version : dernière version que tu as prise sur ton espace de travail
 
 
 
Tu fais une recherche du namespace de ta DLL.
T'auras bien un fichier avec un using ou alors un appelle avec directement le namespace.

 
Pour ça tu peux essayer de regarder coté .SUO (Solution User Options).
Il faut que tu affiches les dossiers et fichiers caché, tu auras des fichiers .SUO à coté de ton fichier .SLN.
 
C'est de l'hexadécimal, tu peux l'ouvrir avec Visual Studio, mais ça ne sera pas facile à lire.
 
Ou tu te fais une petite application console avec le TSF SDK (Tu instancies le VersionControlServer).
 
 
 
Ce que tu peux faire c'est installer IlSpy (Remplaçant gratuit de Reflector qui est devenu payant), tu l'ouvres et mets ta DLL dedans.
Il va la désassemblé, et tu pouvoir voire son contenu et donc son namespace.