VS2019 kopiert nicht benötigte DLL ins Ausgabeverzeichnis

Hallöle,

also ich zweifle ja mal wieder.
Ich habe ein ASP.NET MVC (.NET 4.7.2)Projekt in VS2019.

Mein Problem ist, dass ins Ausgabeverzeichnis lokal Debug/Release und beim Veröffentlichen zwei DLL's mitkopiert werden, die ich vor langer Zeit aus dem Verweis gelöscht habe.
Diese brauche ich nicht.

Ich habe schon alle möglichen Dateien im Projektverzeichnis durchsucht und im Gesamten Ordner in allen Dateien gesucht:
Es gibt genau Null Verweise auf diese beiden DLL's.
Im GAC sind sie auch nicht mehr (wurden gelöscht).

Trotzdem sind sie immer da.
Gibt es eine protokollierte Ausgabe des Kompliervorganges, damit ich sehen kann, woher die ungewünschten DLL's kommen?

Vielen Dank.

Um was für DLLs handelt es sich denn? Aus eigenen Projekten, dem Framework oder aus einem Nuget-Package? Daß du keine Verweise im Projekt selbst hast, muß ja nichts heißen. Die von dir referenzierten Assembys haben auch Abhängigkeiten zu anderen Assemblys.

Setze mal die Build Ausgabe auf "Detailliert" oder "Diagnose", s. Vorgehensweise: Anzeigen, Speichern und Konfigurieren von Buildprotokolldateien ("Ändern der Informationsmenge im Buildprotokoll") - die Ausgabe könnte dann aber sehr groß werden.

Hey,
vielen Dank.

Es handelt sich um DLL's von SAP, die die Konnektivität zu SAP bereitstellen.
Diese liegen einfach in einem von mit erstellten Verzeichnis und werden bei Bedarf in Projekte eingebunden.
Diese hatte ich im Projekt mal involviert, aber aus den Verweisen gelöscht, da ich das in diesem Projekt nicht mehr brauche.
Weder in irgendeiner .csproj, .comfig noch sonstwo ist noch ein Verweis auf diese DLLs vorhanden.
Trotzdem muss es ja irgendwo stehen, dass VS sagt "binde diese DLL's mit ein"...

Vielen Dank.

Ok also ich habe mit der detaillierten Ausgabe den Fehler glaub schon gefunden.
Ich importiere einige andere DLL's die ich selbst erstellt habe ins Projekt.
In diesen werden die SAP-DLL's benötigt.

Diese liegen einfach in einem von mit erstellten Verzeichnis und werden bei Bedarf in Projekte eingebunden.
Diese hatte ich im Projekt mal involviert, aber aus den Verweisen gelöscht, da ich das in diesem Projekt nicht mehr brauche.

Wir wissen nicht, wie du die DLLs "bei Bedarf" einbindest, und wie du das wieder entfernt hast, aber evtl. ist ein Post-Build-Ereignis stehengeblieben? Oder irgendwo wird der gesamte Ordner kopiert, so daß die Suche nach den einzelnen Dateien kein Ergebnis bringt?

Zur Not hilft [Tutorial] Vertrackte Fehler durch Vergleich von echtem Projekt mit minimalem Testprojekt finden

Riecht danach, dass Du die DLL falsch einbindest oder die DLLs an einer falschen Stelle liegen.
DLLs, die manuell mitgeliefert werden, sollten Teil des Projekts sein.

Empfohlene .NET Ordnerstruktur:

$/
  artifacts/          Build outputs go here. Doing a build.cmd/build.sh generates artifacts here (nupkgs, dlls, pdbs, etc.)
  build/              Build customizations (Azure DevOps YAMLs/custom msbuild files/psake/fake/albacore/etc) scripts
  docs/               Documentation stuff, markdown files, help files etc.
  lib/                Things that can **NEVER** exist in a nuget package
  packages/           NuGet packages
  samples/            Sample projects
  src/                Main projects (the product code)
  tests/              Test projects
  wiki/               Wiki
  .editorconfig
  .gitignore
  .gitattributes
  build.cmd           Bootstrap the build for windows
  build.sh            Bootstrap the build for *nix
  global.json         (Optional!) .NET Core SDK only
  LICENSE
  NuGet.Config
  README.md
  {solution}.sln

