Modifications dans .NET Framework 3.5 SP1

améliorations des performances

Les applications utilisent désormais la prévention de l’exécution des données pour empêcher les tentatives d’insertion et d’exécution de code à partir d’emplacements de mémoire non exécutables.

La sécurité de l’exécution du code managé (y compris les assemblys MSIL, les images NGen et le code non managé) est renforcée par la randomisation de disposition de l’espace d’adressage (ASLR).

Les assemblys signés avec nom fort n’ont plus besoin d’avoir vérifié leurs signatures au moment du chargement, à condition qu’elles soient entièrement approuvées et qu’elles soient chargées dans des domaines d’application entièrement approuvés. Cette modification élimine les vérifications redondantes et améliore les performances de démarrage des applications qui ont des assemblys signés, mais qui ne sont pas installées dans le Global Assembly Cache (GAC).

Les applications lancées à partir de partages réseau ont le même comportement que les exécutables non managés et fonctionnent en toute confiance, par opposition à une approbation partielle.

L’attribut StringFreezingAttribute est désormais ignoré. Cet attribut a été utilisé pour créer des images natives à l’aide du générateur d’images natives (Ngen.exe).

L’inliner du compilateur juste-à-temps (JIT) a été considérablement amélioré pour générer du code de meilleure qualité. Toutefois, la modification de l’inliner a un impact sur les applications qui ont des classes instanciées avec des constructeurs qui utilisent la valeur d’énumération TypeAttributes.BeforeFieldInit. L’initialisation statique de ces types est garantie à la fois avant l’accès à l’un des champs statiques, mais pas avant l’appel d’une méthode statique ou d’un constructeur d’instance. L’heure exacte à laquelle le constructeur de classe est appelé peut être différent dans .NET Framework version 3.5 et 3.5 SP1.

Les autres modifications apportées au compilateur JIT incluent les modifications apportées aux erreurs d’arrondi à virgule flottante et aux modifications apportées au minutage des finaliseurs.

Aucune modification n’est requise.

méthodes CanConvertToString sur les classes Serializer Value

Les méthodes CanConvertToString sur les classes de sérialiseur de valeur dans l’espace de noms System.Windows.Converters lèvent un ArgumentException au lieu de retourner faux.

Les méthodes System.Data.SqlClient.SQLDataReader.GetString et oth er Get lèvent une InvalidCastException si les données ne peuvent pas être converties en type demandé. Les messages incluent désormais les types, tels que : « Impossible de convertir l’objet de type « System.Decimal » en type « System.String ».

Aucune modification n’est requise.

Requêtes sur des collections non génériques utilisent désormais la sémantique de cast C# standard.

Dans les expressions de requête LINQ sur des collections non génériques telles que System.Collections.ArrayList, la clause from de la requête est réécrite par le compilateur pour inclure un appel à l’opérateur Cast<T>. Cast<T> convertit tous les types d’éléments en type spécifié dans la clause from de la requête. En outre, dans la version d’origine de Visual C# 2008, l’opérateur Cast<T> effectue également certaines conversions de type valeur et des conversions définies par l’utilisateur. Toutefois, ces conversions sont effectuées à l’aide de la classe System.Convert au lieu de la sémantique C# standard. Ces conversions provoquent également des problèmes de performances significatifs dans certains scénarios. Dans Visual C# 2008 SP1, l’opérateur Cast<T> est modifié pour lever une invalidCastException pour les conversions numériques de type valeur et définies par l’utilisateur. Cette modification élimine à la fois la sémantique de cast C# non standard et le problème de performances. Cette modification est illustrée dans l’exemple suivant.

using System;
using System.Linq;

class Program
{
    public struct S { }
    static void Main()
    {
        var floats = new    float[] { 2.7f, 3.1f, 4.5f };
        var ints = from    int i in floats
                   select    i;

        // Visual C# 2008    SP1 throws InvalidCastException.
        foreach (var v in    ints)
               Console.Write("{0} ", v.ToString());

        // The original    release version of Visual C# 2008
        // compiles and    outputs 3 3 4
    }
}

Modifications suggérées : si vous avez du code qui effectue des requêtes LINQ sur des collections non génériques et que ce code lève désormais une exception, modifiez le type de l’expression de requête pour qu’il corresponde au type des éléments de la collection que vous interrogez. Si vous devez effectuer une conversion de type valeur ou définie par l’utilisateur sur les éléments, vous pouvez le faire lorsque vous exécutez la requête, comme illustré dans l’exemple suivant :

using System;
using System.Linq;

class Program
{

    static void    Main(string[] args)
    {
        ArrayList floats =    new ArrayList();

        floats.Add(2.7f);
        floats.Add(3.1f);
        floats.Add(4.5f);

        var query = from    float f in floats
                    where    f > 3.0f
                    select    f;

        foreach (int i in    floats)
        {
            // Perform the    conversion as you
            // execute the    query.
            int num =    Convert.ToInt32(i);
               Console.Write("{0} ", num.ToString());
        }

           Console.ReadLine(); // output is 3 4
    }
}

