Soweit ich das sehe hast du aus MyClass das Ereignis MyEvent nicht abonniert.
Das einzige was ich sehe ist das du mit der Eigenschaft NewValue rumspielst.

Diese würde zwar das Ereignis auslösen, dieses musst du aber noch abonnieren.
Zum Beispiel in deiner Form1.

Dies hattest du wahrscheinlich auch hier vor:

private void Form1_Load(object sender, EventArgs e)
        {
            MyObject.NewValue += new CustomEvents.MyEventHandler(ShowMyEventInfo);
        }

aber in diesem fall änderst du nur den string Wert von NewValue.

Eigentlich hätte ich hier erwartet das der Compiler eine Fehlermeldung schmeißt, wenn er dies nicht tut wird wohl implizit ToString oder so aufgerufen.

Richtig wäre:

private void Form1_Load(object sender, EventArgs e)
        {
            MyObject.MyEvent += new CustomEvents.MyEventHandler(ShowMyEventInfo);
        }

(Ungetestet)

schau dir oben den TextFieldParser an.
Da kannste Trennzeichen angeben und ob Textbereiche in Hochkommas stehen.

da gibts schon was von ratiopha... eh microsoft
TextFieldParser-Klasse

musst nur als referenz Microsoft.VisualBasic noch mit in dein projekt aufnehmen.

Ich vermute mal durch deine autmatische Generierung kamen höchst wahrscheinlich Steuerzeichen mit in die Datei.

Bei mir und/oder Kollegen schmiert öfters mal VisualStudio einfach ab, während des Compilierens (VS 2010), ohne irgendeiner Meldung.
Wäre da nicht vorher das auto. Speichern hät ich manchmal schon probleme gehabt.

Oder ganz banal (auch schon auf arbeit passiert) wenn jemand versucht einen Baum auszubudeln, mit nem Bagger, und dabei die Stromleitung trifft.
(Von dem her klicke ich schon selbst öfters mal auf Speichern)

Wenn ich mich gerade nicht irre gibt es ja ein ControlAdd Ereignis (oder so ähnlich).
Ich würde das einfach mal abonnieren und dann mal im CallStack schauen wos herkommt.

Kam eine Fehlermeldung in der Art das DLL oder abhängigkeit nicht gefunden werden konnte oder DLL in falscher Version geladen wurde?

Wenn ja könnt es auch einfach sein das du beim kompilieren die AssemblyVersion erhöht hast, in diesem Fall müssen die Projekte neu kompiliert werden die diese DLL einsetzen.
Alternative wäre einfach nur die Dateiversion zu erhöhen, dann müsstest du die anderen projekte auch nicht neu kompilieren.

den standard konstruktor als private brauchts nicht.

sobald ein konstruktor mit parametern existiert, muss man auch explizit den parameterlosen mit anlegen um diesen verwenden zu können.

Ich würde mal Quellcode runterladen, wenn möglich, oder mit reflector/ilspy reinschauen.
Klingt nach nem Bug in diesem Framework.

Ich kenne ebenfalls das problem und bin gerade am überlegen.
Ich glaube anstelle von Panels, wenn ich da UserControls verwendete, hatte ich das phänomen nicht, bin mir da aber grad nicht mehr so sicher.

Die Option mit Höhe 0 wäre für mich damals nicht möglich gewessen, da bei mir die Panels/UserControls selbst einige auf AutoSize standen.

aus meiner Sicht spricht nichts gegen die Verwendung eines Defaultwerts. Ich habe es nicht probiert, aber vielleicht klappt das sogar einfach mit einem DefaultValueAttribute für die Property.

Klappt auch, würde sogar die XML Datei verkleinern da nur die Eigenschaften serialisiert werden deren werde nicht laut DefaultValueAttribute sind.

Könntest versuchen das Programm mal über den application verifier laufen zu lassen, ev. bringt der bessere fehlerbeschreibung/lokalisierung.

Ich versteh das Problem nicht wirklich.
Du hast ja die DLL entfernt, wie soll er da noch das Objekt finden, wenns nicht mehr da ist 🤔

Wie ist den die genaue Meldung, ansosnten würde ich noch vermuten das ev. jetzt eine andere strongname version der dll oder ev. AssemblyVersion unterschiedlich?

