Moli 0.94.51023.0 Errore su vs 2010 SP1

Question

Sto cercando di molare il sistema. Servicemodel V4 in vs 2010 SP1 con moli 0.94.51023.0 e continuo a ottenere il seguente Error:The type or namespace name 'IHttpCookieContainerManager' does not exist in the namespace 'ssm::System.ServiceModel.Channels' (are you missing an assembly reference?) [my-test-project.TestobjDebugMolesssm mgcsproj] my-test-project.test mgcs 293022 43

Questa interfaccia sembra essere stata rimossa da System.servicemodel.dll in .NET 4.0 in quanto posso trovarlo solo in System.ServiceModel.dll v2.0.5.0 (Silverlight) quando cerco nel browser oggetto.

Sono in grado di riprodurlo tramite CMDLINE usando moles.exe e ho provato a modificare il file mole per generare solo nomi di tipi che specifico, ma non sembra fare alcuna differenza. Funzionava bene prima del mio aggiornamento a VS2010 SP1, quindi sospetto che sia un bug, ma qualsiasi aiuto sarebbe apprezzato.

Grazie Nick

Answer 1

Ho debug questo anche da solo e ho scoperto che la causa principale sembra essere VS2010 SP1 (e il relativo Aggiornamento GDR KB per .NET 4) Aggiorna un set di DLL ma non un altro:

System.servicemodel.dll in %ProgramFiles (x86) % Assemblaggi di riferimento non corrisponde a quello nell'installazione .NET V4 su %windir % microsoft.net framework64 v4.0.30319 ...

Post vs 2010 SP1 Aggiornamento:

%Programmi File (x86)% Assemblaggi di riferimento Microsoft framework.netFramework v4.0 System.servicemodel.dll -> File versione 4.0.30319.1

%Windir% Microsoft.net Framework64 v4.0.30319 System.ServiceModel.dll -> File versione 4.0.30319.225

Confrontando queste due DLL nel browser oggetto in VS e nel riflettore produce il risultato che l'interfaccia IHTTPCookIeContainerManager è stata rimossa nel file più recente. Quindi sospetto che si tratti di una combinazione di sondaggi .NET che trovano la nuova DLL e le talpe che si riflettono su quella più vecchia quando si eseguono la generazione di mole/stub. Sono stato in grado di generare manualmente una DLL di moli per la nuova DLL eseguendo le talpe exe manualmente senza percorsi di riferimento di alcun tipo rispetto al bersaglio MSBuild che aggiunge un mucchio di percorsi di riferimento durante una build.

Answer 2

Non lo so perché Ciò accade, ma ho avuto lo stesso problema e l'ho risolto usando i filtri di tipo a moli e includendo solo quelli di cui ho davvero bisogno (che ha un bell'effetto collaterale di accelerare abbastanza la compilation !!). Questo è un esempio .moles file sto usando:

<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

Sembra che sia stato un conflitto tra il sistema e il sistema. Assemblee di manervicemodello che le talpe stava usando per la compilazione.

Di recente avevo installato Microsoft .NET Framework 4.5.

Dopo aver disinstallato questo e aver reinstallato 4.0 tutto ha funzionato.

Answer 4

Bene, nel caso in cui qualcuno stia lavorando con il codice legacy e sembra essere messo all'angolo nell'uso di Microsoft Moles, ho fatto un ampio scavo su questo argomento e spero di salvarne un po 'dalla rabbia e dalla frustrazione che ho incontrato.

Ho provato a usare il suggerimento della risposta accettata, il che significava andare alla directory delle moli (nei file C: Program ..) ed eseguire l'utilità della riga di comando (moles.exe) come amministratore. Ci sono molte opzioni, una delle quali consente di includere assemblaggi di riferimento (come suggerito sopra).

Tuttavia, anche quando si tenta di eseguire l'utilità senza assemblaggi referenziati, l'utilità alla fine chiama il compilatore C# (CSC.EXE) con percorsi di assemblaggio di riferimento predefiniti, che è dove concludo che si verifica la confusione tra le versioni del framework .NET. Non sono riuscito a prenderlo non Per includere questi percorsi di assemblaggio.

Il mio scenario specifico era che stavo cercando di molare un gruppo personalizzato, tuttavia perché, a quanto pare, avevo installato .NET 4.5 su questa macchina, si lamentava della compilation su System.Collections.Generics IreadonlyCollection, IreadOnlyDictionary e ne penso l'altro.

Soluzione: Il solo Soluzione che ho avuto modo di lavorare era utilizzare i filtri talpa, di cui ho letto su altri post e sul sito Web Microsoft Moles (esiste un collegamento speciale per la risoluzione dei problemi di .NET 4.5 sulla pagina principale). In Visual Studio, ho semplicemente aggiunto l'assemblaggio delle moli al mio progetto di test unitaria per il mio gruppo personalizzato di riferimento tramite clic destro in Solution Explorer. Ho quindi provato a costruire. Per ogni errore che ho ricevuto, ho notato le classi offensive e le ho escluse dall'essere screpolti o scambiati aggiungendo quanto segue al file delle moli:

<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>

Ora chiaramente non funzionerà se tu bisogno Le lezioni che stai escludendo dalla generazione di mole/stub, tuttavia per il mio caso ha funzionato bene perché le classi offensive non erano importanti e non avrei bisogno di studiare o evitare nulla in quelle classi.