Laden...

Mehrere AppDomains, Umbenennung der .exe, Assembly wird nicht gefunden

Erstellt von Stu42 vor 2 Jahren Letzter Beitrag vor 2 Jahren 515 Views
S
Stu42 Themenstarter:in
506 Beiträge seit 2006
vor 2 Jahren
Mehrere AppDomains, Umbenennung der .exe, Assembly wird nicht gefunden

Hallo!

Die Software soll für OEM unter einen anderen Namen laufen. Hierfür möchte ich auch gerne die Applikations.exe umbenennen.
Nach dem Umbenennen funktioniert das Programm leider nicht mehr.

Grund: Ich starte die GUI aus einer separaten AppDomain heraus. Die neue AppDomain kann das in der *.exe enthaltene Assembly nicht auflösen, weil die Datei ja umbenannt wurde. Die urpsrungs AppDomain, die entsteht wenn die umbenennte *.exe gestartet wird, enthällt jedoch das Assembly der *.exe.

Jetzt dachte ich mir, ich könne ja die *.exe-Assembly einfach die in die neue AppDomain im vorfeld einladen, z.B. so


guiDomain = AppDomain.CreateDomain("XXXXGui",
                                                    AppDomain.CurrentDomain.Evidence,
                                                    AppDomain.CurrentDomain.SetupInformation);
guiDomain.Load(File.ReadAllBytes(Assembly.GetEntryAssembly().Location));

Aber auch dies führt dazu, dass das Assembly aus der *.exe in der neuen AppDomain nicht aufgelöst werden kann.

Frage: Gibt es noch eine andere Möglichkeit, wie ich die AppDomain vor der Ausführung mit der vorhanden Assembly füttern kann?

Hintergrund: Die Umbennung der exe soll eigentlich nur dazu dienen, damit im TaskManager nicht der Ursprungsname der Applikation steht. Doch ich vermute leider, dass die Umbennung der exe nicht zur Umbennung des Prozesses führt.

Best Grüße, Stu

T
2.219 Beiträge seit 2008
vor 2 Jahren

Wenn es nur dem Anzeige Namen im Task Manager dient, dann geht deine Umsetzung in die falsche Richtung.
Erstell doch die exe beim builden gleich mit dem richtigen Namen oder benenne diese vor dem Ausführen um.
Wenn die Anwendung bereits läuft, bringt ein umbenennen auch nichts mehr.

Mich würde aber interessieren, warum du den Ursprungsnamen per umbenennung verschleiern willst.
Klingt nicht gerade nach einem sinnvollen Einsatzzweck.

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

S
Stu42 Themenstarter:in
506 Beiträge seit 2006
vor 2 Jahren

Ja das Umbenennen der exe geht ja gerade nicht, wegen dem problem mit den App-Domains.

Den Titel im TaskManager kann ich mit [assembly: AssemblyTitle("XXXX")] beinflussen. Aber dann müsste ich für jeden Kunden der die Software unter seinem Namen wiederverkaufen will die AssemblyInfo.cs mit präprozessordirektiven anpassen um den AssemblyTitle zu ändern. Das probiere ich irgendwie zu vermeiden, da ich nicht für jeden OEM-Kunden die Software immer neu erstellen will.

Warum Kunden die Software unter einem eigenen Namen vertreiben möchten verstehe ich auch nicht wirklich - das beudeutet nur mehr arbeit für mich. Aber der Kunde ist nunmal König 🙂

3.825 Beiträge seit 2006
vor 2 Jahren

Ich muss aus einem anderen Grund auch mehrere exe Dateien erzeugen. Umbenennen kann ich nicht da dann die TextControl Lizenz nicht mehr geht.

Ich kopiere per Programm die SLN-Datei und ersetze in dieser die Namen die brauche. Dann wird halt x Mal übersetzt, aber das stört mich nicht.

Grüße Bernd

Workshop : Datenbanken mit ADO.NET
Xamarin Mobile App : Finderwille Einsatz App
Unternehmenssoftware : Quasar-3

16.807 Beiträge seit 2008
vor 2 Jahren

Aber dann müsste ich für jeden Kunden der die Software unter seinem Namen wiederverkaufen will die AssemblyInfo.cs mit präprozessordirektiven anpassen um den AssemblyTitle zu ändern. Das probiere ich irgendwie zu vermeiden, da ich nicht für jeden OEM-Kunden die Software immer neu erstellen will.

Einen Weg wirst gehen müssen; i.d.R. erstellt man die Software neu; oder Du verwendest Mehr-Prozess-Anwendungen, was eine Neuausrichtung Deiner Software Architektur erfordert.
Kann man über entsprechende CI-Setups wie Azure DevOps bequem automatisieren.

Warum Kunden die Software unter einem eigenen Namen vertreiben möchten verstehe ich auch nicht wirklich - das beudeutet nur mehr arbeit für mich. Aber der Kunde ist nunmal König 🙂

Sowas nennt sich White Labeling und in der Enterprise-Welt eine Standard-Anforderung an Dritt-Komponenten/Zusatzsoftware.