en mode intégré IIS

Sur le mode d’intégration pour Internet Information Services (IIS) 7.0, la méthode HttpServerUtility.TransferRequest utilise incorrectement la méthode HTTPResponse.End pour arrêter la requête parente. Cela entraîne la levée d’un ThreadAbortException, ce qui peut avoir un impact sur les performances pour terminer l’exécution d’une réponse. Dans .NET Framework 3.5 SP1, la méthode TransferRequest met désormais fin à la requête parente à l’aide de la méthode HttpApplication.CompleteRequest. Cela met également fin à la requête actuelle en transférant le contrôle vers la HttpApplication.EndRequest gestionnaire d’événements sans lever d’exception.

Modifications suggérées : si vous avez du code de gestion des erreurs qui utilise la méthode TransferRequest pour déterminer si l' threadAbortException a été levée, vous pouvez supprimer ce code du bloc catch. (Enfin, les blocs continueront à s’exécuter.)

CDOSYS

Les classes de l’espace de noms System.Web.Mail s’appuient sur les composants Collaboration Data Objects pour Windows 2000, qui ne seront pas disponibles dans la prochaine version de Windows (Windows 7). Par conséquent, l’utilisation de ces classes dans Windows 7 lève une PlatformNotSupportedException .

Modifications suggérées : System.Web.Mail a été déconseillé dans .NET Framework version 2.0. Utilisez la prise en charge de la messagerie dans l’espace de noms System.Net.Mail à la place.

validations d’URL

ASP.NET valide désormais les parties de l’URL lorsqu’elles sont accessibles à partir d’une page de ASP.NET. Toutefois, lorsque la réécriture d’URL est utilisée, il est possible d’accéder à l’ancienne version de l’URL sur la page avec la propriété Request.RawUrl.

Modifications suggérées : désactivez la validation sur une page, si nécessaire.

d’encodage d’URL

ASP.NET développe désormais l’encodage d’URL des en-têtes HTTP sortants pour inclure le caractère de suppression (7F) et tous les caractères de contrôle ASCII (à l’exception de l’onglet horizontal).

Modifications suggérées : si nécessaire, vous pouvez désactiver le comportement d’encodage d’en-tête par défaut comme suit :

<httpRuntime enableHeaderChecking="true|false" />

la mise en forme des numéros de serveur et du client

Le comportement de mise en forme de la fonction Number.localeFormat (exécuter sur le client) est désormais conforme à la méthode String.Format (exécutée sur le serveur). Par exemple, le code suivant retourne 1000.00% :

String.Format("{0:p2}", 10)

Avant .NET Framework 3.5 SP1, le code suivant retourne 10.00% :

String.localeFormat("{0:p2}", 10)

À présent, paramètres régionauxFormat retourne 1000.00% .

Aucune modification n’est requise.

classes BitmapEffect sont obsolètes

Classe System.Windows.Media.Effects.BitmapEffect, et ses classes dérivées (BevelBitmapEffect, BitmapEffectGroup, BlurBitmapEffect, DropShadowBitmapEffect, EmbossBitmapEffectet OuterGlowBitmapEffect), sont désormais obsolètes.

Modifications suggérées : arrêtez d’utiliser les classes héritées BitmapEffect et dérivées et utilisez plutôt les nouvelles classes dérivées de Effect:BlurEffect, DropShadowEffectet ShaderEffect.

 Vous pouvez également créer vos propres effets en dérivant de ShaderEffect.

comportement du lien hypertexte

Si la valeur de la propriété Hyperlink.NavigateUri change entre l’heure à laquelle l’utilisateur pointe le curseur de la souris sur un lien hypertexte et l’heure où l’utilisateur clique sur ce lien hypertexte, la navigation se produit à l’aide de l’URI obtenu lorsque le curseur a survolé le lien hypertexte.

Aucune modification n’est requise.

méthodes CanConvertToString sur les classes Serializer Value

Les méthodes CanConvertToString sur les classes de sérialiseur de valeur dans les System.Windows.Media.Converters et System.Windows.Media.Media3D.Converters lèvent un ArgumentException au lieu de renvoyer faux.

Aucune modification n’est requise.

correspondance de schéma

Le schéma de correspondance de schéma utilisé par l' UriTemplate et classes UriTemplateTable a été assoupli pour accepter les adresses de base avec des schémas autres que HTTP. À présent, aucune de ces classes n’utilise le schéma ou le numéro de port lors de la mise en correspondance d’URI candidats aux modèles. La prise en charge des modèles pour les barres obliques de fin et les valeurs par défaut a été ajoutée.

Aucune modification n’est requise.

prise en charge de l’approbation partielle pour la journalisation des événements

L’approbation partielle prend désormais en charge la journalisation des événements limitée. Seules les erreurs d’activation de service, les échecs de suivi et les échecs de journalisation sont enregistrés dans le journal des événements. Pour éviter d’écrire des messages excessifs dans le journal des événements, le nombre maximal d’événements pouvant être enregistrés par un processus est de 5.

Aucune modification n’est requise.