Ev. auch cirkuläre referenzen der dll's das die neuste "verloren" geht?

Ich verwende jetzt eine weitere Interface DLL's in der hab ich alle mir benötigten Interfaces angeben.

In der "Wrapper" DLL hab ich die benötigten Objekte abgeleitet und die interfaces angegeben.

Die "Wrapper" DLL wird komplett per Reflection geladen, sowie die Objekte instanziiert und dann je nach Schnittstelle das zurück kommende Objekt nach seinem interface gecastet.

So bekomme ich die oben genannte Warnung nicht mehr.

Und noch ein Vorteil, die komponente und die wrapper dll liegen in einem unterverzeichnis bei uns, jetzt meckert auch ngen nicht mehr.

(ngen ist nur mehr als Prüfung ob alle DLLs da/richtig sind bevors zur Auslieferung geht)

So wie ich das verstehe möchte der Threadersteller einfache strings kombinieren um einen kompletten Dateipfad zu erzeugen mit dem er das jeweilige Bild laden kann.

@Ersteller

normal über den + operator

string s1 = "hallo";
string s2 = "wie gehts";
string s3 = s1+" Welt " + s2;

oder string.Concat

string s1 = "hallo";
string s2 = "wie gehts";
string s3 = string.Concat(s1, "Welt", s2);

Kannst du genaueren Code Beispiel liefern?

Meine Idee wäre, wenn Klasse B nur innerhalb von A lauffähig ist, im Construktor von B dann eine Instanz von A mit zu übergeben.
B selbst wird intern von A erzeugt und A per this Zeiger an B weitergegeben.

dank dir erstmal das de dich des problem annimmst.

Aber wie gesagt ich will die warnung nicht komplett ausschalten, weshalb es mir theoretisch nixs nützen würde wenn es in der assembly.cs funktionieren würde.

das problem hängt ja mehr an der projektdatei selbst,
weshalb ich gehofft hatte man könnte da vielleicht ein attribute oder so bei einigen referenzen in der xml direkt angeben,
das bei diesen die warnung unterdrückt werden soll

Komplett will ich die Meldung ja nicht abschalten, bei anderen DLLs ist diese ja auch richtig.

Nur bei meiner soll dies nicht erscheint da ich dort die Verwaltung und das laden der DLL selbst übernehme, so das ein parell lauf beider Versionen auf einem Formular möglich ist.

Der parallel lauf so funktioniert ja auch, ich habs auf mehreren System ohne GAC, VS und so probiert.
(Process Explorer hat mir auch gezeigt das die DLLs 15er und 20er richtig geladen wurden)
Beide Controls waren sichtbar und man konnte Aktionen drauf ausführen.

Und wie gesagt das ganze zeugs der 20iger DLL habe ich in meiner "Wrapper" DLL, und diese gibt nichts davon direkt nach außen.

Ich hatte gehofft ev. gebts irgendwas das man direkt in die csproj Datei eintragen könnt.

Im Prinzip ist das garnicht so kompliziert.

1. Du musst nur von UserControl ableiten.

2. Dort die Eigenschaft DisplayRectangle überschreiben, für den Client Bereich, wo Controls draufgezogen werden können.
   (Achtung, wenn AutoScroll an dort ev. noch AutoScrollPosition mit beachten, für X,Y)

3. OnPaint Überschreiben für die Header anzeigen und entsprechend mit den Mausereignis auf klick reagieren zum auf/zuklappen. (Image für auf/zu dort zeichnen und in mausereignis entsprechend Koordinaten abfragen)

4. Dieses Control einfach mit Dock.Top docken und beim zuklappen alte höhe merken und höhe auf höhe des headers setzen, beim aufklappen höhe auf alte höhe

Edit:

[Designer(typeof(System.Windows.Forms.Design.ScrollableControlDesigner), typeof(System.ComponentModel.Design.IDesigner))]

Noch setzen damit de im Designer Controls draufziehen kannst

Noch irgendwer Ideen wie ich die Warnung, wie oben im ersten Post geschrieben, im VS abschalten kann?
Und natürlich am besten nur für diese eine "Wrapper" DLL.

