Hallo,
wenn ich ein dll Projekt erstelle, kann ich es ja als debug und auch als release erstellen. Bei release wird ja auch optimiert und es gibt einmal Dateien in debug und einmal im release Verzeichnis. Wenn ich diese dll nun von einem anderen Projekt benutzen möchte, binde ich sie ja als Verweis ein. Wenn ich mein Projekt als debug erstelle, muss ich auch die debug Version der dll einbinden. Wenn ich die release Version einbinde, gibt es (zumindest bei mir) Probleme.

Prinzipiell müsste es doch so sein, dass ich auf die debug Version der dll verweise, wenn ich als debug builde und auf die release Version, wenn ich als release builde. Aber die Verweise sind doch von der Konfiguration unabhängig?

Wie macht man so etwas denn? Oder geht das gar nicht? Das wäre aber blöd.

Innerhalb einer Solution referenziert man Projekte, keine DLLs.
Zwischen Projekten, also Solution-übergreifend, teilt man gemeinsame Bibliotheken über NuGet Pakete; nicht mehr über einzelne DLLs.

NuGet ist dazu da, dass Du alle notwendigen Abhängigkeiten automatisch aufgelöst bekommst.
Siehe What is NuGet and what does it do?
NuGet ist nichts anderes als ein Paketmanager, wie sie heutzutage in jedem Ökosystem gibt.

Im NuGet legt man dann die Release-Varianten der DLL ab; und fügt dann noch Symbol-Dateien hinzu, sodass ein Debugging möglich ist.
Veröffentlichen von NuGet-Symbolpaketen mithilfe des neuen Formats für Symbolpakete „.snupkg“

Du kannst natürlich direkt DLLs referenzieren, aber wie Du merkst, musst Du Dich dann selbst um alles kümmern.

Das mag sich erstmal komplex anhören; aber das Erstellen von NuGet Paketen kannst Du vollständig automatisieren.
Siehe Overview and workflow of creating NuGet packages

Zuerst einmal Danke für die schnelle Antwort und Sorry, dass ich jetzt erst reagiere.
Das mit dem nuget ist sicherlich der richtige Weg und ich habe auch schon vom meiner dll ein nuget Paket in meinem lokalen nuget Verzeichnis erstellt. Allerdings stelle ich jetzt fest, dass das Paket immer die Version 1.0.0 bekommt, obwohl in meinem Assembly Info was anderes steht:
[assembly: AssemblyVersion("1.1.466.1059")]
In meiner .nuspec Datei steht
<version>$version$</version>
Damit sollte er doch die Version aus dem Assembly nehmen. In der Ausgabe von nuget.exe pack wird hinter "Paketerstellung aus Dateien aus" auch das richtige Verzeichnis angezeigt. Es wird auch der richtige .nuspec Dateiname als "wird für Metadaten verwenden". Sieht also alles gut aus.
Trotzdem wird immer das Paket 1.0.0.nupkg erstellt.
Ich suche schon eine Weile im Netz, finde aber nichts, was den Fehler erklärt (zumindest bisher noch nicht).

nuget gibt mit aber noch folgendes aus:
WARNUNG: NU5128: Some target frameworks declared in the dependencies group of the nuspec and the lib/ref folder do not have exact matches in the other location. Consult the list of actions below:
- Add a dependency group for .NETFramework4.7 to the nuspec

Ich habe noch nicht verstanden, wie ich diese dependency group einfüge (muss doch in der .nuspec Datei eingetragen werden), damit diese Warnung nicht mehr kommt.
Kann diese Warnung eventuell dazu führen, dass er immer die falsche Version benutzt?

Gruß
Erwin

Nach einigem Lesen komme ich nun zu dem Schluss, dass $Version$ in .nuspec doch nicht das gleiche wie die Assembly Version ist.
Das passt ja auch von der Anzahl der Nummern nicht: Assembly Version benutzt 4 Zahlen, nuget 3. Also sind die beiden Versionen doch wohl unterschiedlich bzw. ich sollte sie manuell gleich halten. Obwohl die nuget Version ja vielleicht wichtiger als die Assembly Version ist. Vielleicht doch nur eine gleich halten?

Sind auch zwei paar Schuhe.
Die Assembly Version ist nur für die Version der jeweiligen Assembly gedacht.
Die Version aus .nuspec ist eben die Version für die NuGet Paket.
Da ein NuGet Paket auch u.U. aus mehren unterschiedlichen DLLs mit ihren eigenen unterschiedlichen Versionen bestehen kann, macht eine Versionierung über die Assembly Version keinen direkten Sinn.

T-Virus

Pakete werden anhand ihrer Quelle versioniert, meist im Zusammenhang mit dem Entwicklungszyklus in der Quellcode-Verwaltung (Branching etc); auch in der .NET Welt.
D.h. NuGet Pakete werden selbst versioniert, wie auch die Inhalte, die aus verschiedenen Quellen kommen können.

Die Versionierung kann man ebenfalls komplett automatisieren, sowohl für die DLLs wie auch für das Paket selbst.
[Artikel] Automatische, standardisierte Versionsvergabe in und mit .NET