Willkommen auf myCSharp.de! Anmelden | kostenlos registrieren
 | Suche | FAQ

Hauptmenü
myCSharp.de
» Startseite
» Forum
» Suche
» Regeln
» Wie poste ich richtig?

Mitglieder
» Liste / Suche
» Wer ist online?

Ressourcen
» FAQ
» Artikel
» C#-Snippets
» Jobbörse
» Microsoft Docs

Team
» Kontakt
» Cookies
» Spenden
» Datenschutz
» Impressum

VS 2019 – Eigene Klassen (DLL) automatisch in weiteres Projekt Debug/Release einfügen
pollito
myCSharp.de - Member

Avatar #avatar-3521.gif


Dabei seit:
Beiträge: 192

Themenstarter:

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

beantworten | zitieren | melden

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é
private Nachricht | Beiträge des Benutzers
Th69
myCSharp.de - Experte

Avatar #avatar-2578.jpg


Dabei seit:
Beiträge: 4001

beantworten | zitieren | melden

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)).
private Nachricht | Beiträge des Benutzers
Abt
myCSharp.de - Team

Avatar #avatar-4119.png


Dabei seit:
Beiträge: 15704
Herkunft: BW

beantworten | zitieren | melden

Die korrekten Wege wären:
- Projektreferenz statt DLL-Referenz verwenden
- Paketmanagement (NuGet) verwenden
private Nachricht | Beiträge des Benutzers
hypersurf
myCSharp.de - Member



Dabei seit:
Beiträge: 511
Herkunft: Münster

beantworten | zitieren | melden

Ich würde auch immer mit NuGet arbeiten, das erleichtert das ganze sehr.
private Nachricht | Beiträge des Benutzers
pollito
myCSharp.de - Member

Avatar #avatar-3521.gif


Dabei seit:
Beiträge: 192

Themenstarter:

beantworten | zitieren | melden

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é
private Nachricht | Beiträge des Benutzers
pollito
myCSharp.de - Member

Avatar #avatar-3521.gif


Dabei seit:
Beiträge: 192

Themenstarter:

beantworten | zitieren | melden

Zitat von Th69
(...)

<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é
private Nachricht | Beiträge des Benutzers
M.L.
myCSharp.de - Member



Dabei seit:
Beiträge: 250

beantworten | zitieren | melden

Zitat

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,
Software is like cathedrals: first we build them, then we pray ;-)
private Nachricht | Beiträge des Benutzers
hypersurf
myCSharp.de - Member



Dabei seit:
Beiträge: 511
Herkunft: Münster

beantworten | zitieren | melden

Zitat von pollito
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.
private Nachricht | Beiträge des Benutzers
pollito
myCSharp.de - Member

Avatar #avatar-3521.gif


Dabei seit:
Beiträge: 192

Themenstarter:

beantworten | zitieren | melden

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é
private Nachricht | Beiträge des Benutzers
pollito
myCSharp.de - Member

Avatar #avatar-3521.gif


Dabei seit:
Beiträge: 192

Themenstarter:

beantworten | zitieren | melden

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é
private Nachricht | Beiträge des Benutzers
Abt
myCSharp.de - Team

Avatar #avatar-4119.png


Dabei seit:
Beiträge: 15704
Herkunft: BW

beantworten | zitieren | melden

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.
Attachments
private Nachricht | Beiträge des Benutzers
pollito
myCSharp.de - Member

Avatar #avatar-3521.gif


Dabei seit:
Beiträge: 192

Themenstarter:

beantworten | zitieren | melden

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é
private Nachricht | Beiträge des Benutzers