2010-12-13 3 views
6

Malheureusement, c'est presque toutes les informations que j'ai en ce moment.Le complément Visual Git 208 ne fonctionne pas sous Windows 7/Visual Studio 2010

Le programme d'installation Git Extensions 208 fonctionne très bien, la configuration de Git extensions valide bien, avec le vert pour tous les paramètres, Git visuels ouvre bien avec Visual Studio 2008.

Mais, d'entrer dans Visual Studio 2010 me donne une dialogue:

The Add-in 'Visual Git' failed to load or caused an exception. 
Would you like to remove this Add-in? 
If you choose yes, the file it was loaded from, 
'\\myFileServer\home\myUserName\Visual Studio 2010\Addins\GitPlugin.AddIn', 
will be renamed. 

Error Message: <Unknown Error> 
Error number: 80131515 

[Yes] [No] 

Visual Git échoue ensuite à charger.

Le problème est-il que les fichiers Visual Git sont hébergés à partir d'un serveur de fichiers? C'est tout ce que je peux penser qu'il pourrait être ...

Quelqu'un at-il déjà vu/résolu cela?

EDIT: Avant que quelqu'un ne le demande, le titre ne contient pas une faute de frappe "2008". Git Extensions prétend travailler avec VS2005/2008/2010. Le fait que ce soit aussi à la version 208 est une coïncidence, autant que je sache.

+0

Avez-vous essayé de rechercher ce code d'erreur? 80131515? - http://www.tech-archive.net/Archive/DotNet/microsoft.public.dotnet.framework.interop/2004-02/0390.html - 'CreateObject: renvoie l'erreur 80131515 (Le chemin donné > format n'est pas supporté) ' –

+0

C'est probablement ça. Je vais soulever le problème sur la page de développement et voir ce qui en sort. – Frosty840

Répondre

13

J'ai rencontré ce problème, mais j'ai trouvé une solution. Je cours Visual Studio dans une machine virtuelle sur mon MacBookPro. J'utilise Parallels pour exécuter la machine virtuelle. En raison de la façon dont Parallels fonctionne, mon dossier de documents est en fait un partage réseau pointant vers MacOSX. Et apparemment Visual Studio 2010 n'aime pas les partages réseau pour les addins par défaut.

On dirait que c'est le problème que l'OP a rencontré en regardant son message d'erreur.

Pour le faire fonctionner, vous devez ajouter l'élément loadFromRemoteSources (see the MSDN reference) à la « C: \ Program Files \ Microsoft Visual Studio 10.0 \ Common7 \ IDE \ devenv.exe.config »:

<configuration> 
    <runtime> 
     <loadFromRemoteSources enabled="true"/> 
    </runtime> 
</configuration> 

Je l'ai fait et il a immédiatement chargé et a commencé à travailler.

BTW, pleine attribution: J'ai trouvé la solution here.

+0

Cela a également fonctionné pour moi. Merci d'avoir posté le correctif! –

+0

Merci! J'avais déplacé le complément à "Mes documents" (non partagé avec le Mac) mais c'est plus propre. –

2

Cela n'a pas fonctionné pour moi jusqu'à ce que je regardais les commentaires ici: http://msdn.microsoft.com/en-us/library/dd409252.aspx

Sous Vista ou Windows7 prendre soin de thefile système de virtualisation. L'édition de devenv.exe.config peut entraîner la création d'une copie sous

\ Users {% UserName%} \ AppData \ local \ VirtualStore \ Program Files (x86) \ Microsoft Visual Studio 10.0 \ Common7 \ IDE \ devenv.exe .config

en laissant le fichier d'origine intact. Cela dépend de vos paramètres utilisateur. Il pourrait aider à ouvrir « VS 2010 en tant qu'administrateur » (ou un autre éditeur XML de votre choix), modifier devenv.exe.config, insérer le

tag

, enregistrez le fichier et fermer. Cela va modifier le fichier original, pas la copie virtualisée. avoir fait référence à des ensembles « à distance » dans vos projets devraient travailler

1

Pour ceux qui ne peuvent pas se rendre à Henk's link ci-dessus: La question (pour les futurs Googlers) est que l'extension Git ne fonctionne pas s'il est exécuté à partir un chemin UNC (\\server\some\path) et doit être installé dans un répertoire local. Vous pouvez ajouter un répertoire local via le menu Outils> Options> Environnement> Complément> Sécurité de la macro.

1

Ma solution était de remplacer le dossier Addins (qui était réseau distant) avec un lien symbolique vers un dossier local en utilisant mklink. Cela fait effectivement la même chose que David Moles a suggéré.

Questions connexes