Conserver des projets Visual Studio sur un lecteur réseau
Nous venons de stocker 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 de 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?
Donc, mon VS est installé localement. Les fichiers sont sur un lecteur réseau. Comment puis-je obtenir que cela fonctionne?
EDIT: Je sais ce qui DEVRAIT être fait, mais y at-il un pansement que je peux mettre tout de suite pour résoudre ce problème et assurer la maintenance du lecteur réseau?
EDIT 2: Je suis sûr 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.
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 que se rende à SC, alors vous pouvez.
Pour que les projets s'exécutent correctement avec la permission appropriée, 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. Supposons que vous mappiez sur "N: \", puis utilisez "N:\*" comme modèle d’URL. Ce n'est pas évident que vous ayez besoin d'un joker, mais c'est le cas.
La question est plutôt générique, je vais donc répondre à un problème auquel je faisais face.
J'exécute 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 Assembly des projets à partir de là. Essayer de définir les droits avec "caspol" 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, c’é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 la section xml "<runtime>", 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:
Faire confiance aux partages réseau avec Visual Studio 2010/.NET Framework v4.0
Le 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 retrouver mal à l'aise.
Si vous êtes habitué à utiliser 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 également 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. Les performances vont par la fenêtre. Pour ce qui est de le faire fonctionner, il 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, placez vos canards dans une rangée avant de configurer un tel environnement de développement.
Je comprends que c’est un fil plus ancien, 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 (avec 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; Fait 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 le nom UNC, démarrez des applications à partir de cette console, puis fermez la console, des problèmes pourraient survenir dans les applications démarrées à partir de cette console.
J'ai trouvé cette information à l'adresse: 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 un exemplaire de VB 2008 (récemment mis à niveau à partir de VB6). Si je stocke mes solutions sur le lecteur réseau sauvegardé, aucune tâche ne sera exécutée. Il donne des erreurs "appelant partiellement de confiance" pour accéder à un module, même lorsque "autoriser les appels partiellement confiants" est défini dans l'assembly. Si je stocke les fichiers sur mon 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 formulaire.
-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?
Donc, j'avais 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 concerne probablement le contexte de l’administrateur, mais un moyen de le résoudre, que j’ai trouvé 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 et à accéder à 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 et cette réponse est donc 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 sont situés sur des lecteurs locaux, les assemblys référencés sont créés 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: Étant donné que NET 4.0 ne fournit plus automatiquement un bac à sable pour les assemblages réseau, vous devez les mettre en confiance complète via la mise à jour de machine.config. http://msdn.Microsoft.com/en-us/library/dd409252.aspx
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 plus d'une personne à 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'ai trouvé cela utile en essayant d'utiliser vc11 avec des parallèles qui fonctionnent sur mac: http://social.msdn.Microsoft.com/Forums/en-US/toolsforwinapps/thread/2ffdcb01-c511-4961-834b- afd5f2fbb8e1 et plus particulièrement:
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.
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.
Autre exemple, si vous utilisez le chemin UNC, vous devez vous assurer qu’ils sont assez courts.
Si je vous ai bien compris, 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 pour ce faire, ou via le menu Outils du panneau de configuration/admin.
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:\Users\Self\Documents \, au lieu du chemin UNC
(Vous devez faire attention, car Visual Studio vous redirigera automatiquement vers le chemin "\\ domain.net .." si vous double-cliquez sur le lien symbolique lorsque vous parcourez le projet.\Users\'chemin pour l’ouvrir avec la lettre du lecteur)
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 à la zone intranet Windows. 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 en cours d'exécution dans ce scénario.