In diesem Fall sollten die DLLs in "lib" liegen.

@Abt:

Im Prinzip sieht es genau so aus, nur ist das Lib Verzeichnis außerhalb dieser Ordnerstruktur, da verschiedene Projekte auf dieses zugreifen.
Im Prinzip so:

Entwicklung\Lib\Sap\x32*.dll
Entwicklung\Lib\Sap\x64*.dll
Entwicklung\ProjektX
Entwicklung\ProjektX

So gibt es eine Stelle für die DLL's und jedes Projekt greift darauf zu.

Aber wie gesagt, ich binde weitere DLL's in die Webanwendung ein, welche diese DLL's benötigen. Deshalb werden diese auch mit eingebunden(oder?)

Sowas sollte ihr sauber per Nuget Repository lösen anstelle von rumliegenden DLL.
Genau dafür ist NuGet gemacht worden!
Haben wir leider auch noch zu oft bei uns, dass mal DLL von Projekt A zu Projekt B kopiert werden anstelle diese als NuGet Pakete in unserem lokalen NuGet Repository freizugeben.

T-Virus

Sowas sollte ihr sauber per Nuget Repository lösen anstelle von rumliegenden DLL.

Nicht unbedingt; nackte Libs haben ihre Berechtigung und daher auch die Ordnerstruktur.

nur ist das Lib Verzeichnis außerhalb dieser Ordnerstruktur, da verschiedene Projekte auf dieses zugreifen.

Und genau das ist ein No Go. Libs gehören in ein Projekt, und nicht irgendwo ausserhalb.
Daher auch der Hinweis mit der Ordnerstruktur.

Grund:
Das Projekt ist der Single Point of Content und zB. auch Git-relevant.
Alle Elemente, die ausserhalb des Projekts liegen, sind unbekannt und es knallt.

Shared Content Folder sind ein absolutes NoGo.

Das ist wohl des Pudels Kern.
Und das ist wohl ein Grundsätzliches Problem, zumindest bei mir.

Ich habe mehrere selbst erstellte DLL#s mit Funktionen, die ich immer wieder benötige.
Hier verweise ich in den Projekten, direkt auf das Ausgabeverzeichnis der DLL-Projekte.
So muss ich bei Updates nicht immer die neu erstellten DLL's ins Projektverzeichnis kopieren.
Aber das ist wohl genauso "Banane?"
Was wäre hier die passende Vorgehensweise? (Ein Grundkurs im Programmieren ? )

Ok also ich habe nun zumindest mal für die beiden (SAP-) DLL's ein Nuget Package gemacht und installiere diese nun in Zukunft von einer lokalen nuget source.
Funktioniert prima, danke @T-Virus für den Hinweis.

Nach und nach werde ich dann die anderen, eigenen DLL's, teilweise mit Abhängigkeiten packen.
Somit sollte es DLL-Hell nicht mehr geben.

Mal wieder herzlichen Dank an die Profis hier!

Ich habe mehrere selbst erstellte DLL#s mit Funktionen, die ich immer wieder benötige.

Hier wäre NuGet der richtige Weg im .NET Umfeld.

Hier verweise ich in den Projekten, direkt auf das Ausgabeverzeichnis der DLL-Projekte.

Aber das ist wohl genauso "Banane?"

Ja

Was wäre hier die passende Vorgehensweise? (Ein Grundkurs im Programmieren ? )

Sind es eigene Projekte, dann ist NuGet der richtige Weg.
Sind es DLLs von einem externen Anbieter, dann legt man diese i.d.R. im Lib-Ordner ab.

Der Grund: ein NuGet Paket gehört dir - und darin dürfen keine DLLs enthalten sein, die nicht Dir gehören.
Natürlich kann man das der Einfachheit halb trotzdem machen - aber so ein NuGet Paket ist schnell bei unbedachter Behandlung auf nuget.org und nicht mehr löschbar.

In diesen werden die SAP-DLL's benötigt.

Daher ist es organisatorisch üblich und auch empfohlen, dass Drittanbieter DLLs, für die es eben kein offizielles NuGet gibt, im Lib-Ordner liegen sollten.
Auf diesen Ordner kann man in DevOps Prozessen auch sehr schnell und einfach Whitelist-Prüfungen durchführen.