Zum Thema App Domains: diese existieren in der neuen .NET Welt so nicht mehr. AppDomains sind seit vielen vielen Jahren obsolete.
Du wirst Dir ohnehin einen neuen Mechanismus überlegen müssen, wenn Du Deine Software zukunftssicher aufstellen willst.
.NET Framework-Technologien, die für .NET Core und .NET 5 und höher nicht verfügbar sind
Hier kannst Du Dich wahrscheinlich auf eine größere Migrationssache einstellen.

S
Stu42 Themenstarter:in
506 Beiträge seit 2006
vor 2 Jahren

Danke für eure Antworten.

Ich habe ein Tool gefunden (rcedit), mit dem man die FileDescription und das Icon im nachhinein noch ändern kann. Das Ändern der FileDescription führt dazu, dass sich der Name im TaskManager ändert, egal wie der Name der exe ist. Somit komme ich erstmal um die Umbennenung der exe herum.

Für CI und automatische Buildprozesse fehlt hier bei mir leider die Infrastruktur. "Wir sind dafür zu klein". Schade eigentlich.

Ich muss gestehen, dass .NET 5.0 bisher an mir vorbeigezogen ist. Ich arbeite noch mit VS2017 und wenn man nicht immer upgraded, dann gibt es erstmal keine unterstürzung für die neuen Sachen. Das ist schon verrückt, wie sich technologien während der Entwicklung ändern. Ich habe jetzt eine WPF-Anwendung, welches jetzt erstmals an Kunden ausgeliefert wird - und diese Basiert auf einer technologie die nicht mehr weiterentwickelt wird (.net 4.8). An Migration habe ich erstmal nicht gedacht, weil MS ja sagt, dass man nur für neue Projecte .NET Core nutzen sollte und Bestehende weiterhin 4.8 targeten konnen. Aber immerhin gut, das .NET Core jetzt auch WPF kann.

Auf AppDomainen werde ich wohl verzichten können. Ich habe die Applikation jetzt in einen GUI und einen Steuerungsteil unterteilt. Stürzt die GUI ab, so kann ich diese einfach neustarten und der Steuerungsteil bleibt aktiv. Sowas kann man natürlich auch mit unterschiedlichen *.exe-Dateien realisieren.

16.807 Beiträge seit 2008
vor 2 Jahren

Für CI und automatische Buildprozesse fehlt hier bei mir leider die Infrastruktur. "Wir sind dafür zu klein". Schade eigentlich.

Das natürlich totaler Quark 🙂
Wer auch immer diese Aussage so getätigt hat, hat gefährlich wenig Ahnung und dazu vermutlich große Probleme in Sachen Wirtschaftlichkeitskalkulation.
Unbedingt mal damit beschäftigen! 🙂

Aber um Aufklärung zu betreiben:
Ein vollständiges CI-System hat man in spätestens 2h für 99% der Szenarien aufgesetzt, kann kostenlos betrieben werden und hat nachhahltige Effizienzvorteile.
"Wir sind dafür zu unprofessionell" würde daher meiner Meinung nach besser passen als "Wir sind dafür zu klein".
Selbst die meisten Open Source Projekte haben ein CI; das ist ein absolutes Muss für die professionelle Welt.

An diesem Forum hier entwickeln zwei Personen in ihrer Freizeit und wir haben das CI System mit mehreren Stages in wenigen Minuten mit Standard-Templates umgesetzt.
Es nimmt uns so viel Arbeit ab, spart uns immens viel Zeit, die wir in nützliche Dinge investieren können. In einer Firma kostet es einfach nur Geld, wenn man sich mit Builds und Releases selbst blockiert.

Absolut kein Hexenwert. Du wirst erstaunt sein, wie schnell und einfach das aufzusetzen ist.

Ich habe jetzt eine WPF-Anwendung, welches jetzt erstmals an Kunden ausgeliefert wird - und diese Basiert auf einer technologie die nicht mehr weiterentwickelt wird (.net 4.8).

Da hilft es immer das Ökosystem zu kennen, in dem man sich bewegt 🙂
.NET 5 ist der (organisatorische) Nachfolger von .NET 4.x; daher entsprechend auch die Marketing-Anpassung, sodass es wirklich auch jeder versteht.

Im Endeffekt ist das .NET 4.x Universum > 10 Jahre alt, wurde von Microsoft immer gepflegt, weiterentwickelt und supportet.
Letzteres so lange, wie der Update Zyklus von Windows 10 andauert.

Dass sich in der Zeit Anforderungen und Implementierungen verändern: notwendig und natürlich.

An Migration habe ich erstmal nicht gedacht, weil MS ja sagt, dass man nur für neue Projecte .NET Core nutzen sollte und Bestehende weiterhin 4.8 targeten konnen.

Die Aussage stammt aus .NET Core 2.0 - Microsoft sagt schon deutlich, dass man mittlerweile in allen Szenarien Richtung .NET 5 gehen sollte.

Sowas kann man natürlich auch mit unterschiedlichen *.exe-Dateien realisieren.

Würde man sogar heute auch eher so machen. Das über App Domains isoliert in einem Prozess zu machen ist schon eher nen alter Hut aus Architektursicht.