Die app.config hat irgendwie auch nicht wirklich was gebracht.

Wie gesagt so läuft meine DLL.

Die Warnung kommt auch nur weil meine "Wrapper" DLL die 20iger Version referenziert hat.
Ich gebe aber nixs aus der 20iger weiter.

Wenns hilft, ich müsste diese Warnung auch nur bei 2 Projekten ausschalten.
Die weiteren Projekte verwenden wiederrum diese (2 anderen DLLs) und da gibt es keine probleme mehr.

Lizenzprüfung der dritt Komponente konnt ich auch alles intern umleiten, theoretisch steht also nixs weiter im wege.

Nur die Warnung ist halt störend.

Ich habe eine 15er Version der dritt komponente und eine 20er Version.

Er lädt auch beide DLL's, im VS über Debug->Windows->Modules, seh ich auch das beide geladen wurden.
Ich seh auch beide Controls auf meinem Formular.

Ich hät jetzt gern das die Warnung im VS nicht mehr auftaucht.

Für die 20er Version habe ich eine eigene DLL erstellt welche das ganze handling übernehmen soll.
Die dritte Komponente wird dort intern in einem Control zur Laufzeit geladen.
Nach außen hin ist nur ein standard Control vom Typ Control verfügbar.

Im Prinzip gehts mir darum das weitere Projekte nicht merken/mitbekommen sollen das meine DLL diese 20iger DLL benötigt.

Ich habe diese 20iger DLL allerdings als normale referenz in meiner "Wrapper" DLL drin.
Mit copy local false, das laden der assembly übernehme ich.
(Ich habs als referenz drin für einfacheren Zugriff auf die objekte die ich intern brauche in meiner "Wrapper" dll.)

Hoffe ist verständlich was ich vor habe.

Edit:
Ach übrigens VS 2010, und Framework 2.0

Hi leute,
ich habe eine dritt anbieter komponente.

diese komponente muss in einer alten version weiterlaufen können und einige projektbestandteile sollen schon auf die neue version umgestellt werden.

Das problem ist die .net dll's zwischen den versionen haben immernoch den gleichen Assemblyname.

Für die neue Version habe ich schon extra eine neue DLL erstellt welche intern die ganzen aufrufe übernimmt und nach außen hin eigentlich von dieser dritten komponente nixs weiter gibt.

Will ich jetzt die alte und die neue version (die neue über meine dll) in einer exe laufen lassen bekomme ich immer noch die Meldung:> Fehlermeldung:

Found conflicts between different versions of the same dependent assembly.

Zur Info:
Beide Parallel laufen zu lassen hatte ich in einem ersten testprojekt getestet bevor wir die neue Version wirklich kauften, das geht soweit.

Mir gehts jetzt nur noch drum das VisualStudio nicht mehr meckert und vorallem meine Kollegen von den internen sachen nixs wissen/beachten müssen/sollen.

Ach warum setzt du überhaupt die komplette DataSource neu?

Müsste doch nur der Datensatz der Zeile sein oder?
Arbeitest du mit INotifyPropertyChanged und BindingList<T>?

Laut deinem Bild wird versucht die Spalten des Grids neu zu erstellen, mal AutoGenerated ausgeschaltet und direkt die Spalten fest vordefiniert?

Oder ganz blöd einfach SplitContainer verwenden
und die Controls auf die jeweiligen Panels mit Dock Fill.

Ganz ehrlich, ich kann mir irgendwie beim besten willen nicht vorstellen das es an der listview liegt.
Ich würde mal behaupten das Bild, welches rutnergeladen wird ist irgendwie im Arsch und hat eine breite von 0.

Ach seh grad oder könnte auch effnach am using liegen, du solltest das Bild nicht wieder freigeben wenn des eh noch brauchst.

Nachdem scrollen Invalidate() des Controls (welches zeichnet) aufrufen.
Damit wird dein Control neugezeichnet wenns vom System die nächste zeichenaufforderung bekommt.

Ist ähnlich wie Refresh() nur net ganz so hart.

Ev. wäre TXTextControl noch was für dich.

