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.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
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.
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.
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
"Jean BONBEUR" a écrit dans le message de news:
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" <jean.bonbeur@snak.bar> a écrit dans le message de news:
eNcEwA99HHA.4784@TK2MSFTNGP05.phx.gbl...
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?
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
> 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 ?
> 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 ?
> 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
"Jean BONBEUR" a écrit dans le message de news: 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" <jean.bonbeur@snak.bar> a écrit dans le message de news:
OWsysdP%23HHA.484@TK2MSFTNGP06.phx.gbl...
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" a écrit dans le message de news: 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
> 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.
> 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.
> 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.