Aber gut, dass Du einen Weg für Dich gefunden hast, der für Dich funktioniert.

S
Stu42 Themenstarter:in
506 Beiträge seit 2006
vor 2 Jahren

Ich glaube zu unprofessionell trifft es ganz gut 🙂

Aber ich muss auch sagen, dass wenn man quasi alleine entwickelt, man schon so ausgelastet ist, das man vom ökosystem nicht viel mitbekommt. Aber wie du schon sagst, es lohnt sich das ökosystem zu kennen.

So ein CI könnte man natürlich auch schnell mit einem Batch-Script implementieren: Pullen/Auschecken, Compilieren, VSTest-Ausführen, Dateien-Kopieren und Setups builden...

2.078 Beiträge seit 2012
vor 2 Jahren

So ein CI könnte man natürlich auch schnell mit einem Batch-Script implementieren: Pullen/Auschecken, Compilieren, VSTest-Ausführen, Dateien-Kopieren und Setups builden...

Passend dazu eine kleine top aktuelle Geschichte von mir:
Ich hab die letzte halbe Woche mit einem System, das sich "Build-Server" schimpft, gekämpft.
Dieses System hat (so mein Eindruck) genau so begonnen, wie Du beschreibst: Ein simples Script, das Kompiliert und das Ergebnis bereitstellt (keine UnitTests und kein Setup)
Zu diesen simplen Anforderungen sind immer mehr dazu gekommen und das Script wurde immer größer, bis daraus eine interne Website (PHP und CMD) wurde, die man mit Script-Fragmenten in XML "konfiguriert" wird, damit es ein CMD-Script zusammen baut und ausführt. Und dieses Build-System ist voll mit Fallstricken und Bugs, um die bisher irgendwie drum herum gebastelt wurde, weil sich keiner an den Code heran traut.

Ein Kollege hat vorher schon wochenlang damit gekämpft und viel von den Erkentnissen an mich weiter gegeben, nur deshalb habe ich "nur" eine halbe Woche für meine Anpassung gebraucht.

Um nochmal auf deine Aussage zurückzukommen:

So ein CI könnte man natürlich auch schnell mit einem Batch-Script implementieren: Pullen/Auschecken, Compilieren, VSTest-Ausführen, Dateien-Kopieren und Setups builden...

Ja, kann man so machen, wird dann halt scheiße 😁
Oder Du nimmst dir ein/zwei Tage Zeit, arbeitest dich in die Thematik ein und testest, was geht.

309 Beiträge seit 2020
vor 2 Jahren

Ein Beispiel dafür: https://www.c-sharpcorner.com/article/continuous-integration-for-net-projects-with-jenkins/
Habe das sogar alleine genutzt.
Das dauert vielleicht mal 1-2h bis du das aufgesetzt und dich eingearbeitet hast. Ich kann es aufjedenfall empfehlen.

16.807 Beiträge seit 2008
vor 2 Jahren

So ein CI könnte man natürlich auch schnell mit einem Batch-Script implementieren: Pullen/Auschecken, Compilieren, VSTest-Ausführen, Dateien-Kopieren und Setups builden...

Ein CI ist mehr als ein Batch Script.
Da gehts auch um das Management von Builds, Qualität und Releases.

Was viele Entwickler / kleine Firmen nicht wissen: sobald Software in den Wirtschaftskreislauf einfließt, hast Du eine gesetzliche Aufbewahrungs bzw. Lieferpflicht. Und wenn ihr Software an Kunden liefert, dann seid ihr von dieser Regelung betroffen.
Das heisst nicht direkt, dass Du ein Release 10 Jahre lang speichern musst, sondern mindestens 10 Jahre einen genauen Software Stand zur Verfügung stellen musst, wie auch immer.
In der Realität kommt so eine Anfrage nur selten vor (ich kenne in den letzten 15 Jahren tatsächlich auch nur 6 Fälle), aber sie gibt es. Und das kann teuer werden, wenn man es nicht kann - und viel Ärger bringen, den man sich sparen kann: mit einem Quellcodeverwaltungs- und Managementsystem.
Ganz abgesehen von einer Effizienzsteigerung aller Beteiligten ohnehin.

Ich bin persönlich kein Fan von Jenkins (weil es ne Bastelbude ist), aber ich verstehe auch die Fans davon, die eben gern basteln (hier übrigens ein Vergleich Jenkins vs GitLab, der schon ganz gut zeigt, wie viel Jenkins den etablierten Systemen allein fehlt)
Für Unternehmen empfinde ich derzeit Azure DevOps das mit riesigem Abstand führende System, der einfachste Einstieg macht aber definitiv GitHub Features • GitHub Actions

Unser neuestes offene Projekt von MyCSharp auf GitHub kann man sich hier anschauen: https://github.com/mycsharp/HttpUserAgentParser/actions
Und die entsprechende Build-Config kann man 1:1 für alle .NET Projekte verwenden (in diesem Fall Libs für NuGet), die sich an die .NET Guidelines halten.
Einfacher gehts meiner Meinung nicht.