0

Ich verwende VS 2015 Update 2 mit Resharper Ultimate 2016.1 und ich habe dieses seltsame Problem.Assembly.LoadFrom lädt DLL nicht aus bin debug, wenn Unit-Tests mit Resharper ausgeführt werden

Ich habe ein Testprojekt namens Test, das auf zwei Projekte, Modell und Persistenz, verweist. Das Modellprojekt enthält Nhibernate-Entitätsklassen und das Persistence-Projekt enthält * .hbm.xml-Dateien. Sie wurden mit llblgenpro 4.2 generiert. Ich benutze Nhibernate 4.0.4.

ich initialisieren NHibernate mit diesem Aufruf:

NHibernateSession.Init(
    new SimpleSessionStorage(), 
    new string[] { "Persistence.dll", "Model.dll" }); 

Als ich eines meiner Testfälle laufen die nhibernate Initialisierung mit dieser Ausnahme fehlschlägt:

System.IO.FileNotFoundException was unhandled by user code 
    FileName=file:///C:\Users\costa\AppData\Local\JetBrains\Installations\ReSharperPlatformVs14\Persistence.dll 
    FusionLog==== Pre-bind state information === 
LOG: Where-ref bind. Location = C:\Users\costa\AppData\Local\JetBrains\Installations\ReSharperPlatformVs14\Persistence.dll 
LOG: Appbase = file:///C:/projects/csharp/Test/bin/Debug 
LOG: Initial PrivatePath = NULL 
Calling assembly : (Unknown). 
=== 
LOG: This bind starts in LoadFrom load context. 
WRN: Native image will not be probed in LoadFrom context. Native image will only be probed in default load context, like with Assembly.Load(). 
LOG: Using application configuration file: C:\Users\costa\AppData\Local\Temp\s0hjyhsk.jq1\a3514fde-acb9-4c62-a0ce-a586f8202f35.config 
LOG: Using host configuration file: 
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework64\v4.0.30319\config\machine.config. 
LOG: Attempting download of new URL file:///C:/Users/costa/AppData/Local/JetBrains/Installations/ReSharperPlatformVs14/Persistence.dll. 

    HResult=-2147024894 
    Message=Could not load file or assembly 'file:///C:\Users\costa\AppData\Local\JetBrains\Installations\ReSharperPlatformVs14\Persistence.dll' or one of its dependencies. The system cannot find the file specified. 
    Source=mscorlib 
    StackTrace: 
     at System.Reflection.RuntimeAssembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks) 
     at System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(AssemblyName assemblyRef, Evidence assemblySecurity, RuntimeAssembly reqAssembly, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks) 
     at System.Reflection.RuntimeAssembly.InternalLoadFrom(String assemblyFile, Evidence securityEvidence, Byte[] hashValue, AssemblyHashAlgorithm hashAlgorithm, Boolean forIntrospection, Boolean suppressSecurityChecks, StackCrawlMark& stackMark) 
     at System.Reflection.Assembly.LoadFrom(String assemblyFile) 
     at SharpArch.NHibernate.NHibernateSession.<>c__DisplayClass36_0.<CreateSessionFactoryFor>b__0(MappingConfiguration m) in C:\work\sharp-arch\Solutions\SharpArch.NHibernate\NHibernateSession.cs:line 412 
     at FluentNHibernate.Cfg.FluentConfiguration.BuildConfiguration() 
    InnerException: 

Wenn ich die persistence.dll auf die Kopie C: \ Benutzer \ costa \ AppData \ Local \ JetBrains \ Installations \ ReSharperPlatformVs14 Ordner, der Testfall funktioniert einwandfrei. Die Datei persistence.dll befindet sich im Ordner C:/projects/csharp/Test/bin/Debug, da auf das Persistenzprojekt im Testprojekt verwiesen wird.

Dies alles lief gut in VS 2013 mit Nhibernate 3.3.1. Außerdem habe ich alle DLL-Versionen mit den Assemblybinding-Elementen in der Datei app.config des Testprojekts ausgerichtet.

Meine Projekte zielen auf .Net 4.6 und ich benutze Nunit 3.2.1.

fand ich dies:

Resharper runs UnitTest from different location

jedoch in meinem Fall 'Shadow-Copy-Baugruppen getestet werden' ausgeschaltet ist, mit Tests für jede Baugruppe separate AppDomain verwenden wird ebenfalls ausgeschaltet. Test ausführen von ist auf Projektausgabeordner eingestellt.

Irgendwelche Ideen, was könnte das verursachen?

Dank

Ein Update: Wenn ich dies tun, funktioniert es:

string path = Assembly.GetExecutingAssembly().Location; 
    string directory = Path.GetDirectoryName(path); 

    NHibernateSession.Init(
    new SimpleSessionStorage(), 
    new string[] { directory + "\\Persistence.dll", directory + "\\Model.dll" }); 

Update 2. Mein Projekt der Sharp Architecture library verwendet. NHibernateSession ist eine Klasse, die zu dieser Bibliothek gehört.

+0

Was ist 'NHibernateSession'? Es sieht für mich nicht wie ein nativer Teil von NHibernate aus. Wenn dies eine benutzerdefinierte Klasse ist, ist es schwer, Ihnen zu helfen, ohne seinen Code zu haben. Vielleicht ist das eine Klasse, die von llblgenpro generiert wurde: Es könnte besser sein, sie in solchen Fällen um ihre Unterstützung zu bitten. –

+0

Und vielleicht hättest du es einfacher, llblgenpro beiseite zu legen und arbeitet direkt mit deinen Mappings und Session Factory. Damit können Sie sie auf Ihre Geschäftsanforderungen abstimmen. (Sie können mehr über meine Ansicht [hier] lesen (/ a/35589532/1178314).) Und Sie hätten mehr Möglichkeiten, die Initialisierung Ihrer Sitzungsfactory zu verarbeiten, wie die in meiner Antwort [hier] (/ a/35711701/1178314). –

+0

@ Frédéric: Ich habe meinen Beitrag aktualisiert. Diese NHibernateSession gehört zur Bibliothek s # arp-architecture.Tut mir leid, ich habe das vermisst. – costa

Antwort

2

Dies ist wahrscheinlich eine Änderung in NUnit 3, die das aktuelle Verzeichnis nicht mehr an den Speicherort der getesteten Assembly ändert. Ich glaube, das liegt daran, dass mehrere Assemblies in einem einzigen Testlauf ausgeführt werden können - welches Verzeichnis wäre also am besten?

Gemäß the NUnit 3 Breaking Changes document können Sie TestContext.CurrentContext.TestDirectory verwenden, um das Verzeichnis zu finden, das die zu testende Baugruppe enthält.

+0

Ich wechselte zu NUnit 2.6.4 und es funktioniert gut wie es ist. Das muss es also sein. – costa