Les taupes 0.94.51023.0 erreur sur visual studio 2010 SP1

Question

Je suis en train de mole Système.ServiceModel v4 VS 2010 SP1 avec les Taupes 0.94.51023.0 et je reçois l'erreur suivant:Le type ou le nom d'espace de noms 'IHttpCookieContainerManager" n'existe pas dans l'espace de noms 'ssm::System.ServiceModel.Canaux (vous manque une référence d'assembly?) [mon-test-projet.Test\obj\Debug aupes\ssm\m.g.csproj] mon-test-projet.Test\m.g.cs 293022 43

Cette interface semble avoir été retiré de System.ServiceModel.dll dans .NET 4.0 que je ne peux que le trouver dans System.ServiceModel.dll v2.0.5.0 (Silverlight) quand je fais une recherche dans l'explorateur d'Objets.

Je suis en mesure de reproduire ce via le cmdline à l'aide de moles.exe et j'ai essayé de modifier les grains de beauté fichier seulement de générer des noms de type I préciser mais il ne semble pas faire de différence.Cela fonctionnait bien avant ma mise à niveau de VS2010 SP1, donc je suppose que c'est un bug, mais toute aide serait appréciée.

Merci Nick

Answer 1

J'ai également évoqué cela seul et j'ai constaté que la cause première semble être que VS2010 SP1 (et le Mise à jour de gdr KB pour .NET 4 ) Mettez à jour un ensemble de DLL mais pas une autre:

the system.servicemodel.dll in% programfiles (x86)% \ assemblages référencés \ ne correspond pas à celui de l'installation .NET V4 à% windir% \ microsoft.net \ framework64 \ v4.0.30319 ...

POST VS 2010 SP1 Mise à jour:

% Fichiers du programme (x86)% \ assemblages de référence \ Microsoft \ Frader.netframework \ v4.0 \ system.servicemodel.dll -> Version du fichier 4.0.30319.1

% Windir% \ Microsoft.net \ Framework64 \ V4.0.30319 \ System.ServiceModel.dll -> Version du fichier 4.0.30319.225

Comparaison de ces deux DLL dans le navigateur d'objets dans VS ainsi que dans le réflecteur donne le résultat que l'interface IHTPCOOKIECONTAINERMANAGER a été supprimée dans le fichier plus récent. Je soupçonne donc que ceci est une combinaison de sondage .NET trouver la nouvelle DLL et les moles qui se réfléchissent sur l'aînant lorsqu'ils font une génération de mole / talon. J'ai pu générer manuellement une dll de moles pour la DLL plus récente en exécutant manuellement les taupes exe sans chemins de référence de quelque nature que ce soit, par opposition à la cible Msbuild qui ajoute une bouquet de chemins de référence lors d'une construction.

Answer 2

Je ne sais pas pourquoi qui se passe, mais j'ai eu le même problème, et je l'ai résolu en utilisant les Taupes type de filtres, et seulement, y compris ceux que j'ai vraiment besoin (qui a le bel effet d'accélérer la compilation beaucoup!!).C'est un exemple .moles le fichier que j'utilise:

<Moles xmlns="http://schemas.microsoft.com/moles/2010/">
  <Assembly Name="System.ServiceModel"/>
  <StubGeneration>
    <Types>
      <Clear/>
      <Add Namespace="System.ServiceModel.Description!"/>
    </Types>
  </StubGeneration>
</Moles>

Answer 3

On dirait qu'il s'agissait d'un conflit entre les assemblages système et système.ServiceModel que Moles utilisait pour la compilation.

J'avais récemment installé le Microsoft .NET Framework 4.5.

Après la désinstallation et réinstallez 4.0 Tout a fonctionné.

Answer 4

Eh bien, au cas où tout le monde travaille avec le code hérité et qu'il se trouve être coincé à utiliser Microsoft Moles, j'ai effectué de nombreux creux sur ce sujet et j'espère sauver certaines de la colère et de la frustration que j'ai rencontrées.

J'ai essayé d'utiliser la suggestion de la réponse acceptée, ce qui signifiait aller dans le répertoire Moles (dans C: \ Program Files ..) et exécuté l'utilitaire de ligne de commande (moles.exe) en tant qu'administrateur. Il y a beaucoup d'options, dont l'une vous permet d'inclure des assemblages référencés (comme suggéré ci-dessus).

Cependant, même lorsque vous essayez d'exécuter l'utilitaire sans assemblages référencés, l'utilitaire appelle finalement le compilateur C # (CSC.EXE) avec des chemins d'assemblage référencé prédéfinis, ce qui est là que je conclus que la confusion entre les versions .NET se produit. . Je ne pouvais pas l'obtenir pas pour inclure ces chemins d'assemblage.

Mon scénario spécifique était que j'essayais de taire une assemblée personnalisée, cependant parce que, apparemment, j'avais .net 4.5 installé sur cette machine, il s'est plaint de la compilation sur System.Collections.Generics Ireadonlycollection, IrlonlyDictionary, et je pense un autre.

solution : la solution seule que je dois travailler était d'utiliser des filtres à mole, que je lis sur les autres postes et sur le site Web Microsoft Moles (il y a une spéciale Lien pour .NET 4.5 Dépannage sur la page principale). Dans Visual Studio, j'ai simplement ajouté l'assemblage Moles à mon projet de test de mon appareil pour mon assemblage personnalisé référencé via le clic droit dans l'explorateur de solutions. J'ai ensuite essayé de construire. Pour chaque erreur que j'ai reçue, j'ai noté les classes d'incrimination et les exclues d'être bouleversé ou basculé en ajoutant ce qui suit au fichier Moles:

<Moles xmlns="http://schemas.microsoft.com/moles/2010/">
  <Assembly Name = "MyCustomAssembly" />
  <StubGeneration>
    <Types>
      <Remove TypeName="ClassThatUsesIReadOnlyCollectionEtc" />
    </Types>
  </StubGeneration>
  <MoleGeneration>
    <Types>
      <Remove TypeName="ClassThatUsesIReadOnlyCollectionEtc" />
    </Types>
  </MoleGeneration>
</Moles>

Maintenant, cela ne va pas fonctionner si vous besoin les classes que vous excluez de la génération de tautrie / stub, mais pour mon cas, cela a fonctionné bien parce que les classes incriminées n'étaient pas importantes et je ne voudrais pas Ne doit pas avoir besoin de supporter quelque chose dans ces classes.