Je travaille sur une utilité pour SharePoint. C'est une application qui fonctionne pour SharePoint 2007 et 2010. Lorsque j'ai une référence à la version 12.0.0.0 de la version SharePoint.dll, l'application fonctionne pour SharePoint 2007, mais pas pour 2010. Si je renvoie la version 14.0.0.0 du DLL, puis l'application fonctionne bien pour 2010, mais pas pour 2007.
Je peux facilement dire quels .dll que je dois utiliser en regardant sur le système de fichiers avec le code suivant, en vérifiant 12 sur le chemin (SharePoint 2007 ) ou 14 (SharePoint 2010). P>
System.IO.File.Exists(
Environment.GetFolderPath(Environment.SpecialFolder.CommonProgramFiles) +
@"\Microsoft Shared\web server extensions\14\ISAPI\Microsoft.SharePoint.dll"));
5 Réponses :
Je pense que vous devez regarder la redirection de liaison de l'assemblage dans le cadre.
http://msdn.microsoft.com/en-us/library /2fc472t2.aspx
Vous pouvez utiliser l'outil de configuration '.NET Framework' pour configurer la redirection.
Une redirection contraignante est la configuration, qui n'est pas dynamique.
@Kent Boogaart - Oui, mais comme il sait quels assemblages à charger, ceux-ci peuvent être configurés correctement?
Seulement s'il veut configurer sélectivement l'application pour chaque machine auquel il est déployé, qu'il indique qu'il ne le fait pas. Il veut se déployer une fois et le faire fonctionner quelle que soit la version de SP installée.
Je pourrais avoir l'utilisateur de sélectionner sur la première charge quelle version de SharePoint L'application est utilisée, puis de configurer et de redémarrer l'application.
@RYAN: Cela suppose que votre application a la permission d'écrire sur le fichier de configuration, ce qui ne serait généralement pas (ni ne devrait pas) une fois installé.
Vous n'avez pas besoin de définir ces redirections contraignantes - elles sont déjà en place.
à titre de appdomain.assemblblyResolve code> , vous pouvez vérifier l'existence de la DLL et renvoyer l'une étant présent:
AppDomain.AssemblyResolve += delegate(object sender, ResolveEventArgs e)
{
if (e.Name == "Microsoft.SharePoint")
{
// do your check here and return the appropriate Assembly
// or maybe just skip an explicit check and instead return either
// Assembly.Load("Microsoft.SharePoint, Version=14.0.0.0") or
// Assembly.Load("Microsoft.SharePoint, Version=12.0.0.0"), whichever works first
// but beware of recursion!
}
};
+1 - Je devais faire face à cela dans le passé et c'est ce que j'ai fait.
Vous n'avez pas besoin de faire cela - voir ma réponse. Les redirections contraignantes sont déjà en place dans SharePoint 2010 pour rediriger V12 à V14 afin de travailler automatiquement et de manière automatiquement de manière automatiquement. OH - et 2007 redirige 2003 (v11) à V12 aussi.
Cela ressemble à un excellent cas pour l'injection de dépendance à l'aide de l'un des DI Cadres tels que Unity ou Castle Windsor . Il y en a d'autres, mais je risques déjà une guerre religieuse simplement en mentionnant ces deux. :)
Vous devez utiliser la réflexion. Regardez Assembly.loadfile et Assemblage.load .
Si Vous devez travailler avec des méthodes de classe, vous pouvez l'utiliser comme ceci:
réflexion? Injection de dépendance? Vous rendez la vie difficile pour vous-même!
Compilez contre Microsoft.SharePoint.dll V12 et cela fonctionnera sur 2007.
déployer en 2010 et il «fonctionnera simplement» (dans presque tous les cas) SharePoint 2010 a déjà une configuration de redirection contraignante afin que toute référence à V12 soit redirigée vers la V14. Vous n'avez pas besoin de faire de la configuration sage. Les seules situations où vous devez devenir plus complexe que ce n'est cas où quelque chose fonctionnerait
sur 2007 mais pas sur 2010 (je ne peux pas
penser à quelque chose à la main).
où vous pouvez utiliser des fonctionnalités spécifiques de 2010.
Si tel est le cas, alors ce que je ferais personnellement, c'est à double compiler. Modifiez le fichier .csproj pour produire 2 versions légèrement différentes, utilisez un paramètre et une compilation conditionnelle (tout comme vous le feriez avec #IF Débogage) pour des versions spécifiques au produit du code si nécessaire (très peu d'entre eux). Vous pouvez également utiliser ces conditions dans les références dans .csproj E.g. inconvénients Avantages
Très informatif sur tant de niveaux. J'ai appris 3 nouvelles choses ici! Merci!