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...
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
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
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.
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.
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?
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.
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.
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.
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?
ich habe mal eine grundlegende Frage zur Netzwerkkommunikation.
Da eine TCP-Verbindung ja selbst auf die Daten "aufpasst" brauche ich ja nicht
unbedingt eine Lesebestätigung von Teildaten in "meinem" protokoll. Wenn ein Fehler in der
Kommunikation auftritt werde ich wohl einen Verbindungsabbruch bekommen.
Mal angenommen ich möchte nun große Daten pro Zeiteinheit auf den NetzwerkStream
schreiben, so rufe ich oft NetworkStream.Write auf.
Meine Frage nun: Blockiert die Write-Methode irgendwann wenn der Sendepuffer voll ist?
Würde ich die Socket-Funktion "send" von Windows aufrufen, würde ich als Rückgabewert
ja die bytes bekommen, welche von der send-Funktion abgenommen wurden. Da
die NetworkStream.Write-Funktion jedoch nicht diesen Rückgabewert hat müsste sie ja blockieren...
Der Kommunikationsteil wird vorest nur benutzt wenn die GUI lebt.
Ich schaue mal wie schnell ich mit den AppDomainen weiter komme, aber bisher sieht es nur noch einer kleinen Umstellung aus.
{"Assembly.GetEntryAssembly() gibt NULL zurück. Legen Sie die Application.ResourceAssembly-Eigenschaft fest, oder verwenden Sie die Syntax \"pack://application:,,,/assemblyname;component/\", um die Assembly anzugeben, aus der die Ressource geladen werden soll."}
Wenn ich dann aber den Source-Pfad wie von dir beschrieben abändere, geht es!
Aber beim SplashScreen funktioniert das nicht.
Wahrscheinlich gibt Assembly.GetEntryAssembly() nun mal Null zurück.
Wenn ich den SplashScreen Aufruf aber wie folgt abändere tut es:
SplashScreen splashScreen = new SplashScreen(System.Reflection.Assembly.GetCallingAssembly(), "images/splashscreen.png");
Danke für den Tipp!
Ich hoffe ich mir fliegt diese AppDomain -Umstellung nicht bei viele weiteren Stellen um die Ohren.
das Programm an dem ich gerade arbeite übernimmt u.a. Steuerungsaufgaben von
angeschlossenen Geräten.
Der Steuerungsprozess läuft dabei in einer eigener AppDomain und kommuniziert mit der WPF-GUI
über MemoryMappedFiles.
Sollte die GUI mal abstürzen, möchte ich nicht das der Steuerungsprozess mit untergeht. Idealer weise würde ich gerne die GUI nach einem Absturz mit Parametern neu starten.
Das Problem ist, dass die WPF-Gui in der ersten AppDomain im Hauptthread läuft.
Wenn die GUI dann abstürzt habe ich leider keine "Überwachungs-App Domain" mehr, welcher die GUI neu starten könnte.
Ich möchte also die GUI in einer eigenen AppDomain ausführen.
Nur wenn ich dies mit folgenden Code mache, können die Resourcedateien nicht geladen werden (ArgumentNullException).
[STAThread]
[LoaderOptimization(LoaderOptimization.MultiDomainHost)]
static void Main()
{
AppDomain guiDomain = AppDomain.CreateDomain("Gui");
guiDomain.DoCallBack(() =>
{
SplashScreen splashScreen = new SplashScreen("images/splashscreen.png");
splashScreen.Show(true);
App app = new App();
app.InitializeComponent();
app.Run();
});
/* Der folgende Code wuerde funktionieren
SplashScreen splashScreen = new SplashScreen("images/splashscreen.png");
splashScreen.Show(true);
App app = new App();
app.InitializeComponent();
app.Run();*/
}
Wenn ich den Startup-Code nicht in einer extra Domain ausführe läuft alles.
In dem Domain-Callback kann der SplashScreen bereits nicht auf "images/splashscreen.png"
zugreifen.
Kann es sein, dass am Start Resourcen in den Haupt-AppDomain geladen werden, welche
in einer neuen AppDomain nicht verfügbar sind?
ich hohle mal diesen Beitrag hervor, weil ich beim kompilieren mit VS2005
wieder folgende Fehlermeldung bekomme:
Fehler
Error 4 "C:\Windows\Microsoft.NET\Framework\v2.0.50727\AL.exe" was not found. Either 1) Install the .NET Framework SDK, which will install AL.exe. Or 2) Pass the correct location of AL.exe into the "ToolPath" parameter of the AL task.
Heute hat Windows 10 bei mir ein Anniversary-Update installiert (mit Windows.old-Ordner!).
Noch so einem Update funktioniert immer irgendetwas nicht...
Hat jemand auch das Problem?
Hat mittlerweile jemand ein Tipp wie ich das behben kann?
Schöne Grüße,
Stu
[EDIT]
Letzens hatte ich das Problem durch eine komplette neuinstallation von Windows 10 mit Updates und ein nachträgliche Installation von VS2005 beheben können. Aber das kann ja wohl keine gängige Praxis nach einem Anniversary-Update sein.
anbei eine kleine Klasse zur schnellen Interprozesskommunikation über MemoryMappedFiles.
Die Komponente kann benutzt werden um Daten zwischen verschiedenen AppDomains oder Prozessen einfach und schnell auszutauschen.
Mehrere Teilnehmer teilen sich dabei einen Kanal. Schreibt ein Teilnehmer eine Byte-Nachricht, wird sie von allen anderen Teilnehmer Empfangen.
Das Programm mit dem benötigten Microsoft.Diagnostics.Runtime-Assembly befindet sich im Anhang.
Da ich die Komponente auch in meinen aktuellen Projekt einsetze, nehmen ich Fehler und anregungen gerne entgegen.
Ich habe es jetzt so gelöst, dass ich mir die process id und die thread id im mmf speichere. Dauert eine Übertragung dann länger, wird überprüft ob alle beteiligten Prozesse (bei verschieden Prozessen), bzw. alle beteiligten Threads (bei einem Prozess und mehrere AppDomains), noch leben.
Die managed Threads hohle ich mir, wie von Abt schon erwähnt, aus einem Debug dump, welcher mit Microsoft.Diagnostics.Runtime (https://github.com/Microsoft/clrmd) wie folgt erstellt wird:
bekomme ich zwar Id´s, die beziehen sich jedoch auf unmanaged Threads. Meine managed Threads sind da leider nicht enthalten.
An die ProcessId hab ich auch schon gedacht, das gibt aber Probleme wenn ich aus dem gleichen Process, aber mit unterschiedlichen AppDomains, arbeite. Aber vielleicht könnte ich ja beides, also sowohl die ManagedThreadID als auch die ProcessId speichert.
ich habe eine Klasse entwickelt welche eine Interprozesskommunikation über MemoryMappedFiles realisiert.
Problem: Wenn ein Prozess sich nicht richtig beendet und abstürzt, bekommen das die Kommunikationspartner nicht mit, wodurch die Kommunikation stehen bleibt (weil gewartet wird bis jeder die aktuelle Nachricht empfangen hat).
Nun dachte ich mir, ich könnte das Problem einfach lösen, wenn jeder Kommunikationsteilnehmer seine ManagedThreadId registriert. Bleibt die Kommunikation stehen, so mein Plan, wird nachgeschaut ob alle regestierten Threads leben und wenn nicht, gibt es eine Fehlerbehandlung.
Schwierigkeit: Wie kann ich alle ManagedThreadId von einen Process abrufen?
Synchronisierung von Eigenschaften bekommt man mit Bindings hin.
Das Label passt sich aber eigentlich der größe des Inhaltes an, sofern das übergeordnete Panal das erlaubt.
Das Label hat im default Style ein Padding. Wenn du die Labelgröße manuell auf die Größe des TextBlocks setzt, wird das Padding stören in dem es das innere Control abschneidet. Probier mal das Padding auf 0 zu setzen.
Virtualisierung ist aktiviert, ich schaue mal nach wie gut das geht, bisher aber keine Probleme.
Anscheinend benutzt VS2015 ja auch Vektorgrafiken, welche man übrigens auch in der VS2015 Image Library einsehen kann.
Man kann ja z.B. Illustrator-Dateien auch als XAML speichern, die Ausgabe ist dann ein Resource-Dictionary mit "einigen" Elementen.
Ich hätte jetzt gedachte, dass das Rendern von diesen Vektorgrafiken noch viel länger dauert und mehr Speicher einnimmt.
mit welcher Icongröße würde man performant ein Programm bebildern, welches auch auf
einem 4k-Bildschirm, bzw. bei höherer dpi gut aussieht?
Normalerweise binde ich Bilder in 96 dpi in meine WPF Programme ein. D.h wenn ich ein 32 wpf-unit Icon "Slot" habe, nehme ich ein 32 px icon.
Wenn ich nun aber möchte, dass das eingebundene Bild auf höheren DPI-Einstellungen gut aussieht, müsste ich ja ein Bild mit höherer Auflösung bzw. einfach mehr Pixeln nehmen.
Also z.B. für ein 16 wpf-unit icon ein 64 px icon.
Das Problem ist dann nur, dass wenn das WPF-Programm auf 96 dpi läuft, das zu große Bild herunterskaliert wird, was je nach qualität performance benötigt.
Wenn ich nun z.B. ein Tree-View mit viele Elementen (z.B. 5000) habe, wobei jedes Item ein Bild enthällt, ist es dann ratsam größere Bilder zu verwenden die man dann runterskalieren lässt?
Wenn du das Binding im Code-Behind erstellt und dort die Source auf ein Objekt setzt, wie soll er das denn überhaubt speichern können? Im Xaml kann man doch auch nicht einfach ein Objekt als Source angeben.