Hab allerdings weniger gute Erfahrung damit wenn man dem User selbst die Möglichkeiten gibt Dokumente zu ändern.
Allerdings hab ich bei mir das auch ziemlich für Reports aufgebohrt, denke mal bei std. Sachen sollte es da keine probleme geben.

Edit:
Bisher aber nur Erfahrung mit der 15 Version.
Die 20iger liegt grad noch rum zum einbinden.

Schau mal hier:
Custom ContainerControl

beim MyGroupControlDesigner der Aufruf EnableDesignMode in der Initialize Methode.
Sowas in deinem Designer müssteste noch mit angeben.

Hat das Elternformular einen Container (UserControl, Panel, etc) und auf diesen Container werden die Controls gezogen/verändert?
Wenn ja muss ev. der Container für den Designer noch freigegeben werden.

Was ich nur noch anmeckern wollte, wenn es verschachtelt sein soll nutzte die Namespaces richtig.

Als Beispiel das Namespace System
Dort findest du alle gängigen Datentypen

Im Namspace System.Collections
befinden sich die Auflistungen.

Im Grund auch ganz einfach anlegbar über den "Punkt" trenner

namespace Haupt
{
}
namespace Haupt.Unterpunkt
{
}

ValueMember und DisplaMember sind Eigenschaft die für die Datenbindung gebraucht werden.

Erstmal, dies über die Schleife zu setzen hätte wohl nixs gebracht da in diesem Fall das letzte setzen gewonnen hätte, du hast hier immer die gleiche Spalte geändert.

Und ich vermute mal das hat das ganze verlangsamt da höchst wahrscheinlich die Datenbindung immer neu gesetzt wurde (die Anzeige) bei zuweisung der Eigenschaften.

ich denke mal bei deinem Generic Write<T> sollte der parametertyp auch T sein.
sonst verstehe ich den sinn dieser methode nicht.

