Moin zusammen,
ich habe bisher in VB.Net meine Anwendungen Programmiert und bin auf C# gewechselt.
Ich kenne das so, wenn ich meine Anwendung fertig habe und über F5 kompiliert habe, dass ich die EXE aus dem debugverzeichnis nehmen kann und diese überall lauffähig ist (klar, .net muss schon installiert sein).
In C# habe ich festgestellt, das ich den ganzen Ordnerinhalt inkl. Unterverzeichnis mitkopieren muss, mache ich etwas falsch, oder beachte ich etwas nicht?
Viele Grüße
Christian
Sarkasmus ist die Kunst, Menschen einen Spiegel vorzuhalten. Nur merken es viele nicht.
Man hat noch nie einfach ne Exe aus nem Debug genommen und verteilt. Das war schon immer eine schlechte Idee und "pfusch".
Anwendungen haben immer Abhängigkeiten; teilweise in die EXE eingebettet, teilweise daneben, teilweise Runtime. In .NET / Java etc... musst Du immer alles ausliefern, was zur Applikation gehört (auch in VB.NET, C# ist nur eine Sprache, keine Runtime).
Deswegen gibts Installer bzw. Veröffentlichungsprofile, die alles zusammen setzen, was dazu gehört.
Willst Du eine "Portable App mit einer Exe", so musst Du in .NET Framework ILmerge verwenden bzw. in .NET 5 und höher Self Contained Deployments verwenden.
Aber achtung: nicht alle Abhängigkeiten sind in eine einzelne Exe packbar.
.NET Doku dazu: Einzeldatei-App - .NET
PS: .NET Framework (also alles bis v4.8) ist veraltet.
Das .NET Framework funktioniert auch ander als .NET 5 und höher.
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code
Zwischen VB und C# gibt es da keinen Unterschied.
Es reicht die Exe und die DLL's die Du benutzt weiter zu geben.
Wie Abt schon gesagt hat ist es besser eine Release-Version zu erstellen und diese weiterzugeben.
Grüße Bernd
Workshop : Datenbanken mit ADO.NET
Xamarin Mobile App : Finderwille Einsatz App
Unternehmenssoftware : Quasar-3
Moin,
Danke erst mal für die Antworten.
@Abt: Wieso ist das eine schlechte Idee und Pfusch? Das ist doch eine einfache Variante sich die Tools direkt irgendwo hin zu kopieren...
Ich verstehe aber nicht wieso ich dieses Problem mit VB in .Net nie gehabt habe.
Ich werde mir das "ILmerge" mal ansehen, guter Tipp.
Macht das Eig. einen Unterschied dabei ob ich.Net oder .Net Core nehme (weil diesen habe ich das erste mal verwendet)?
Sarkasmus ist die Kunst, Menschen einen Spiegel vorzuhalten. Nur merken es viele nicht.
Natürlich macht das einen unterschied.
Unter .NET Framework war das meiste schon vorinstalliert.
Bei NET5 ( oder Core ) ist nur die Runtime und das wichtigste vorinstalliert.
Die meisten DLL's werden aber ins Programmverzeichnis copiert.
Aber du kannst im normalfall auch mit NET5 eine single exe erzeugen.
für 32Bit
dotnet publish -p:PublishSingleFile=true --self-contained true -p:IncludeAllContentForSelfExtract=true -r win-x86 -p:PublishReadyToRun=true
für 64Bit
dotnet publish -p:PublishSingleFile=true --self-contained true -p:IncludeAllContentForSelfExtract=true -r win-x64 -p:PublishReadyToRun=true
Ich verstehe aber nicht wieso ich dieses Problem mit VB in .Net nie gehabt habe.
Vielleicht ein anderes Framework?
.NET Core/5/6 sind etwas ganz anderes, als .NET 4 (meist wird es ".NET Framework" ausgeschrieben) oder älter, auch wenn es gleich klingt.
Mit .NET Core/5/6 hat sich einiges zum alten System geändert.
Wieso ist das eine schlechte Idee und Pfusch? Das ist doch eine einfache Variante sich die Tools direkt irgendwo hin zu kopieren...
Wenn Du nur für privat arbeitet, reicht der Pfusch meistens auch völlig aus, sind halt ein paar Klicks mehr.
Produktiv kann sich der Publish-Prozess aber schon mal vom simplen F5 unterscheiden, das müsstest Du immer manuell machen und da versteckt sich der Pfusch.
Außerdem sollten fertig auslieferbare Versionen immer ein Release-Build sein.
Ich werde mir das "ILmerge" mal ansehen, guter Tipp.
Ist kein guter Tipp, sondern nur ein "So hat man's früher gemacht".
Heute solltest Du Self Contained Deployments nutzen, ist sowieso viel einfacher.
Macht das Eig. einen Unterschied dabei ob ich.Net oder .Net Core nehme [FAQ] Das .NET Ökosystem - .NET, .NET Core, .NET Standard, NuGet und Co
Lesen und verstehen, da führt heutzutage kein Weg dran vorbei, außer Du magst Felsen im Weg 😉
NuGet Packages im Code auslesen
lock Alternative für async/await
Beim CleanCode zählen nicht die Regeln, sondern dass wir uns mit diesen Regeln befassen, selbst wenn wir sie nicht befolgen - hoffentlich nach reiflichen Überlegungen.
Wieso ist das eine schlechte Idee und Pfusch? Das ist doch eine einfache Variante sich die Tools direkt irgendwo hin zu kopieren...
Weil dieser Ordner für solche Aktionen nicht gedacht ist.
Der Debug- und Release Ordner (unterhalb von bin) sind reine Entwicklungsverzeichnisse. Beim Build wird auch nicht immer aufgeräumt, sondern nur das aktualisiert, das für ein Build in dem Zustand notwendig ist.
Es ist nur über ein Publish ersichtlich, was eine Anwendung tatsächlich für den Betrieb benötigt.
Daher ist das einzelne Herauskopieren von Dateien einfach nur Roulette obs am Ende funktioniert, oder nicht.
Die Beispiele von FZelle treffen absolut den Punkt, wie es auch für Hobby-Tools richtig funktioniert.
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code
Oder einfach Publish to Folder
Die UI dafür ist einfach und "Self Contained Deployment" ist da nur eine Checkbox.
Die ganz Faulen, die einfach nur für sich ein Tool basteln wollen, können dort auch einfach direkt den richtigen Ziel-Ordner einstellen, wo dann z.B. ein Startmenü-Link hin zeigt.
NuGet Packages im Code auslesen
lock Alternative für async/await
Beim CleanCode zählen nicht die Regeln, sondern dass wir uns mit diesen Regeln befassen, selbst wenn wir sie nicht befolgen - hoffentlich nach reiflichen Überlegungen.
Ok, das bringt mal ein wenig Licht ins Dunkle...
Vielen Dank noch mal für die zahlreichen Antworten! 😁
Sarkasmus ist die Kunst, Menschen einen Spiegel vorzuhalten. Nur merken es viele nicht.