TFS 2008, supprimer le fichier du contrôle de source mais le laisser dans le projet

Question

Nous utilisons la suggestion de Scott Hansleman pour plusieurs web.configs de son article here. Le problème que nous avons est que nous devons vérifier le Web.Config. Si on le supprime du projet, quand on publie, aucun web.config n'est poussé. Nous devons donc supprimer les liaisons de contrôle de source uniquement à partir de web.config, mais les laisser dans le projet et garder le reste du projet sous contrôle de source.

Le problème est que le contrôle de source rend le fichier en lecture seule jusqu'à ce que vous l'extrayiez. Nous devons être en mesure de l'écraser avec les événements de pré-construction, de préférence sans avoir à le vérifier. Est-il possible de supprimer les liaisons de ce fichier uniquement et de le laisser dans le cadre du projet?

Merci.

Answer 1

En ajoutant un nouveau fichier à l'explorateur de solution, vous obtiendrez le petit signe plus indiquant qu'il doit être ajouté au contrôle de la source. Ensuite, faites un clic droit et choisissez "Annuler les modifications en attente". Cela annulera l'ajout mais laissera le fichier dans votre projet.

Si cela ne fonctionne pas, je suggère l'une des méthodes suivantes:

• Utilisez la tâche Attrib du projet MSBuild Community Tasks pour enlever lecture seule drapeau.
• Utilisez Exec task dans MSBuild pour appeler tf.exe et de récupérer le fichier.

Answer 2

Vous devez laisser le fichier dans le contrôle de code source. Sinon, vous rencontrerez plusieurs problèmes:

• Les modifications ne seront pas versionnées. dit nuf.
• il ne peut pas être ramifié ou fusionné, même si web.config est l'un des fichiers les plus susceptibles de varier entre les environnements de développement/test/production parallèles
• Les modifications que vous effectuez localement ne seront pas propagées aux collaborateurs sans manuel solutions de contournement
• Les développeurs qui configurent un environnement pour la première fois ne recevront pas le fichier
• Team Builds ne contiendra pas le fichier, donc vos déploiements ne le seront pas non plus. (vous ne déployez sûrement pas directement à partir du bureau?!)

Notez que l'état des fichiers individuels est entièrement stocké sur le serveur TFS. ('tf properties' renvoie cette métadonnée si vous êtes curieux) Seuls les projets & ont des liaisons réellement écrites dans le fichier. Et même ce sont des entrées factices qui disent à VS "ne vous inquiétez pas pour moi, il suffit de demander à TFSProvider, je saurai qui je suis et où je suis supposé être." Bien qu'il y ait beaucoup d'autres bizarreries dans le système de projet VS qui me donnent des maux de tête sans fin, dans ce cas, c'est votre ami. Ne le contournez pas.

meilleures options:

1. Modifier votre script de compilation pour activer l'attribut lecture seule avant/après modification. Si vous utilisez le script "copyifnewer.bat" à partir de l'article de blog lié, il devrait littéralement être une ligne supplémentaire. Même si vous voulez garder les choses entièrement déclaratives dans le makefile MSBuild, il n'y a pratiquement aucun travail avec l'aide de 3rd party tasks.Utilisez la fonction Fichier -> Contrôle de source -> Exclure. Après avoir appliqué ce paramètre, le fichier reste sous le contrôle de la source, mais ne sera plus soumis à des vérifications/vérifications automatiques par la solution active. En d'autres termes, vous pouvez éditer le fichier localement au contenu de votre coeur sans affecter personne d'autre, mais si vous voulez commettre (ou mettre en veille) vos modifications, vous devez le faire depuis Source Control Explorer ou la ligne de commande.

L'option 1 a l'avantage d'être une solution très rapide pour votre installation existante. L'inconvénient vient du maintien de plusieurs copies de web.config. * La même raison pour laquelle copier/coller du code est mauvais: si vous en changez un, vous devez aller changer tous les autres - ou pire, oubliez et laissez-les désynchroniser jusqu'à bugs étranges vous forcent à revoir le problème. Cela pourrait être amélioré en changeant le processus pour qu'il y ait seulement 1 web.config "maître" et les copies additionnelles ne contiennent que des différences (via un moteur de diff textuel, des transformations XSLT, une manipulation programmée dans Powershell, etc.). Bien sûr, c'est plus de travail.

L'option # 2 évite les problèmes # 1 avec très peu de frais généraux. (le processus d'ingénierie lui-même est inchangé, seule la différence est le comportement de l'interface utilisateur de Visual Studio) Cet avantage est essentiel si vous modifiez fréquemment web.config. Inconvénient est qu'il n'y a pas de façon intégrée de suivre les variations sur le fichier "maître". Si les seuls diffs sont simples, par exemple une chaîne de connexion ou deux, vous trouverez peut-être plus facile de coller avec un seul "maître" et de laisser les gens faire des changements ad hoc sur leurs machines dev. Il existe même des outils pour le faire pour vous, tels que Web Deployment Projects (facile) et le IIS Deployment Tool (complexe). Dans tous les cas, votre déploiement réel devrait être automatisé et contrôlé à la source, bien sûr! Si des personnalisations plus lourdes sont requises que ces outils ne le permettent, vous aurez probablement besoin de l'approche hybride master + transform décrite plus haut.