L'emplacement du projet n'est pas approuvé

Le
SL3News
Bonjour,
J'utilise Visual Studio 2005 version Standard.
Je veux travailler sur une solution se trouve sur un PC distant du réseau
local. Le dossier contenant la solution est bien partagé avec les droits
nécessaires.
Par contre, lorsque je lance cette solution, Visual Studio 2005 me donne le
message suivant :
<<L'emplacement du projet n'est pas approuvé.
L'exécution de l'application risque de générer des exceptions de sécurité
lors de l'exécution d'actions qui exigent une confiance totale. >>

Que faire pour exécuter correctement une solution se trouvant dans un
dossier partagé via le réseau local?
Merci d'avance pour vos contributions.
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Jean BONBEUR
Le #12176981
ne pas faire.

utiliser plutot un gestionnaire de sources, genre SVN, qui va se charger de
ramener la solution sur votre machine, et la, vous modifiez et testez, et
renvoyez vos modifs vers le server. c'est multi-user, c'est traçable, c'est
propre... et ça vous evitera ce message.
SL3News
Le #12176881
"Jean BONBEUR"
ne pas faire.

utiliser plutot un gestionnaire de sources, genre SVN, qui va se charger
de ramener la solution sur votre machine, et la, vous modifiez et testez,
et renvoyez vos modifs vers le server. c'est multi-user, c'est traçable,
c'est propre... et ça vous evitera ce message.



Merci pour votre réponse.
Il me semble que le gestionnaire de source ne me permettra que de faire
automatiquement ce que je fais déjà manuellement actuellement?
Jean BONBEUR
Le #12176871
> Merci pour votre réponse.
Il me semble que le gestionnaire de source ne me permettra que de faire
automatiquement ce que je fais déjà manuellement actuellement?



Et ainsi, on ouvre plus la solution sur la machine distante, mais sur sa
machine. on bosse en local, et tout le monde profite des modifs que vous
commitez. ça évite de se poser ce genre de question, et offre des avantages
immenses par rapport à l'approche repertoire partagé (historisation,
traçabilité, branches, versioning..., les modifications locales ne
perturbent pas les autres... ). donc, même si on est seul à bosser sur le
projet, ça peut être un gain appreciable.

ou alors je n'ai rien compris à votre probleme. vous ouvrez bien directement
la solution sur la machine distante, c'est bien ça ?
SL3News
Le #12176851
"Jean BONBEUR" OWsysdP%
Merci pour votre réponse.
Il me semble que le gestionnaire de source ne me permettra que de faire
automatiquement ce que je fais déjà manuellement actuellement?



Et ainsi, on ouvre plus la solution sur la machine distante, mais sur sa
machine. on bosse en local, et tout le monde profite des modifs que vous
commitez. ça évite de se poser ce genre de question, et offre des
avantages immenses par rapport à l'approche repertoire partagé
(historisation, traçabilité, branches, versioning..., les modifications
locales ne perturbent pas les autres... ). donc, même si on est seul à
bosser sur le projet, ça peut être un gain appreciable.

ou alors je n'ai rien compris à votre probleme. vous ouvrez bien
directement la solution sur la machine distante, c'est bien ça ?



Vous avez bien compris mon problème. Effectivement j'ouvre bien la solution
sur la machine distante.
Par contre, je ne sais pas trop comment le gestionnaire de source arrive à
s'en sortir lorsque deux utilisateurs modifient en-même temps un fichier
source. Bref, je suppose que cela fait partie de son travail.
Jean BONBEUR
Le #12176751
> s'en sortir lorsque deux utilisateurs modifient en-même temps un fichier
source. Bref, je suppose que cela fait partie de son travail.



vous supposez parfaitement.

le comportement est souvent parametrable, et on retrouve souvent les memes
variantes :
- empecher d'ouvrir le fichier si quelqu'un d'autre le possede déja. on
négocie avec la personne pour qu'elle archive ses modifs. c'est un peu
violent, tres strict, et pas toujours utile.
- ouvrir le fichier, tel quel, et au moment d'archiver avertir si quelqu'un
a fait des modifs que vous ecraseriez si vous faisiez un save violent. la,
on merge dans un outils approprié pour intégrer vos modifs dans le nouveau
source. en gros, ça fait le differentiel par rapport à l'original que vous
aviez, pour déduire ce qui est ajouté, supprimé, modifié, et ça essaye
d'appliquer les modifs sur le fichier du server qui a subi d'autres modifs,
tout ça dans un editeur qui attend vos choix, pour comiter le résultat.

pour conclure, justement, le gestionnaire de sources va vous permettre de
bosser à plusieurs car il résoud proprement les problemes de concurrence
d'acces, ce que ne fait pas un éditeur de texte qui save comme une brutasse.
voila voila... c'est sans compter avec les branches et les labels, concepts
dont vous allez certainement vite tirer parti quand vous les decouvrirez.

Cordialement,

--
Frédéric DIDIER
Architecte .Net
SQLI Montpellier
Publicité
Poster une réponse
Anonyme