2008-10-24 6 views
5

J'utilise 3.5 SP1 sur ma machine, alors que nos clients utilisent actuellement 3.5 sans SP1. Je ne connais aucun moyen dans VS2008 pour cibler la solution ou le projet à 3.5 sans SP1, seulement le 3.5 avec SP1 que j'ai installé.Détection de dépendance .NET Framework 3.5 SP1 (cmp 3.5 sans SP1)

Si nous utilisons des fonctions ou des constructeurs non disponibles dans la version 3.5 sans SP1, le code ne fonctionnera pas correctement.

C'est, je veux détecter à l'heure de compilation ce qui ne fonctionnerait pas sans SP1. Jusqu'à présent, nous avons effectué des tests (dans une machine virtuelle ou une machine séparée) pour voir si l'application se casse, et elle se casse parfois lorsque nous avons utilisé des parties de l'API qui ne sont pas disponibles avant le SP1. Le problème est qu'il ne casse que lorsque le code s'exécute (au moment de l'exécution), et non lorsque l'assembly est chargé.

Une solution serait d'avoir une machine avec VS2008 sans SP1 et essayer de compiler le projet. Cependant, je préférerais un outil pour m'aider à détecter une dépendance à 3.5 SP1 (en raison de l'utilisation d'une nouvelle API, ou autre), soit en analysant le code source, soit les assemblages que nous produisons.

Mes pouvoirs google n'a pas été assez fort avec cette question, des conseils?

Répondre

5

J'ai juste eu le même problème, et j'ai trouvé une solution. Pour notre application, c'était un appel à System.Threading.WaitHandle.WaitOne (Int32) qui nous a causé des problèmes. Pour plus de détails sur la façon dont les références aux API qui ont été introduites dans les versions du Service Pack peuvent fuir dans votre code sans que Visual Studio ne s'en aperçoive, voir Krzysztof Cwalina's post. Les bonnes nouvelles sont que, comme Marc mentioned is his answer, FxCop a un new rule qui détecte ces fuites.

La mauvaise nouvelle est que la règle est rompue dans FxCop 1.36 lorsque vous ciblez .NET Framework 3.5. Toutefois, David Kean décrit comment modifier un couple de fichiers de configuration XML en fix the problem. J'ai suivi les instructions, et FxCop détecte maintenant mes références aux API du Service Pack.

2

Que diriez-vous de this? (règles de multi-ciblage pour FxCop)

+0

Je viens d'essayer FxCop 1.36 (autonome). En utilisant une version de notre application connue pour utiliser l'API SP1, je n'étais toujours pas capable de localiser les utilisations 3.5SP1. –

1

Vous pouvez utiliser le code trouvé here pour détecter les Frameworks .NET installés.

+0

Merci, mais je sais déjà exactement quelle version est installée. Ceci est un produit interne, et l'environnement est bien spécifié. Les problèmes que nous avons est de ne pas utiliser accidentellement le code du SP1 car les stations de travail ne peuvent pas l'exécuter. –

0

chaîne Fx35RegistryKey = @ "HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ NET Configuration du système \ NDP \ v3.5"; objet Fx35ServicePack = Registry.GetValue (Fx35RegistryKey, "SP", null); If (Fx35ServicePack == null || (int) Fx35ServicePack 10 1) lancer une nouvelle exception (".NET Framework 3.5 SP1 est requis.");

+0

Ceci est similaire à une Answear précédente et ne fonctionne que dans Runtime. Ma question concerne principalement quelque chose pendant la compilation. –

0

Il y a une autre option que je n'ai pas essayée. Le Visual Studio documentation indique que vous pouvez faire en sorte que votre programme d'installation ClickOnce cible spécifiquement le framework .NET 3.5SP1. Suivez le lien et recherchez "Cibler .NET Framework Version 3.5 SP1". Essentiellement, il indique que l'une des actions suivantes forcera le programme d'installation à installer 3.5SP1:

  • Spécifiez une URL d'erreur dans la boîte de dialogue Options de publication.
  • Spécifiez un nom de suite dans la boîte de dialogue Options de publication.
  • Créez un raccourci sur le bureau dans la boîte de dialogue Options de publication.
  • Exclure un fichier du hachage dans la boîte de dialogue Fichiers d'application.
  • Décochez la case Signer les manifestes ClickOnce sur la page Signature.
  • Ajoutez une référence à l'assembly System.Data.Entity.
Questions connexes