2012-03-24 9 views
7

Ho una soluzione con diversi progetti. Uno dei progetti include ulteriori metodi Assert per il test dell'unità. Si riferisce a Microsoft.VisualStudio.QualityTools.UnitTestFramework 10.1.0.0. Include anche altri progetti di test, che fanno riferimento sia a UnitTestFramework di Microsoft sia al mio progetto con metodi di asserzione aggiuntivi.Visual Studio persiste nell'utilizzo di UnitTestFramework 10.0.0.0

Ogni volta che riavviare Visual Studio e compilare, ottengo il seguente avvertimento:

conflitti Trovato tra le diverse versioni dello stesso assembly dipendente.

Ho provato a modificare tutti i riferimenti a UnitTestFramework su 10.1.0.0, ma al riavvio Visual Studio sembra impostarli nuovamente su 10.0.0.0. Ho anche provato a cambiare il file di progetto al di fuori di Visual Studio, ma all'apertura del progetto in Visual Studio i riferimenti mostrano nuovamente la vecchia versione in Solution Explorer. Quando si chiude Visual Studio senza apportare modifiche ai file, chiede se salvare o meno le modifiche ai file di progetto.

Come impedire a Visual Studio di modificare la versione del mio UnitTestFramework di riferimento nei miei progetti?

+0

I' d provare a riapplicare VS SP1 – KMoraz

+0

@KMoraz Ora ho un nuovo laptop, con un'installazione pulita. Ho scaricato di nuovo il progetto e questi problemi persistono. Credo che sia qualcosa che non va nei file di progetto, o che sia un bug di Visual Studio. –

+0

Questo problema si verifica ancora in Visual Studio 2013, Aggiornamento 4. –

risposta

3

Aveva lo stesso problema. Uno dei nostri sviluppatori stava riorganizzando le assemblee e il suo VS per qualche motivo sconosciuto ha cambiato questo:

<Choose> 
    <When Condition="('$(VisualStudioVersion)' == '10.0' or '$(VisualStudioVersion)' == '') and '$(TargetFrameworkVersion)' == 'v3.5'"> 
    <ItemGroup> 
     <Reference Include="Microsoft.VisualStudio.QualityTools.UnitTestFramework, Version=10.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL" /> 
    </ItemGroup> 
    </When> 
    <Otherwise> 
    <ItemGroup> 
     <Reference Include="Microsoft.VisualStudio.QualityTools.UnitTestFramework" /> 
    </ItemGroup> 
    </Otherwise> 
</Choose> 

in questo:

<Reference Include="Microsoft.VisualStudio.QualityTools.UnitTestFramework, Version=10.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL" /> 
<Choose> 
    <When Condition="('$(VisualStudioVersion)' == '10.0' or '$(VisualStudioVersion)' == '') and '$(TargetFrameworkVersion)' == 'v3.5'"> 
    <ItemGroup> 
     <Reference Include="Microsoft.VisualStudio.QualityTools.UnitTestFramework, Version=10.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL" /> 
    </ItemGroup> 
    </When> 
    <Otherwise /> 
</Choose> 

La prima riga dei quali tenuti cambiarsi su tutti gli altri sistemi (stessi sintomi come tu).

Dal momento che abbiamo in programma di supportare 3,5 in ogni caso, ho riparato rimuovendo la sezione "Scegliere" e la semplificazione in:

<Reference Include="Microsoft.VisualStudio.QualityTools.UnitTestFramework" /> 

(rimozione della versione specifica del tutto dal riferimento)

+0

Per qualche motivo, sembra funzionare. Tuttavia, vale la pena notare che questo sembra che 10.0 venga caricato. Quando tutti i riferimenti sono impostati su 10.0 e quindi non è caricato nessun 10.1, funziona anche. Non specificare la versione può quindi essere semplicemente un modo per garantire che 10.1 sia _non_ caricato, che è un modo più generale di evitare questo (bug?). –

+0

Inoltre, anche se questo potrebbe essere totalmente casuale, sembra che ci voglia _much_ più lungo (> 1 minuto) per chiudere Visual Studio quando si segue questo approccio? : / –