Mit Version 3.3Patch2 hat es noch funktioniert.
Ich verstehe ehrlich gesagt die Fehlermeldung nicht. MyControl.dll ist keine Interface-Komponente, das ist einfach eine Library-DLL die nichts mit CoDeSys zu tun hat und die in meinem Plugin verwendet wird. Die selbe Konstellation hab ich in anderen Plugins auch, ein Problem tritt nur auf wenn die Library-DLL WPF verwendet.
Hat irgend jemand eine Idee, wie ich dieses Problem lösen kann?
Die beiden Projekte MyView.plugin und MyControl in eines zusammenzuführen kommt nicht in Frage, da MyApp.exe unabhängig von CoDeSys bleiben soll.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
zur V3.4 wurden neue Prüfungen eingebaut, die verhindern sollen, dass Interface-Komponenten GAC-Komponenten referenzieren. Dazu mehr unten. Das Wichtigste wird erst mal sein, die Plug-Ins wieder zum Laufen zu bekommen. Hier sehe ich zwei Möglichkeiten:
- IPMCLI wird mit /idrc statt mit /i aufgerufen. Damit werden die zusätzlichen Prüfungen deaktiviert und das Tool verhält sich wie unter V3.3
- MyControl wird signiert. Damit wird es vom Component Manager nicht mehr als Interface-Komponente erkannt, sondern in den GAC installiert.
Eine ausführliche Begründung, warum diese Prüfung eingebaut wurde, befindet sich unter http://dn.codesys.com/de/node/31. (Hierbei handelt es sich um einen Artikel unseres neuen (noch nicht ganz offiziellen) Developer Networks, das u.a. eine wichtige Informationsquelle für Automation Platform-Entwickler werden soll. Einfach Account erstellen und sich via PM an mich für den Automation Platform-Bereich freischalten lassen.)
Eine Kurzfassung der Begründung möchte ich aber auch in diesem Rahmen nicht schuldig bleiben. Es ist so: Wenn in einem Interface ein Typ aus einer GAC-Komponente verwendet wird, sei es als Parameter oder als Rückgabewert, und die Version der GAC-Komponenten ändert sich, dann wird wegen den strengen CLR-Typprüfungen die Schnittstelle inkompatibel. Dadurch würde einer wichtigsten Regeln der Automation Platform verletzt werden. Das größte Problem ist, dass man das zur Compile-Zeit nicht bemerkt, sondern erst in ferner Zukunft, wenn es mal eine neuere Version der GAC-Komponente gibt. Wir haben bei 3S selbst diese leidvolle Erfahrung machen müssen und deswegen eine ganze Schnittstellengruppe "sterben" lassen müssen (was zwar auch gegen die Regeln ist, aber in diesem Fall leider unvermeidlich war; Gott sei Dank handelte es sich um selten verwendete Schnittstellen, so dass bisher kein Kunden-PlugIn davon betroffen war).
In dem konkret geschilderten Fall gibt es natürlich von uns noch Verbesserungsbedarf. Da die PresentationFramework.dll zum .NET-Framework gehört, darf sie eigentlich nicht in die Prüfung eingehen, da es in der CLR spezielle Auflösungmechanismen gibt (genauso wie für mscorlib, System.Windows.Forms, etc., die ja strenggenommen auch GAC-Komponenten sind, aber bedenkenlos in Interfaces verwendet werden dürfen, da .NET sie besonders behandelt).
Grüße
Kevin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Danke für die detaillierte Antwort. Das mit dem signieren hat funktioniert, meine Plugins lassen jetzt bei CoDeSys 3.4 installieren.
Ich hab mich im Developer Network angemeldet (gleicher Username wie hier, roland_s). Ich schaffe es allerdings nicht, eine PM zu schicken. Kann es sein, dass das in diesem Forum deaktiviert ist?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ich habe gerade auf CoDeSys Version 3.4SP1 upgedatet, und meine Plugins funktionieren nicht mehr.
Ich habe folgende Assemblies:
Bei der Installation von MyView.plugin.dll als Plugin kriege ich die Fehlermeldung:
Mit Version 3.3Patch2 hat es noch funktioniert.
Ich verstehe ehrlich gesagt die Fehlermeldung nicht. MyControl.dll ist keine Interface-Komponente, das ist einfach eine Library-DLL die nichts mit CoDeSys zu tun hat und die in meinem Plugin verwendet wird. Die selbe Konstellation hab ich in anderen Plugins auch, ein Problem tritt nur auf wenn die Library-DLL WPF verwendet.
Hat irgend jemand eine Idee, wie ich dieses Problem lösen kann?
Die beiden Projekte MyView.plugin und MyControl in eines zusammenzuführen kommt nicht in Frage, da MyApp.exe unabhängig von CoDeSys bleiben soll.
Hallo roland_s,
zur V3.4 wurden neue Prüfungen eingebaut, die verhindern sollen, dass Interface-Komponenten GAC-Komponenten referenzieren. Dazu mehr unten. Das Wichtigste wird erst mal sein, die Plug-Ins wieder zum Laufen zu bekommen. Hier sehe ich zwei Möglichkeiten:
- IPMCLI wird mit /idrc statt mit /i aufgerufen. Damit werden die zusätzlichen Prüfungen deaktiviert und das Tool verhält sich wie unter V3.3
- MyControl wird signiert. Damit wird es vom Component Manager nicht mehr als Interface-Komponente erkannt, sondern in den GAC installiert.
Eine ausführliche Begründung, warum diese Prüfung eingebaut wurde, befindet sich unter http://dn.codesys.com/de/node/31. (Hierbei handelt es sich um einen Artikel unseres neuen (noch nicht ganz offiziellen) Developer Networks, das u.a. eine wichtige Informationsquelle für Automation Platform-Entwickler werden soll. Einfach Account erstellen und sich via PM an mich für den Automation Platform-Bereich freischalten lassen.)
Eine Kurzfassung der Begründung möchte ich aber auch in diesem Rahmen nicht schuldig bleiben. Es ist so: Wenn in einem Interface ein Typ aus einer GAC-Komponente verwendet wird, sei es als Parameter oder als Rückgabewert, und die Version der GAC-Komponenten ändert sich, dann wird wegen den strengen CLR-Typprüfungen die Schnittstelle inkompatibel. Dadurch würde einer wichtigsten Regeln der Automation Platform verletzt werden. Das größte Problem ist, dass man das zur Compile-Zeit nicht bemerkt, sondern erst in ferner Zukunft, wenn es mal eine neuere Version der GAC-Komponente gibt. Wir haben bei 3S selbst diese leidvolle Erfahrung machen müssen und deswegen eine ganze Schnittstellengruppe "sterben" lassen müssen (was zwar auch gegen die Regeln ist, aber in diesem Fall leider unvermeidlich war; Gott sei Dank handelte es sich um selten verwendete Schnittstellen, so dass bisher kein Kunden-PlugIn davon betroffen war).
In dem konkret geschilderten Fall gibt es natürlich von uns noch Verbesserungsbedarf. Da die PresentationFramework.dll zum .NET-Framework gehört, darf sie eigentlich nicht in die Prüfung eingehen, da es in der CLR spezielle Auflösungmechanismen gibt (genauso wie für mscorlib, System.Windows.Forms, etc., die ja strenggenommen auch GAC-Komponenten sind, aber bedenkenlos in Interfaces verwendet werden dürfen, da .NET sie besonders behandelt).
Grüße
Kevin
Danke für die detaillierte Antwort. Das mit dem signieren hat funktioniert, meine Plugins lassen jetzt bei CoDeSys 3.4 installieren.
Ich hab mich im Developer Network angemeldet (gleicher Username wie hier, roland_s). Ich schaffe es allerdings nicht, eine PM zu schicken. Kann es sein, dass das in diesem Forum deaktiviert ist?