Laden...

VS 2019 – Eigene Klassen (DLL) automatisch in weiteres Projekt Debug/Release einfügen

Erstellt von pollito vor 4 Jahren Letzter Beitrag vor 4 Jahren 1.757 Views
pollito Themenstarter:in
314 Beiträge seit 2010
vor 4 Jahren
VS 2019 – Eigene Klassen (DLL) automatisch in weiteres Projekt Debug/Release einfügen

Hallo!

Die Überschrift ist etwas verwirrend, mir fiel aber nichts besseres ein – sorry! Ich erkläre es:

Ich habe ein Projekt, das Klassen aus einem anderen Projekt von mir verwendet. Diese Klassen liegen als DLL vor – sie werden in das Projekt als Verweis eingefügt.

Wenn ich nun die Klassen ändere, ändern sich die DLLs sowohl in bin\Debug als auch in bin\Release. Diese neuen DLLs hätte ich auch gerne automatisch in den entsprechenden bin-Ordnern meins Projektes – ein Mal in bin\Release für das fertige Programm und einmal in bin\Debug für die Entwicklung. Allerdings kann ich über "Verweis Hinzufügen..." nur einen Verweis hinzufügen: entweder bin\Debug oder bin\Relese.

Wie kann ich automatisch dafür sorgen, dass ich während der Entwicklung die Debug-Version meiner DLL habe, während bei Fertigstellung des Programms die Release-Version der DLL verwendet wird?

Sicher eine triviale Sache, aber ich komme nicht drauf.

Liben Dank im Voraus und einen schönen Sonntag!

René

René

4.931 Beiträge seit 2008
vor 4 Jahren

Dies geht wohl nur über manuelles Editieren der Projektdatei, s. Visual Studio 2010 Compiling with the Debug or Release version of third party library depending on if my project is being compiled Build or Release?, also


<Reference Include="MyLib">
   <HintPath>..\lib\$(Configuration)\MyLib.dll</HintPath>
</Reference>

(alternativ entsprechend der anderen Antworten mittels Bedingung (Condition)).

16.807 Beiträge seit 2008
vor 4 Jahren

Die korrekten Wege wären:

  • Projektreferenz statt DLL-Referenz verwenden
  • Paketmanagement (NuGet) verwenden
H
523 Beiträge seit 2008
vor 4 Jahren

Ich würde auch immer mit NuGet arbeiten, das erleichtert das ganze sehr.

pollito Themenstarter:in
314 Beiträge seit 2010
vor 4 Jahren

Danke!

Mit Projektreferenzen werden die entsprechenden Queldateien teil meines Zielprojektes und demnach immer wieder mitübersetzt. Habe ich das richtig verstanden? Interessant – ich muss schauen, ob das eine gangbare Lösung ist.

Bei NuGet muss ich erst passen. Bis auf ein paar Mal was von VS nachinstallieren zu lassen, kenne ich mich damit nicht aus. Dank deinem Vorschlag weiß ich jetzt aber, dass es einen weiteren Weg gibt und werde ihn mir in den nächsten Tagen anschauen. Danke dafür!

LG

René

René

pollito Themenstarter:in
314 Beiträge seit 2010
vor 4 Jahren

(...)

  
<Reference Include="MyLib">  
   <HintPath>..\lib\$(Configuration)\MyLib.dll</HintPath>  
</Reference>  
  

(...)

Danke! Der erste Test war nicht erfolgreich. Ich muss nachschauen, was ich das falsch gemacht habe.

Eine Frage in die Runde: Ich kann anscheinend dasselbe erreichen, wenn ich im Präbuildereignis die entsprechenden DLLs (sofern sie sich geändert haben), in das Ziel kopiere. Ich habe gerade einen Test durchgeführt, der erfolgreich war: Als DLL-Verweis wird auf die Debug-DLL verwiesen. Beim Erstellen der Release-Version wird zunächst die Release-DLL kopiert und verwendet. – Ist das ein gangbarer Weg oder eher Gefrimmele und demnach mit Seiteneffekten zu rechnen?

