L’ensemble des sources d’EF est disponible sur codeplex à l’adresse http://entityframework.codeplex.com/.

Alors concrètement qu’est-ce que cela va changer pour nous les utilisateurs ? Eh bien au-delà des avantages à disposer du code source pour comprendre comment tout cela fonctionne et/ou apporter des corrections/modifications, EF reste un produit MS officiel.
Cela veut dire que l’équipe qui travaille actuellement sur le produit va continuer et que MS continuera à fournir le support pour EF.

Le texte de l’annonce : http://blogs.msdn.com/b/adonet/archive/2012/07/19/entity-framework-and-open-source.aspx

Prenons par exemple l’organisation suivante et le cas ou la vue « Index » de la zone « MyArea » fait référence au layout « _Layout » par défaut :

Cela fonctionne très bien tant qu’il n’y a pas d' »Action » de défini dans le layout de base.

Ajoutons une instruction d’inclusion de la vue partielle « _LogOnStatus » comme ceci :

@Html.Action(« LogOnStatus », « Accounts »)

La page d’accueil fonctionne toujours correctement et la vue partielle est bien affichée. Naviguons maintenant vers notre zone et patatra ! Le moteur MVC nous renvoi l’erreur suivante lors de l’accès à une page de votre zone (Par exemple lors de l’accès à l’url /MyArea/Test) :

Le message d’erreur semble parlant mais … il n’est pas correct . Le problème ne vient pas du contrôleur de la vue mais de l’action du layout qui tente de trouver un contrôleur « AccountsController » qui possède une action « LogOnStatus » dans la zone en cours. En effet par défaut lorsqu’un contrôleur est recherché, la zone en cours est prise comme contexte.

Pour remédier à ce problème il suffit d’utiliser, dans le layout de base, la surcharge de Html.Action qui permet de spécifier la zone et de lui passer une nom de zone vide afin de cibler la « zone par défaut » :

Exemple :

@Html.Action(« LogOnStatus », « Accounts », new { area = «  » })

C’est tout bête mais encore faut-il le savoir

Maintenant petite devinette :

Soit la méthode suivante :

 public static IEnumerable<string> TestMethod(string filter)
 {
     if (string.IsNullOrEmpty(filter))
  throw new ArgumentNullException("filter");
 
     foreach (var item in values)
     {
  if (item.Contains(filter))
      yield return item;
     }
 }
 
 private static List<string> values = new List<string>() { "item 1", "item 2", "item 3", "item 1.1", "item 1.2" };

et le test unitaire suivant :

 [TestMethod]
 [ExpectedException(System.ArgumentNullException)]
 public void TestMethod_FilterIsNull_Test()
 {
     string filter = string.Empty;
     Program.TestMethod(filter);
 }

Quel est le résultat de ce test unitaire ?

tic, tac, tic, tac …

Ce test échoue ! La question à 10 ct, c’est pourquoi ? (J’avoue, c’est un de mes collègue qui a trouvé la réponse )

La réponse se trouve dans la MSDN cité en début d’article (ou dans ILDASM ) : Lors de l’utilisation d’une instruction “yield return”, une classe encapsulant le contenu de la méthode est générée par le compilateur. Cette classe implémente les interfaces IEnumerable et IEnumerable<T>. Le code effectif de la méthode est “déplacer” dans la méthode “MoveNext” de la nouvelle classe générée, y compris la vérification de notre argument “filter”.

L’impact de tout ça c’est que la vérification de la valeur de “filter” ne sera faite que lorsque l’on commence à énumérer les valeurs possible.

Le tests unitaires tel qu’il est écrit ne parcours jamais les résultats de la méthode TestMethod et donc ne déclenchera pas d’appel à la méthode “MoveNext” de la classe généré par le compilateur.

Coté VS 2011, c’est principalement la refonte (partielle) de l’EDI ainsi que les outils liés à la gestion du cycle de vie d’une application qui seront les nouveautés à essayer.

Pour plus d’informations sur cette annonce :
L’annonce de la date de dispo sur le blog de Somasegar

Un aperçut du nouveau look de VS 2011 sur le blog de Jason Zander

