VS2012 Test gezgini, yerel .dll dosyasını kilitler ve yeniden oluşturma işlemlerinin başarısız olmasını sağlar

Visual Studio 2012 C# ve C ++/CLI .dll ile bir çözüm için kullanıyorum, C ++/CLI dll ile artırma gibi yerel .dlls. C ++ kodu x64 olarak derlenir.

VS'yi açtığımda projemi temizleyebilir ve inşa edebilirim.

Test gezginini kullanarak testlerimi çalıştırabilirim.

Test gezginini bir kez testleri çalıştırmak için kullandığım anda projeyi yeniden oluşturamam. Görünüşe göre VS2012 Test Explorer, C ++/CLI-dll cihazımı kilitliyor ve şu hatayı alıyorum:

LNK1104: cannot open file 'C:\Dev\LockExample\bin\Debug\cli.dll'

Bunun bir sonucu olarak, ne zaman Test Explorer'ı kullanarak testleri çalıştırdığımda, geliştirmeye devam etmeden önce VS2012'yi yeniden başlatmam gerekiyor. Açıkçası bu sürdürülebilir bir gelişme süreci değil.

Test etme ve yeniden oluşturma, C# -only dlls ile sorunsuz çalışır - sorunu söyleyebildiğim kadarıyla, yalnızca yerel x64 kodunu kullanan DLL'lerde görülür.

Biraz daha test ettikten sonra, burada kötü adam vstest.executionengine.exe olduğunu buldum. Sapı (SysInternals'dan) kullanarak, vstest.executionengine.exe dosyasının .dll ve cli-dll'nin .pdb dosyasının kilitlerini tuttuğunu gördüm. Yalnızca yönetilen işler için herhangi bir kilit tutmaz.

Test tamamlandıktan sonra Visual Studio Test Explorer'ın C ++/Cli gişelerindeki kilitleri açmasını nasıl sağlayabilirim?

24
Aynı sorunu VS 2017'de başvurulan yönetilmeyen DLL ile de buldum.
katma yazar Slobodan Savkovic, kaynak

6 cevap

In Visual Studio 2013 this problem can easily be fixed by unchecking the option "Keep Test Execution Engine Running" under "Test -> Test Settings" in the menu.

I found the answer in another post: vstest.executionengine.x86.exe not closing

30
katma

Biraz daha aradıktan sonra, connect.microsoft.com adresinde bu yazı . Geçici çözümlerde son ipucu, çirkin bir kesmek olmasına rağmen sorunu çözer.

Aşağıdakileri C ++/CLI dll dosyama pre-build olayları olarak eklersem yeniden oluşturabilirim:

taskkill /F /IM vstest.executionengine.exe /FI "MEMUSAGE gt 1"
taskkill /F /IM vstest.executionengine.x86.exe /FI "MEMUSAGE gt 1"

Bu vstest.executionengine.exe işlemini öldürür, böylece benim .dll dosyamdaki kilidi serbest bırakır.

9
katma
Bu "çözüm" çirkinliğe rağmen benim için çalışıyor. Sadece bakmamaya çalışacağım ...
katma yazar rom99, kaynak

Yerel sorunları içeren testler sırasında da bu sorunla karşılaştım. Geçici çözüm (çözüm?) Bulduğum geçici çözüm testlere bir DeploymentItemAttribute eklemekdi - bunun genel olarak doğru olup olmadığından emin değil, ama kesinlikle benim için çalıştı. Çok fazla varsa biraz acı çekiyor (benim davamda 6 tane vardı), fakat bir kez yapıldığında diğer testlere kopyalayıp yapıştırmak kolaydı.

Birim test dersim şöyle gözüküyor:

[TestClass]
public class TestMyClass
{
    [TestMethod]
    [DeploymentItem("firstnative.dll")]
    [DeploymentItem("secondnative.dll")]
    public void TestMyMethod()
    {
        //Code which (indirectly) uses the above native dlls.
    }
}
3
katma

Ayrıca bu sorunla mücadele ediyorum ve başlangıçta "görev sırası" çözümünü kullandım, ancak VS2013 ayarlarında bu sorunu daha zarif bir şekilde çözen bir seçenek üzerinde bulundum:

Üzerindeki onay işaretini kaldırın.

Test çalıştırma motorunu test çalıştırmaları arasında çalışır halde tutun

seçeneğinde bulundu

Tools/Options/Web Performance Test Tools

2
katma
Benim için çalışmıyor ama bir web projesi yapmıyorum - Sanırım bu seçenek web projelerine özgü mü? Belki de bulamadığım başka bir yerde bir seçenek vardır.
katma yazar rom99, kaynak
Evet, test yürütme motorunu kullanıyorum ve testler yapıldıktan sonra belirli ikili dosyalar üzerinde bir kilit var gibi görünüyor (sqlite dlls). Aynı testleri vstest.console.exe komut satırı aracını kullanarak çalıştırdığımda, her şey beklendiği gibi çalışıyor ve ikili dosyalar kilitli değil. Bu arada, testler ayrıca komut satırı aracını kullanarak MUCH'i daha hızlı çalıştırır (veya testlerin kendisi değil, test çalıştırıcısı çok daha hızlıdır). Ama dalıyorum ...
katma yazar rom99, kaynak
Eh, bu sadece "Test Explorer" ı kullanırken her zaman sorunu çözer. C# uygulamalarını test ediyorum (web ile ilgili bir şey değil!) Ve bu benim sorunumu çözdü. "Test yürütme motorunu" mu kullanıyorsunuz? Eğer değilseniz, belki de "bin" 'deki herhangi bir ikili çıktı dosyasını kilitleyen başka bir işlemdir.
katma yazar axeloide, kaynak

Adding some stuff to the answer of @frodesto, (in case of VS2013), "Test>Test Setting>Keep Test Executin Engine running" configuration is stored in the user configuration (SUO file). This can be a bit nasty in case of this error happens in the TFS Build agent, beacause it uses a service default user.

Bu durumu düzeltmek için önce mevcut vstest.executionengine.exe dosyasını kapatın, TFS Build aracısı tarafından oturum açtığınız kullanıcı ile yürütmek için kullanılan kullanıcıyı değiştirin. TFS Build agent çalışma alanında depolanan çözümü açın ve seçeneğin işaretini kaldırın. Bundan sonra, TFS Yapı Aracısı, SUO dosyasının aynı kullanıcı için olduğu için "test yürütme motorunu tut" seçeneğini okuyacaktır.

1
katma
Bu seçenek yalnızca VS'nin yeni sürümlerinde kullanılabilir.
katma yazar Wilbert, kaynak
Biliyorum, sadece VS2013 (bazı durumlarda net olan bir cevabı işaretlemek için işaret ediyordum) ve TFS konusunda bazı ipuçları ekliyordum. Ama muhtemelen yeterince açık olamadım, cevabımı düzenleyeceğim.
katma yazar Jon Ander Ortiz Durántez, kaynak

Yerel kütüphaneleri C# yardımcı programı yazdım. nofollow "> burayı Test projesinde aşağıdaki gibi kullandım. Dispose dll dosyasını kaldırdığı için derleme hatalarıyla karşılaşmıyorum.

public interface INativeCrypto : INativeImport
{
    [ImportFunction("mynative.dll"]
    int NativeMethod();
}


[TestClass]
public class UnitTest1
{
    public void TestMethod1()
    {
        INativeCrypto impl = NativeImport.Create("");

       //Use methods in impl
        int i = impl.NativeMethod();
        //...
    }
}
1
katma