Nochmals vielen Dank!

LG

René

René

M
368 Beiträge seit 2006
vor 4 Jahren

Bei NuGet muss ich erst passen. Hier geht es zur Doku: https://docs.microsoft.com/en-us/nuget/

Goalkicker.com // DNC Magazine for .NET Developers // .NET Blogs zum Folgen
Software is like cathedrals: first we build them, then we pray 😉

H
523 Beiträge seit 2008
vor 4 Jahren

Bei NuGet muss ich erst passen. Bis auf ein paar Mal was von VS nachinstallieren zu lassen, kenne ich mich damit nicht aus.

Musste Dir wirklich mal anschauen. Einen eigenen NuGet-Server aufzusetzen dauert nicht mal ne Stunde und die Pakete lassen sich per Batch-Einzeiler oder auch direkt beim Build erstellen.

pollito Themenstarter:in
314 Beiträge seit 2010
vor 4 Jahren

Danke für die Tipps! Ich werde mir das Thema NuGet ab heute anschauen, sofern ich etwas Zeit abzwacken kann. Auf alle Fälle ist es jetzt auf meiner Agenda drauf.

LG

René

René

pollito Themenstarter:in
314 Beiträge seit 2010
vor 4 Jahren

Gut, ich habe etwas Zeit gefunden, mich mit NuGet ein wenig zu befassen (eher einzulesen). Was ich aber nicht verstehe, ist es, wie man ein Paket mit beiden Versionen (Bin und Release) erstellen und verwenden kann.

Wird das von NuGet überhaupt unterstützt?

Nochmals vielen Dank!

LG

René

René

16.807 Beiträge seit 2008
vor 4 Jahren

Es gibt in NuGet Stable und Unstable Pakete.
Unstable wird anhand von SemVer Richtlinien identifiziert: https://semver.org/
Siehe auch Doku: https://docs.microsoft.com/en-us/nuget/concepts/package-versioning

Prinzipiell ist es so, dass man in 99,9999% aller Varianten immer Release paketiert.
Wenn Du einen ordentlichen DevOps Prozess hast, geht das alles völlig automatisiert:

  • feature Branch in Git erstellen
  • Changes commiten
  • Pullrequest erstellen
  • PullRequest erhält eine SemVer Beta Version (das macht zB GitVersion automatisch inkl. Versionierung)
  • Das Paket ist entsprechend ein Beta Paket
  • Wenn Changes valide sind, dann wird der Freature Branch in den master branch überprüft
  • Der Build ist dann stable
  • Paket ebenfalls Stable

via Azure DevOps ist das alles in wenigen Zeilen umzusetzen:
https://github.com/BenjaminAbt/AzureDevOps-YamlBuildSamples/tree/master/DotNetCore-NuGet

bzw genaue Steps:
https://github.com/BenjaminAbt/AzureDevOps-YamlBuildSamples/blob/master/DotNetCore-NuGet/build/azure-pipelines-steps.dotnet-nuget.yml

In der Umsetzung mit Azure DevOps sieht das dann so aus wie im Anhang:

  • Der Build erzeugt ein oder mehrere Pakete (je nach Repository/Projekt) in der jeweiligen Konfiguration
  • Das Release published auf ein oder mehrere Feeds

PS: prinzipiell kann man auch Debug-Pakete erstellen (das kann man konfigurierbar machen), sollte aber nur für die Unstable und niemals für die Stable Pakete gelten.
I.d.R. ist auch so, dass Debug-Pakete nicht auf den "offiziellen" Feed gepublished werden.

pollito Themenstarter:in
314 Beiträge seit 2010
vor 4 Jahren

Super, danke! Da habe ich aber einiges nachzuholen.

Ich hatte sehr viele Jahre C++ in Visual Studio programmiert, und da war es normal, im den Einstellungen unterschiedliche DLLs, LIBs usw. für Debug und Release angeben zu können. Eine direkte ähnliche Möglichkeit sehe ich für C# nicht.

LG

René

René