Question

Disons que nous avons une solution bien établie dans Visual Studio 2008, en utilisant WSPBuilder pour bundle en un paquet. Il a une poignée de fonctionnalités et tout un tas d'actifs à déployer (.webpart, .xsl, .js, images, colonnes de site, les types de contenu, etc.) aux deux bibliothèques de collections de sites et la ruche 12.

Que proposeriez-vous l'approche devrait être pour aller à 2010?

J'ai un sentiment étrange que les dossiers SPI (aussi belle que pour les gérer Module éléments) vont être assez occupé et difficile à gérer dans une solution VS2010 avec plusieurs fonctionnalités dans le seul projet. Alors, seriez-vous toujours utiliser WSPBuilder, et votre 14 / TEMPLATE / FEATURES / hiérarchie etc dossier dans le projet?

De plus, je déteste les surfaces effroyablement de conception « Solution » et « Feature », particulièrement lorsque vous avez une solution VS2010 avec plusieurs projets, chacun avec une poignée de fonctionnalités.

Quelqu'un d'autre a l'expérience avec moyenne et-up VS2010 solutions encore?

De plus. L'hypothèse est que la solution 2010 sera déployée à la ferme

Était-ce utile?

La solution

WSPBuilder dans CKS: Outils de développement Extension Edition pour VS2010. http://cksdev.codeplex.com/

PS. Doit avoir cette extension pour le développement SP.

Autres conseils

Nous avons fait une migration récente 2007 à 2010, projet de taille moyenne (webparts Silverlight, autres WebParts, de 30 WFC, images, js, DEFINITIONS liste, récepteurs de fonction et beaucoup plus). Nous avons converti toutes les webparts à WebParts visuels (nous avons déterminé Solution Farm est ok), y compris les conventions d'espace de noms. (Nous avons dû webparts recréer dans la publication de pages cependant). Nous avons également utilisé la capacité Dossier SP Carte de VS2010 pour ajouter des dossiers, Layouts Images. Notre ancien code était codé en dur 12 HIVE répertoires, nous les avons modifiés pour utiliser 14 HIVE via appSettings. nous avons décidé également de regrouper en une seule fonction.

J'utilise trois extensions - SP Power Tools, productivité Outils électriques et PowerCommands pour VS2010. Je ne me WSPBuilder plus, mais utilise la fonctionnalité intégrée de VS 2010. Déployez très utile.

Mon équipe a converti un grand projet de constructeur de SP2007 WSP à SharePoint 2010. Quelques choses importantes à retenir, surtout si vous mettez à niveau la base de données de contenu sharepoint ainsi:

Lors de la recréation des caractéristiques oubliez pas d'utiliser la même caractéristique ids.

Ne modifiez pas les noms, l'ensemble des espaces de noms pour des choses comme webparts et EventReceivers et d'autres choses qui sont référencés dans la base de données.

Ne pas modifier l'emplacement de déploiement pour artifatcs sharepoint. Sauf si vous voulez écrire une fonction de mise à niveau des éléments définissant nouvel emplacement des fichiers requis, peut être douloureux si grand projet.

Utilisez l'élément de projet sharepoint correct lors de la recréation. Dans le cas contraire, la fonctionnalité spécifique peut être absente de Visual Studio pour cet élément du projet.

Dans la plupart des cas, le flux de travail suivant fonctionne très bien. Créer un nouveau poste webpart dans VS2010 -> remplacer ids, fichiers d'éléments et le code de projet WSP 2007 -.> Faites quelques coups secs

Avec CKS-Dev et VS2010 l'expérience de développement est grand.

J'ai migré une solution avec plus d'une caractéristique et certains actifs déployés dans les mises en page dossier de 2007 à 2010. Je suis satisfait de l'expérience de la boîte dans Visual Studio 2010 après que je m'y suis habitué. La migration était un peu plus manuel que prévu au premier abord, mais dans l'ensemble, pas trop complexe. Je recommande de commencer la migration avec la sortie des outils boîte pour aider à construire la familiarité avec eux. Cela pourrait réduire votre dépendance à l'avenir sur les outils tiers qui peuvent ne pas mettre à jour ou bien être maintenu ainsi que des outils complets pris en charge MS.

Licencié sous: CC-BY-SA avec attribution
Non affilié à sharepoint.stackexchange
scroll top