oder überhaupt was du da gerade vor hast ?(

ich glaube ich persönlich würde eifnach object zulassen aös Parameter für eine Write Methode und dieses objekt auf das Attribute SerializeableAttribute prüfen und/oder ob ISerializeable Schnittstelle gesetzt ist und dann intern BinaryFormatter aufrufen.

Wenns geht versuche ich die Verwendung von var zu vermeiden.

Ich empfinde das einfach als nicht schön zu lesen, vorallem wenn man mal in Projekte anderer rein muss und dann erstmal die Objekte verstehen muss.

Mag schon sein das die IDE da auch einem bei hilft aber ich persönlich versuche erst garnicht solche hürden für andere zu stellen.

Und auch Microsoft sagt ja:

Der Einsatz von var kompliziert jedoch potenziell Ihren Code, sodass andere Entwickler ihn nur schwer nachvollziehen können. Aus diesem Grund wird in der C#-Dokumentation var im Allgemeinen nur verwendet, wenn es erforderlich ist.

Kenne sowas in Verbindung mit Schriftart wechsel.
Könnt es ev. an nem Font Scale liegen?

Sollte eigentlich normal über dem DbDataReader mit GetValue abfragbar sein.
Da sollte dann ein byte Array zurück kommen.

Das am besten als datei irgendwo temporär Speichern und mit Process.Start starten.
Ist die anwendung registriert müsste eigentlich das richtige Programm dann aufgehen.

Eigentlich sollte der Explorer das selbst händeln.
Glaube aber auf die File Liste als Angabe reagiert er nicht.

Mittels FileDescriptor sollte es gehen.

Ich hab nur mal schnell gegoogelt da ich kein VisualStudio hier habe, aber so ungefähr sollte es gehen:
How to use filegroupdescriptor to drag file to explorer c#

Arbeite mit PropertyDescriptor (über TypeDescriptor abfragbar) oder PropertyInfo (über Type abfragbar) und ihren entsprechend GetValue, SetValue Methoden.
Du musst zwar eine Instanz deines Objektes mitgeben, aber da würde eine einfache object Variable reichen (sprich Typ muss nicht direkt bekannt sein).

Ich persönlich halte nicht viel von DataSets und finde ein ordentliches Objektmodell pflegeleichter.
Einerseits für dich, andererseits auch für dritte die mit am Projekt dann arbeiten und nixs von der eigentlichen DB wissen müssten.

Und selbst bei 30 Tabellen gehen ich mal davon aus das es als Einstiegspunkt für die GUI nur vielleicht eine Handvoll Tabellen vielleicht geben wird, welche dann erst die weiteren Tabellen als weitere "Eigenschaftensbeschreibungen" benötigen.

Kann mich zwar grad irren aber das verhalten meine ich auch schon aus Win7 und XP zu kennen (mit .Net 2.0).
Jedenfalls kommt mir das problem ziemlich bekannt vor und ich achte deshalb schon länger drauf bei gebundenen Objekten.

Ich würde für die Listen einfach auf IEnumerable prüfen.
Damit hättest eigentlich alle Listen und Arrays mit erschlagen, das könnteste problem im foreach durchlaufen und rekursiv deine methode wieder aufrufen.

Schaut für mich nach DataGridView aus.
Oder wenn auch kostenfplichtige Componenten erlaubt sind.
C1FlexGrid von ComponentOne, gerade das finde ich ein leicht zu bedienendes aber mächtiges grid control.

Hast du noch ein StackTrace?
Ich erkenne aus dem obigem Code erstmal nicht warum es krachen sollte, mit dieser Meldung.

Du instanziierst ja ein neues Formular und rufst für dieses ShowDialog auf, schaut erstmal richtig aus.

eigentlich sollte es so sein, in der regel, das zu beginn die DataSource den zu bindenden Typen erhält (typeof(XXX)).
Dann Dispaly-/ValueMember setzen und wenn daten da sind entsprechend Liste/Objekte übergeben.

DataSource auf null setzen ist immer bissl triggy, zumindest die normalen Datenbindings der Controls gingen bei mir damit immer verloren, deshalb setze ich da eher dann immer mit typeof(xxx) oder so zurück.

Wenn du die abonnierten Ereignisse etc. beibehalten willst und wirklich eifnach blos die anzeige verschieben willst.
Setzt einfach die TabPage auf TabControlA, B oder C.
Oder mittels UserControl steuern.

Einer Fehlerliste ist immer, finde ich, solch eine Sache.
In meinem aktuellem Projekt verwende ich auch eine Art Fehlerliste, aber die Fehler dich ich da reinschreibe sind eher Warnungen die den kompletten Programmfluss nicht durchbrechen und soll später mehr als interaktion für den User dienen was er machen soll (oder welche weiteren Schritte ich durchführe).

Ich gebe irgendwie lieber entsprechende Statuse als Enum zurück.

Ansonsten prüfe ich schon in der GUI ob alle Daten zum start einer Methode da sind.
Und bringe entsprechende Hinweise für den User.

In der Methode selbst wird nochmal geprüft und knallhart Exception geschmissen wenn ich mit den übergebenen Daten nixs anfangen kann.
Wie oben schon beschrieben Parameterprüfung.

Und Exceptions sollten auch nicht als GoTos behandelt werden.
Wird eine Exception geschmissen wird diese meist erst an oberster Stelle abgehandelt, was in der Regel die GUI sein sollte.

Was eher sinnvoll wäre wäre ein
Try{}finally{}
(also ohne catch) in kritischen Methoden wenn man Speicher/Sachen freigeben will/muss.

Ansonsten, mit ordentlicher Kommentierung des Codes, finde ich, versteht man immernoch am besten den Ablauf. 😁

Ach nochwas zur performance von Exceptions.
Die gehen schon auf die performance, wenn diese in einer schleife bewusst in kauf genommen werden und dort wirklich als goto, oder als "faule" validierung, verwendet werden.

Das mit \k steht in der msdn zu regular expressions.
Sprachelemente für reguläre Ausdrücke – Kurzübersicht

Hast du das DesignerSerializationAttribute bei der Eigenschaft auch mit Content belegt?
Ansonsten Code............

Vielleicht hilft es auch das Programm mal mit Application Verifierer zu starten, ev. sieht man da auch dann bissl was.

öh einfach System.IO.StreamReader ausm Framework zum lesen
und zum schreiben/ersetzten wäre ja dann StreamWriter, theoretisch müsst ja nur dann die Position zum setzten/weiterlesen entsprechend gesetzt werden