Conserver des projets Visual Studio sur un lecteur réseau
https://stackoverflow.com/questions/159627
-
03-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
Nous venons juste de déplacer tous les fichiers localement sur un lecteur réseau. Le problème est que c'est là que mes projets VS sont également stockés maintenant. (Pas encore de système de gestion des versions, je travaille dessus.) Je sais que j'ai déjà entendu parler de problèmes avec ce procédé, mais je n'ai jamais entendu parler d'une solution de rechange. Y at-il un travail autour?
Mon VS est donc installé localement. Les fichiers sont sur un lecteur réseau. Comment puis-je le faire fonctionner?
EDIT: Je sais ce qu’il faudrait FAIRE, mais y at-il un pansement que je peux mettre tout de suite pour régler ce problème et assurer la maintenance du lecteur réseau?
EDIT 2: Je suis certain de ne pas comprendre quelque chose, mais Bob King a la bonne idée. Quand je rentrerai au bureau, je travaillerai avec le développeur web en chef pour trouver une solution temporaire en attendant que nous ayons une sorte de configuration de contrôle de version. Merci pour les idées.
La solution
Bien que nous utilisions le contrôle de code source, nous exécutons également tous nos projets à partir de lecteurs de réseau (répertoires non partagés, répertoires privés sur des lecteurs de réseau). Les lecteurs réseau sont sauvegardés tous les soirs et utilisent également le cliché instantané des volumes. Par conséquent, si vous devez revenir à quelque chose avant , vous pourrez le faire.
Pour que les projets fonctionnent correctement avec les autorisations appropriées, suivez ces étapes .
En gros, vous devez simplement mapper le répertoire partagé sur un lecteur, puis accorder une autorisation, basée sur cette URL, à tout le code. Dites que vous mappez vers & Quot; N: \ & Quot ;, puis utilisez & Quot; N: \ * & Quot; comme votre modèle d'URL. Il n’est pas évident que vous ayez besoin d’un caractère générique, mais vous le faites.
Autres conseils
La question est plutôt générique, je vais donc donner une réponse à un problème auquel je faisais face.
J'utilise Visual Studio 2010 en utilisant une machine virtuelle Parallels sur mon Mac tout en conservant tous mes projets du côté mac via un partage réseau. Cependant, Visual Studio ne chargerait pas les fichiers d'assemblage de projets à partir de là. Essayer de définir les droits avec & Quot; caspol & Quot; seul n'a pas aidé dans mon cas.
Ce qui a finalement fonctionné pour moi pour permettre à Visual Studio de charger des assemblys à partir d'un partage réseau était de modifier le fichier. " C: \ Program Files (x86) \ Microsoft Visual Studio 10.0 \ Common7 \ IDE \ devenv.exe.config " (en supposant une installation par défaut).
dans le xml " < runtime > " section que vous devez ajouter
<loadFromRemoteSources enabled="true"/>
Vous devrez peut-être modifier les autorisations sur ce fichier pour autoriser l'accès en écriture. Enregistrez le fichier. Redémarrez Visual Studio.
Dans l’intérêt de répondre à la question, j’ai copié ce commentaire de jcarle.com:
Approbation des partages réseau avec Visual Studio 2010 / .NET Framework v4.0
20 janvier 2011 à 16 h 10 Si vous êtes comme moi et que vous stockez tout votre code sur un serveur, vous aurez probablement appris à faire confiance à un partage réseau à l'aide de CasPol.exe. Toutefois, lorsque vous passez de Visual Studio 2008 (.NET Framework 2.0 / 3.0 / 3.5) à Visual Studio 2010 (.NET Framework 4.0), vous risquez de vous perdre la tête.
Si vous utilisez habituellement l'invite de commandes Visual Studio pour accéder rapidement à CasPol, il est possible que certains de vos projets ne semblent pas respecter vos nouveaux paramètres FullTrust. En effet, l'invite de commandes Visual Studio ajoute par défaut le dossier .NET Framework 4.0 à son chemin. Si votre projet est toujours exécuté sous .NET Framework 2.0 / 3.0 / 3.5, il faudra également définir CasPol pour ces versions. Juste une note, j'ai aussi personnellement eu plus de succès avec l'utilisation de 1 en tant que groupe de code au lieu de 1.2.
Pour faire confiance à un partage réseau pour toutes les versions du .NET Framework, appelez simplement CasPol pour chaque version en utilisant le chemin complet, comme ci-dessous:
C: \ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ CasPol -m -ag 1 fichier -url: // YourSharePath * FullTrust
C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ CasPol -m -ag 1 fichier -url: // YourSharePath * FullTrust
Je ne recommanderais pas cela si vous avez (ou même si vous n'en avez pas) plusieurs personnes qui travaillent sur les projets. Vous ne faites que demander des ennuis.
Par contre, si vous êtes le seul à travailler dessus, vous éviterez en grande partie les ennuis. La performance va sortir par la fenêtre, cependant. Pour ce qui est de le faire fonctionner, il vous suffit d'ouvrir le fichier de solution à partir de VS. Vous rencontrerez probablement des problèmes de sécurité, mais pourrez y remédier en utilisant CASPOL. Comme je l'ai dit, les performances vont être terribles. Encore une fois, pas recommandé du tout.
Faites une faveur à votre équipe et installez SVN ou une autre forme de contrôle de source et insérez le code là-bas dès que possible.
EDIT: Je vais retirer partiellement mes commentaires. Bob King explique ci-dessous la raison pour laquelle ils exécutent des projets VS à partir d'un lecteur réseau, ce qui est logique. Je dirais que si vous ne le faites pas pour une raison spécifique telle que Bob, restez à l'écart. Sinon, mettez vos canards en rang avant de configurer un tel environnement de développement.
Je comprends que c’est un ancien fil, mais c’est le meilleur fil que j’ai trouvé en cherchant à résoudre un problème similaire: visual studio 2013 était installé sur une boîte virtuelle (sous Win 8.1) et le code sur la machine hôte (Win 7). ). Même si je pouvais ouvrir la solution, je ne pouvais pas compiler. Toutes les autres réponses à ce sujet concernent des logiciels plus anciens. J'ajoute donc cette réponse pour mettre à jour cette question fréquemment trouvée avec la solution qui a fonctionné pour moi.
Voici ce que j'ai fait; Faites une entrée de registre pour pouvoir utiliser un chemin UNC comme répertoire actuel.
AVERTISSEMENT: une utilisation incorrecte de l'Éditeur du Registre peut générer des problèmes graves affectant l'ensemble du système, pouvant vous obliger à réinstaller Windows NT pour les corriger. Microsoft ne peut pas garantir que les problèmes résultant de l'utilisation de l'Éditeur du Registre puissent être résolus. Utilisez cet outil à vos risques et périls.
Sous le chemin du registre: HKEY_CURRENT_USER \Logiciel \ Microsoft \ Processeur de commandes
ajoutez la valeur DisableUNCCheck REG_DWORD et définissez la valeur sur 0 x 1 (Hex).
AVERTISSEMENT: si vous activez cette fonctionnalité et démarrez une console comportant un répertoire actuel portant un nom UNC, démarrez des applications à partir de cette console, puis fermez la console, des problèmes pourraient survenir dans les applications lancées à partir de cette console.
Ces informations ont été trouvées sur le lien http://support.microsoft.com/kb/156276
Pourquoi ne pas reformuler cette question en une question à laquelle tout le monde peut répondre? J'ai exactement le même problème que l'affiche initiale.
J'ai une copie de VB 2008 (récemment mise à jour depuis VB6). Si je stocke mes solutions sur le lecteur réseau sauvegardé, aucune tâche ne sera exécutée. Cela donne & "; Appelant partiellement de confiance &"; erreurs d’accès à un module, même lorsque " autorise les appels partiellement confiants " est défini dans l'assemblée. Si je stocke les fichiers sur mon disque C :, (non sauvegardé), il fonctionnera à merveille, jusqu'à ce que je le mette sur le lecteur partagé pour que tout le monde puisse l'utiliser, et je reviens au même problème.
Ce n'est pas une grosse demande. Je veux juste pouvoir mettre une solution et un exécutable sur le lecteur partagé et l'exécuter sans absurdité d'absurdités sur la sécurité. Je ne devrais pas avoir à mettre tout mon travail dans des fichiers de formulaires.
-Edit: j'ai trouvé le problème avec pourquoi il ignorait la commande AllowPartialllyTrustedCallers. J'essaie de faire référence à ADODB, ce qui ne permet pas une confiance partielle. Donc, aucun exécutable réseau ne peut accéder à une base de données? Qu'est-ce que Microsoft a de toute façon contre les intranets?
Ne le fais pas. Si vous avez un contrôle de source (gestion des versions), vous ne voulez pas que vos fichiers soient sur un lecteur réseau. Il contourne totalement tout ce que vous souhaitez obtenir en utilisant le contrôle de source, car une fois que vos fichiers sont stockés sur un lecteur réseau, tout le monde peut les modifier .... même pendant que vous construisez votre projet. Ka-boooom!
PS: cela ressemble à un cas typique d'ingénierie excessive pour moi.
Avez-vous des problèmes spécifiques?
Si vous autorisez plusieurs personnes à ouvrir la solution, votre premier problème sera que le fichier .NCB (Intellisense) sera verrouillé exclusivement et qu'un seul utilisateur pourra parcourir l'arborescence de la classe. Et bien sûr, les modifications d’un utilisateur risquent d’écraser les modifications de l’autre utilisateur.
J'avais donc un problème similaire. Visual Studio ne reconnaîtrait aucun emplacement réseau que j'avais mappé pour une lettre de lecteur. La chose amusante est que cela a fonctionné pendant une journée. J'ai monté mon projet et commencé à y travailler sans problèmes. Ensuite, je me suis arrêté et le lendemain, rien ne fonctionne. Je ne pouvais pas lire / écrire des fichiers en code, sortir mes exécutables ou quoi que ce soit. Mon projet est local mais ma sortie était destinée à être projetée sur le réseau.
Quoi qu’il en soit, le problème tient probablement au contexte de l’administrateur, mais un moyen de le résoudre, que j’ai découvert lors de mes recherches en ligne, consiste à faire en sorte que Visual Studio accède au lecteur en question. Il existe de nombreuses façons de le faire, mais VS sera capable de reconnaître comme par magie des lettres de lecteur mappées. Ma solution consiste à définir l’emplacement de sortie du débogage dans les propriétés du projet, à cliquer sur Parcourir, puis sur l’emplacement de sortie précédemment défini sur le lecteur réseau et le tour est joué !!!
Je voulais mettre cela en place parce que j'ai passé une demi-journée à essayer de comprendre cela et que cela pourrait faire gagner du temps à quelqu'un d'autre. Merci beaucoup et bonne chance !!!
Erik
Je faisais face au même problème tout récemment, aussi cette réponse est-elle destinée à garder une trace de mes propres connaissances. Quoi qu’il en soit, si nous trouvons cela utile, voici le problème et la solution.
Problème: Les projets NET 4.0, le référentiel SVN, les dossiers de sortie se trouvent sur des lecteurs locaux, les assemblys référencés sont construits par le serveur de génération et disponibles sur un lecteur réseau. Visual studio sur W7 peut ajouter la référence mais ne peut pas construire de projets.
Solution: Comme NET 4.0 ne fournit plus automatiquement un bac à sable pour les assemblages réseau, vous devez les mettre à jour en toute confiance via la mise à jour de machine.config. http://msdn.microsoft.com/en-us/library/dd409252.aspx
Si je vous comprends bien, vos fichiers de projet Visual Studio sont stockés sur le lecteur réseau et vous les exécutez à partir de cet emplacement. C'est ce que je fais et n'ai aucun problème. Vous devrez vous assurer que vous avez défini la stratégie de sécurité. Vous pouvez utiliser Caspol , ou via le menu Outils du panneau de configuration / admin.
Vous devez être averti que certaines fonctionnalités de Visual Studio refuseront de fonctionner avec un lecteur réseau.
Par exemple, le fichier mdf de l'instance d'utilisateur SQL Express doit se trouver sur le lecteur local.
Pour un autre exemple, si vous utilisez le chemin UNC, vous devez vous assurer qu’ils sont assez courts.
J'ai trouvé cela utile en essayant d'utiliser vc11 avec des parallèles fonctionnant sur mac: http: //social.msdn .microsoft.com / Forums / fr-FR / toolsforwinapps / thread / 2ffdcb01-c511-4961-834b-afd5f2fbb8e1 , et plus précisément:
1) Vous pouvez passer du débogage local au débogage distant et définir le nom de la machine sur 'localhost'. Cela fera un déploiement à distance sur votre machine locale (n'utilisant donc pas le répertoire du projet). Vous n'avez pas besoin d'installer les outils de débogage distant ni de démarrer msvsmon pour que cela fonctionne sur localhost.
Au cas où cela aiderait quelqu'un d'autre, je devais suivre les étapes décrites ici pour ajouter l'emplacement du partage réseau à Windows. zone intranet. En particulier, je rencontrais des difficultés avec le blocage de Visual Studio lors de l’ouverture d’une solution sur un partage réseau (utilisation de VMware Fusion et ouverture d’une solution à partir du disque dur de mon Mac). J'ai également eu des problèmes avec PostSharp dans ce scénario.
J'ai eu un problème similaire lors de l'ouverture de projets Visual Studio sur un lecteur réseau et je l'ai corrigé en créant un lien symbolique sur mon lecteur C: \ local qui pointe vers le répertoire UNC
par exemple
mklink /D "C:\Users\Self\Documents" "\\domain.net\users\self\My Documents"
alors vous pouvez simplement ouvrir le projet en utilisant le chemin C: \ Utilisateurs \ Self \ Documents \, au lieu du chemin UNC
(Soyez prudent, car Visual Studio vous redirigera automatiquement vers le chemin "\\ domain.net .." si vous double-cliquez sur le lien symbolique lorsque vous parcourez le projet. Je devais copier-coller le Chemin 'C: \ Utilisateurs \' pour l’ouvrir avec le chemin de la lettre du lecteur)
& "Comment puis-je le faire fonctionner? &"; Vous avez plusieurs choix:
Choix A: 1. Replacez tous les fichiers sur votre disque dur local 2. Implémentez un type de logiciel de sauvegarde sur votre machine 3. Testez ladite solution de sauvegarde 4. continuer à coder
Choix B: 1. Obtenez une copie de l'un des produits de contrôle de source GRATUIT et mettez-la en œuvre. 2. Assurez-vous qu'il est sauvegardé 3. Testez-le
Choix C: Utilisez l’un des nombreux référentiels de contrôle de source ONLINE disponibles. Google, SourceForge, CodePlex, quelque chose.
Eh bien, ma question serait de savoir pourquoi vous demandez cela. Cela ne fonctionne-t-il pas lorsque vous le stockez sur un lecteur réseau? Je n'ai pas essayé cela moi-même et un problème que je pourrais envisager serait que le code .NET exécuté à partir d'un lecteur réseau (c'est-à-dire du répertoire bin \ Debug, situé également sur le lecteur réseau) s'exécute en mode bac à sable, à moins que vous ne vous amusiez avec CASPOL (ou que vous utilisiez la version 3.5 SP1 qui, à ce que j’entends, a supprimé cet obstacle).
Si vous rencontrez des problèmes spécifiques, posez des questions à ce sujet. Ne jamais demander & "Pourquoi le X ne fonctionne-t-il pas? &";
Vous ne dites pas si vous êtes une ou plusieurs personnes accédant au même lecteur distant, mais je suppose que vous n'êtes qu'un pour chaque répertoire réseau. Est-ce correct? Sinon, non, il n'y a pas de pansement. Obtenez le contrôle de version, replacez les fichiers sur un disque local.
