Dans notre solution dans VS2012, nous avons plusieurs applications Web qui nécessitent tous JavaScript. Nous avons développé une application à une seule page à l'aide de Kendo UI de Telerik pour MVC4 ASP.NET en combinaison avec JQuery et Typescript.
En raison des multiples applications Web, nous avons créé beaucoup de dossier redondant et donc JavaScript. La modification du code est une traînée. Nous devons synchroniser tout le code de toutes les applications Web tout au long de l'heure et qui est gênant de dire le moins.
J'ai enquêté sur plusieurs solutions à ce problème et je suis venu vide. Voici quelques-uns des scénarios que j'ai enquêtés:
Liens dans Visual Studio
On peut faire glisser tout un «dossier» d'un projet à un autre détenant la touche Alt. Cela provoque des liens dans ce projet de destination pour tous les fichiers du projet source. Cela fonctionne bien à l'intérieur de Visual Studio pour l'édition. Le problème ici est que, à l'exécution, l'application nécessite les fichiers pour être dans l'emplacement sur disque à l'intérieur de la hiérarchie de l'exécution de l'application Web. Parce qu'ils sont des liens vers un autre emplacement, le serveur ne peut pas trouver les fichiers.
déposé cette solution.
avec la commande 'mklink' sous Windows, on peut créer des "liens symboliques". Cela fonctionne comme un charme dans Visual Studio. On peut ajouter les répertoires existants (symboliques) dans Visual Studio en les faisant glisser de l'explorateur de fichiers dans l'arborescence de l'application Web. Vous pouvez ensuite modifier les fichiers et les modifications sont immédiatement reflétées dans l'emplacement d'origine. Nous avons eu les projets courants avec cela et avons pensé que nous avons eu la solution à notre problème jusqu'à ce que nous voulions vérifier cela dans Subversion. Subversion pense que c'est un vrai dossier et essaie de vérifier les fichiers avec les informations de version à partir de l'emplacement d'origine. Après plusieurs heures frustrantes d'essai et d'erreur, j'ai également abandonné cette solution. Nous avons essayé des liens symboliques et des points de jonction, mais dans les deux cas, nous ne pouvions pas obtenir cela pour travailler.
déposé cette solution.
J'ai également examiné la solution utilisée dans les applications ASP.NET à l'aide de WeBresources.ASXD en combinaison avec JavaScript sous forme de ressources immentées. Nous avons également laissé tomber l'un aussi parce que, défini de la complexité accrue, cela augmenterait trop notre temps de retournement pendant le développement. Nous devrions construire la solution pour chaque changement de fichier JavaScript afin que nous perdions les possibilités de montage très rapide que nous avons maintenant. Nous pouvons maintenant simplement modifier un JavaScript, le sauvegarder sur le disque et rafraîchir le navigateur pour que les modifications deviennent actives.
L'option ci-dessus, nous avons le mieux aimé, c'est la seule avec les liens symboliques, mais nous n'avons pas trouvé de travail sur les problèmes de subversion avec celui-là.
4 Réponses :
Avez-vous envisagé de créer un package Nuget pour votre JavaScript? C'est une bonne façon de gérer les dépendances et vous pouvez Créer un local nourrir pour cela.
Si vous utilisiez GIT pour le contrôle de la version, j'aurais pu suggérer d'utiliser des sous-modules à la place. Afaik SVN n'a pas d'équivalent. Correction: voir la réponse de @ Bahrep.
Si nous utilisons Nuget, devrions-nous créer un package sur chaque changement de fichier JavaScript?
Non, vous n'êtes pas obligé, vous pouvez utiliser les mécanismes de version de Nugeing pour la gérer et avoir des forfaits générés dans le cadre de votre processus de construction.
Nous devrons donc construire la solution sur chaque changement à un fichier JavaScript?
Ce que je ferais, c'est avoir une solution séparée pour les composants / bibliothèques javascript communs, puis dans votre application, il vous suffit d'exécuter le package de mise à jour pour obtenir les modifications.
Nous perdrions toujours l'édition rapide de Thypscript (JavaScript) que nous avons maintenant décrit dans ma question. Nous ne voulons pas que le temps d'articulation du tour s'aggrave. Mais c'est une nouvelle façon de regarder les choses, merci pour cela.
Vous pouvez configurer MSBuild pour mettre à jour automatiquement les packages Nuget et les publier sur la construction. Pour un développeur, il peut publier avec un référentiel de Nuge local, puis une fois enregistré, une construction de livraison continue pourrait publier à un référentiel central.
Si vous souhaitez avoir des références liées à Symlink dans le référentiel Subversion, vous devez certainement envisager De cette façon, vous pouvez créer des liens vers votre code commun. svn: externals :
Merci de votre suggestion, j'ai lu des opinions contradictoires sur SVN: externes. Certains disent que c'est de bons autres disent que c'est une solution problématique. Je vais jeter un coup d'œil à cela moi-même.
Je suis dans le même bateau et svn externes a résolu mon problème de la réutilisation de ma propre grande bibliothèque JavaScript entre plusieurs projets. J'ai aussi essayé les mêmes méthodes que vous écoutez dans la question.
@Paulsinnema - SVN: Les extérieurs sont une solution parfaitement bonne pour 2-3 projets de petit à moyennes qui doivent partager du code. Il devient difficile de contrôler le développement et la dépendance une fois que vous commencerez à l'utiliser pendant plus de 5 projets dans lesquels les développeurs de tous les projets peuvent y apporter des modifications. Mais cela posera un problème pour tout mécanisme de partage de dépendance. Je pense que c'est le point où vous devez avoir une équipe de technologie interne dédiée.
Essayé la solution svn: externals mais c'est une traînée. Nous devons enregistrer dans le répertoire source et consulter dans le répertoire de destination chaque fois que nous effectuons un changement.
@Paulsinnema Vous pouvez faire SVN Update pour obtenir les modifications requises.
Nous avons eu un problème similaire, sauf que nous génèverons un fichier dossier à partir d'un modèle T4 dans un projet et si vous avez besoin de ce même fichier à référencer dans notre projet Web. Nous avons essayé des fichiers liés et avons eu le même problème.
Qu'est-ce que nous avons fini par faire consiste à utiliser un événement pré-construction à simplement xcopy le fichier d'un dossier à un autre. Maintenant, nous utilisons TFS, qui vérifiera automatiquement le fichier de destination lors de la copie. Nous avons les deux fichiers sous contrôle source, qui est un peu des déchets, mais le bénéfice du partage du code l'emporte sur ce cas. Votre kilométrage peut varier.
Le problème avec la solution XCopy est celui-ci, il faut construire toujours pour que les fichiers copiés.
Vrai. Nous le faisons dans un environnement CI où nous construisons toujours toute la solution. S'il est nécessaire d'obtenir les fichiers en dehors d'une version CI, nous devrions copier manuellement les fichiers. Je n'ai pas encore rencontré ça, mais je pouvais voir cela comme une limitation.
question intéressante, je sais que je suis à la fin de la fête, mais voici mon problème.
Créer un projet TS avec tout votre code commun Publier en tant que package NPM au serveur NPM privé (si vous ne voulez pas que ce soit public) sinon, vous pouvez toujours le publier à la NPM publique.
Ceci est un complexe bit et comporte de nombreuses pièces mobiles, telles que la création et la gestion d'un serveur NPM privé ni en achetant une, à la mise à jour de vos modules NPM dans le projet comme si nécessaire, mais je suppose que cela ferait le tour
Gardez un référentiel séparé pour vos fichiers TS / JS, hôte et où vous le souhaitez, mettez un lien à ce déploiement JS.
Je ne peux pas croire que notre équipe est la seule équipe du monde entier face à ce problème.
Qu'en est-il d'une commande post-build? J'ai plusieurs projets de script qui génèrent des fichiers JS dynamiques que je tombe dans plusieurs projets dans ma solution.
Seule équipe disposée à poster cela publiquement? :) J'aime l'idée de créer une bibliothèque JS puis de le laisser tomber dans chaque projet.