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...

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.

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 🙂

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

Beispiel-Code ist schwer, weil das über mehrere Projekte geht...
Auf einem anderem Entwicklungsrechner habe ich das Problem nicht und das Assembly wird richtig aufgelöst.

Das mit dem AssemblyResolve ist ein guter tip, da werde ich nochmal schauen.

Danke für eure Antworten.

Hallo!

Ich habe eine Applikation welche dynamisch Assemblies zur Laufzeit lädt. Diese "Module-Assemblies" befinden sich im "Modules" Unterordner der Applikation.
Jedes Modul kann dann noch eine GUI-Extension haben, welche sich dann im Unterordnet "GUI" befindet. Ein GUI-Assembly benötigt jedoch Typdefinitonen aus einem Module Assembly.

Das ist eigentlich kein Problem. Das GUI-Assembly hat eine Reference in VisualStudio auf ein "Module"-Assembly und kennt daher die Typen aus diesem zur compile-time. Im GUI-Ordner der Applikation liegen jedoch nicht die Module-Assemblies. Die Module-Assemblies werden von der Applikation jedoch früher geladen, so dass die Definitionen bereits in der AppDomain geladen sind.

Wenn ich nun eine GUI-Dll aus dem Unterordner laden will, welche auf einen Typ verweist der aus einem Modul-Assembly kommt, so kann die GUI-Dll nicht geladen werden weil der Modul-Typ nicht gefunden wird. Im Debugger liefert der Ausdruck "typeof(modul-type)" null zurück. Ich sehe jedoch dass der Typ in der AppDomain gelistet ist.

Warum kann zur Laufzeit ein bestimmter Typ nicht gefunden werden, obwohl er zuvor in die AppDomain geladen wurde?
Was mache ich falsch?

Liebe Grüße, Stu

Hey! Das ist ein Graphen-Control, ich Layoute damit die verschieden Achsen, die Legende und Items im Graph. Hätte man sicherlich auch mit Grids machen können.

Es war übrigens doch ein InvalidateVisual von mir (ein untergeordnetes Graph-Element). Ein typische Fall von zuviel Kaffee und zu spät am Programmiertag.

Mich würde es aber schon noch Interessieren, ob man die Quelle von einem InvalidateVisual-Aufruf irgentwie herausbekommen kann.

Hallo,

ich habe ein Control welches von Panel erbt und in dem ich MeasureOverride, ArrangeOverride und OnRender überschreibe. Mein Problem ist, dass andauernt ArrangeOverride und OnRender aufgerufen werden (komischer weise OnMeasure nicht).

Ich kann die Ursache dafür nicht finden. Es ist kein InvalidateVisual-Aufruf von einer anderen Stelle.
Das übergeordnete Control bleibt vom Layout her ruhig - dort wird OnRender nicht aufgerufen.
Binde ich das Control in ein Test-Projekt ein, dann tritt dieser "Fehler" nicht auf. In dem richtigen Projekt ist dieses Control in einem komplexeren Layout angeordnet.

Frage: Hat jemand irgendeine klevere Idee wie ich herausfinden kann was die Aufrufe von ArrangeOverride und folgend OnRender verursacht?
Da die Aufrufe ja alle aus dem Dispatcher kommen, kann ich da leider kein Breakpoint setzen.
Könnte man vielleicht die Aufrufe irgendwie profilen?

Mich wundert auch das MeasureOverride nicht aufgerufen wird, was ja zu einem vollständigen Layoutprozess eigentlich dazugehört. Ich meine auch das InvalidateVisual dazu führt, dass das Layout vollständig neu berechnet wird, also MeasureOverride auch mit aufgerufen wird.

Liebe Grüße, Stu

Also das klappt bei mir nicht.

List<ClassicMenuItem<FrameworkElement>> list = new List<ClassicMenuItem<FrameworkElement>>();

list.Add((ClassicMenuItem < FrameworkElement > ) new ClassicMenuModuleButton<PumpModule>());

ClassicMenuModuleButton ist nochmals von ClassicMenuModuleItem geerbt, aber das tut eigentlich nichts zur Sache.

Ich bekomme die Fehlermeldung dass der Typ nicht konvertiert werden kann. Was ja auch gar nicht so trivial ist, weil es ja tatsächlich auch verschiedene typen sind. Aber vllt gibt es ja noch einen Trick den ich nicht kenne.

Hi!

Ich habe eine Vererbungshierarchie von generichen Klassen und möchte eine Collection vom Grundtypen erstellen (also z.B. IEnumerable<ClassicMenuItem<?>>).

public class ClassicMenuItem<B>
        where B : FrameworkElement
    {
        public B MenuElement { get; protected set; }
    }

    public abstract class ClassicMenuModuleItem<T,B> : ClassicMenuItem<B>
        where T : Module
        where B : FrameworkElement
    {
        public T Module { get; set; }
        public string FunctionName { get; set; }
    }

Die Eigenschaft MenuElement von ClassicMenuItem muss ja mindestenz vom Typ FrameworkElement sein, d.h. es müsste doch eigentlich möglich sein die abgeleiteten Klassen auf ClassicMenuItem<FrameworkElement> casten.

Hat jemand eine Ahnung wie ich diesen Cast hinbekommen?

Schöne Grüße,
Stu