Plus de détails sur le look de l’EDI sur le blog de l’équipe VS

Son but ? Fournir une liste de succès qui seront débloqués en fonction du code que vous écrivez !

Totalement indispensable pour pouvoir se la raconter à la pause café ^^?

« Quoi ? tu n’as pas encore débloquer le succès « Ecrire une méthode utilisant un dynamic, 5 délégués et 15 requêtes linq » Noob va. »

Ou pour mettre dans un CV :

« Expérience pro : Tout les succès VS 2010 débloqué »

Bref ça ne sert à rien mais c’est fun.

Pour plus d’info c’est par ici :

http://dev9.channel9.msdn.com/blogs/c9team/Coming-Soon-Visual-Studio-Achievements

Mais connaissez-vous vraiment le comportement sous-jacent lorsque cela arrive ?

Soit ce code :

public class TestCtor
{
    /// <summary>
    /// Initializes a new instance of the <see cref="T:TestCtor"/> class.
    /// </summary>
    public TestCtor()
    {
        throw new Exception("test");
    }

    /// <summary>
    /// Finalizes an instance of the <see cref="T:TestCtor"/> class.
    /// </summary>
    ~TestCtor()
    {
        Console.WriteLine("Object is alive ! Hashcode : {0}", this.GetHashCode());
    }
}

et son utilisation :

/// <summary>
/// Defines the program entry point. 
/// </summary>
/// <param name="args">An array of <see cref="T:System.String"/> containing command line parameters.</param>
private static void Main(string[] args)
{
    TestCtor instance = null;
    try
    {
        instance = new TestCtor();
    }
    catch (Exception) { }
    Console.WriteLine("instance is null ? {0}", instance == null);

    GC.Collect();
    Console.ReadLine();
}

Question : D’après vous quel est le comportement affiché ?

1°) “Instance is null = true” et fin du programme

2°) “Instance is null = true “et “Object is alive ! HashCode : ”

3°) “Instance is null = false” et “Object is alive ! HashCode" : “

tic, tac, tic, tac, tic, tac …

La bonne réponse est la numéro 2.

En effet lors du passage dans le constructeur, l’instance de la classe TestCtor est déjà créé et référencé par le runtime. L’exception déclenché lors de l’exécution du constructeur ne fait qu’empêcher que le pointeur sur l’instance ne soit transmis à la variable “instance”. Ce qui veux dire que nous avons, à ce moment, un objet qui n’est référencé à aucun endroit dans le programme. Le Garbage Collector peut donc nettoyer cet objet, c’est ce qui est mis en avant dans le destructeur.

A noter qu’il n’est pas interdit ou déconseillé de déclencher des exceptions depuis un constructeur, il faut juste être au courant de ce comportement pour éviter par exemple de laisser trainer un objet à moitié instancié.

Pour rappel le projet Roslyn est plus connu sous le nom de « Compiler as a Service » qui a pour but d’ouvrir les compilateurs VB.NET et C# afin de permettre leur enrichissement et leur intégration dans nos applications.

Mais alors pourquoi donc ?
– Pour faire plein d’outils d’analyse de code
– Pour utiliser le C# en tant que langage de script
– Faire de l’invocation dynamique de code dans nos applications
– etc, etc, etc.

Bon code

Pour rappel le FP 1 apportait un ensemble d’outils dédiés à la modélisation.
Dans le FP 2 ce sont les outils de testing qui sont à l’honneur.

En effet ce FP 2 apporte le support de Firefox pour les tests d’interfaces graphiques (CodedUI tests), un nouvel éditeur pour ces tests et surtout le support de Silverlight 4 lors de l’enregistrement et du rejoue des tests.

Pour le téléchargement, c’est par ici.

Pour en savoir plus sur les tests d’interfaces graphiques, c’est par ici

et surtout, surtout le partage des entités par plusieurs domaine.

Si vous avez déjà les RIA services d’installé, il vous faudra les déinstaller avant de pouvoir utiliser le SP1.

Pour le téléchargement c’est par ici :
– RIA Services
– RIA Services toolkit