Referenzierte Assemblys (DLLs), die bei der Veröffentlichung plötzlich nicht kopiert werden

Ich stehe vor einem seltsamen Problem mit der Bereitstellung einer referenzierten Bibliothek (ServiceStack.Ormlite) während der Veröffentlichung von Webprojekten. Es funktionierte gut bis letzte Woche oder so, und jetzt plötzlich einige ServiceStack DLLs werden nicht kopiert, wenn das Projekt in lokalen Dateisystem, FTP oder Web Deploy, von Visual Studio oder Msbuild veröffentlicht wird.

Ormlite Referenz wird über nuget zu einem class lib Projekt hinzugefügt. Der Klassenbibliothek-Projektverweis wird dem Haupt-Webanwendungsprojekt hinzugefügt. Wenn ich das Web-App-Projekt veröffentliche, kompiliert und kopiert es alle Dateien außer drei der fünf ServiceStack.Ormlite-DLLs (nämlich ServiceStack.Common, ServiceStack.Interfaces und ServiceStack.Text werden nicht kopiert). Ich habe die Eigenschaft "Copy Local" für alle DLL-Verweise auf "true" überprüft (und sogar zurückgesetzt), aber das Problem besteht weiterhin. Ich habe auch überprüft, dass Ormlite nicht in GAC registriert ist.

Alle Tipps oder Vorschläge sind willkommen.

Update 1:

Ich stieß auf eine Reihe von Beiträgen im Zusammenhang mit demselben Problem (nicht jedoch bei ServiceStack). Es scheint so, als würden Visual Studio und msbuild [zu Recht] alle indirekten Referenzen in einem Projekt während der Veröffentlichung ignorieren.

Hier sind einige Lösungen, auf die ich gestoßen bin:

1. Verweisen Sie auch die Assemblys im Hauptprojekt.

2. Verwenden Sie ein Buildskript, um die DLLs als Post-Build-Ereignis zu kopieren.

3. Fügen Sie der Klasse lib eine Dummy-Methode hinzu und instanziieren Sie jede Klasse aus der Assembly oder dem Namespace, die während der Veröffentlichung nicht kopiert wird. Ich habe diese Option gewählt und das Problem teilweise gelöst. Jetzt werden ServiceStack.Common und ServiceStack.Text kopiert, aber ServiceStack.Interfaces wird immer noch nicht kopiert, obwohl ich eine Scheininstanz von 'ServiceStack.Logging.LogManager' erstellt habe, die Teil von ServiceStack.Interfaces ist. Also, im Grunde bin ich immer noch fest.