Systemeigenen Typ veröffentlichen
Armin Zingler
stimmt es, dass systemeigene Typen in einer (verwalteten) Assembly
grundsï¿œtzlich nicht so verï¿œffentlicht werden kï¿œnnen, dass sie in einer
anderen Assembly (ebenfalls managed C++) genutzt werden kï¿œnnen?
Gelesen habe ich schon viel zu dem Thema (u.a.
http://msdn.microsoft.com/en-us/library/zbz07712.aspx)
aber eine Aussage zu dieser grundlegenden Frage habe ich noch nirgends
gefunden.
Armin
Jochen Kalmbach [MVP]
> stimmt es, dass systemeigene Typen in einer (verwalteten) Assembly
> grundsï¿œtzlich nicht so verï¿œffentlicht werden kï¿œnnen, dass sie in einer
> anderen Assembly (ebenfalls managed C++) genutzt werden kï¿œnnen?
Die Frage verstehe ich nicht ganz...
Was sind denn "systemeigene Typen"? (ich hasse die deutsche ï¿œbersetzung
vom Englischen).
> Gelesen habe ich schon viel zu dem Thema (u.a.
> http://msdn.microsoft.com/en-us/library/zbz07712.aspx)
> aber eine Aussage zu dieser grundlegenden Frage habe ich noch nirgends
> gefunden.
Dein Link bezieht sich doch auf native-managed-InterOp.... was hat das
jetzt mit Deiner Frage zu tun?
Greetings
Jochen
Armin Zingler
> Hallo Armin!
>
>> stimmt es, dass systemeigene Typen in einer (verwalteten) Assembly
>> grundsï¿œtzlich nicht so verï¿œffentlicht werden kï¿œnnen, dass sie in
>> einer anderen Assembly (ebenfalls managed C++) genutzt werden kï¿œnnen?
>
> Die Frage verstehe ich nicht ganz...
> Was sind denn "systemeigene Typen"? (ich hasse die deutsche
> ï¿œbersetzung vom Englischen).
struct bla
im Gegensatz zu verwalteten
value struct bla
>> Gelesen habe ich schon viel zu dem Thema (u.a.
>> http://msdn.microsoft.com/en-us/library/zbz07712.aspx)
>> aber eine Aussage zu dieser grundlegenden Frage habe ich noch
>> nirgends gefunden.
>
> Dein Link bezieht sich doch auf native-managed-InterOp.... was hat das
> jetzt mit Deiner Frage zu tun?
Das erste Unterthema ist z.B. "Gemischte (systemeigene und verwaltete)
Assemblys" (http://msdn.microsoft.com/de-de/library/x0w2664k.aspx) und genau
darum geht es ja.
Hï¿œtte ich "nativ" statt "systemeigen" verwendet, wï¿œre der nï¿œchste gekommen
und hï¿œtte sich beschwert, dass ich mich nicht an die Terminologie aus der
Doku halte. :-)
Nimm besser diesen Link, der ist hoffentlich unmissverstï¿œndlicher:
http://msdn.microsoft.com/de-de/library/ms235607.aspx
Demnach mï¿œsste es gehen. Oder ich habe den Sinn nicht verstanden.
Der erste Satz unter "Remarks" ist fï¿œr mich eigentlich eindeutig, aber
funktionieren tun tut das irgendwie nicht (...oder ich habe den Sinn nicht
verstanden)
Danke.
Armin
Jochen Kalmbach [MVP]
> struct bla
Danke...
Wie willst Du denn nicht verwaltete Stukturen in .NET sprachen verwenden
(auï¿œer mit StructLayout-Attrribut)?
> Nimm besser diesen Link, der ist hoffentlich unmissverstï¿œndlicher:
> http://msdn.microsoft.com/de-de/library/ms235607.aspx
> Demnach mï¿œsste es gehen. Oder ich habe den Sinn nicht verstanden.
> Der erste Satz unter "Remarks" ist fï¿œr mich eigentlich eindeutig, aber
> funktionieren tun tut das irgendwie nicht (...oder ich habe den Sinn
> nicht verstanden)
Was willst Du denn genau tun?
Strukturen kannst Du eh *nie* exportieren... das geht nicht mal mit
"native DLLs"... du kannst hï¿œchstens eine Instanz einer Struktur
exportieren.. das geht auch immer noch...
Oder was war jetzt Deine Frage!?
Greetings
Jochen
Jochen Kalmbach [MVP]
>> Nimm besser diesen Link, der ist hoffentlich unmissverstï¿œndlicher:
>> http://msdn.microsoft.com/de-de/library/ms235607.aspx
>> Demnach mï¿œsste es gehen. Oder ich habe den Sinn nicht verstanden.
>> Der erste Satz unter "Remarks" ist fï¿œr mich eigentlich eindeutig, aber
>> funktionieren tun tut das irgendwie nicht (...oder ich habe den Sinn
>> nicht verstanden)
>
> Was willst Du denn genau tun?
> Strukturen kannst Du eh *nie* exportieren... das geht nicht mal mit
> "native DLLs"... du kannst hï¿œchstens eine Instanz einer Struktur
> exportieren.. das geht auch immer noch...
Das "make_public" erzeugt ja nur den .NET-"Wrapper" fï¿œr diese native
Struktur...
Wenn Du Dir das mal im Relfector/ILDasm anschaust, dann wird aus:
struct MyStruct
{
int i;
double d;
};
Ein
[StructLayout(LayoutKind.Sequential, Size=0x10), DebugInfoInPDB,
MiscellaneousBits(0x41), NativeCppClass, CLSCompliant(false)]
public struct MyStruct
{
}
Also, sogar noch schlimmer, als wenn es von Hand in C# angelegt worden
wï¿œre... (es fehlen ja die ganzen Member)
Es bingt Dir also (aus meiner SIcht) ï¿œberhaupt nix... die Struktur wird
nur von "internal" nach "public" geï¿œndert...
IMHO kommtst Du um die Header-Datei nicht drum rum...
Greetings
Jochen
Armin Zingler
> Hallo Armin!
>
>> struct bla
>
> Danke...
>
> Wie willst Du denn nicht verwaltete Stukturen in .NET sprachen
> verwenden (auï¿œer mit StructLayout-Attrribut)?
Wenn du C++/CLR auch dazu zï¿œhlst dann z.B. mit
bla* b;
>> Nimm besser diesen Link, der ist hoffentlich unmissverstï¿œndlicher:
>> http://msdn.microsoft.com/de-de/library/ms235607.aspx
>> Demnach mï¿œsste es gehen. Oder ich habe den Sinn nicht verstanden.
>> Der erste Satz unter "Remarks" ist fï¿œr mich eigentlich eindeutig,
>> aber funktionieren tun tut das irgendwie nicht (...oder ich habe den
>> Sinn nicht verstanden)
>
> Was willst Du denn genau tun?
Systemeigene Typen verï¿œffentlichen. ï¿œffentlich machen. Von auï¿œerhalb der
Assembly nutzen kï¿œnnen.
> Strukturen kannst Du eh *nie* exportieren...
Das scheint die Antwort auf meine Frage zu sein.
> "native DLLs"... du kannst hï¿œchstens eine Instanz einer Struktur
> exportieren.. das geht auch immer noch...
>
> Oder was war jetzt Deine Frage!?
Wie ich systemeigene Typen verï¿œffentlichen kann. Mit verwalteten
funktioniert es.
Armin
Armin Zingler
> [...]
> Es bingt Dir also (aus meiner SIcht) ï¿œberhaupt nix... die Struktur
> wird nur von "internal" nach "public" geï¿œndert...
Das habe ich auch festgestellt. Deshalb meine Frage, ob es ï¿œberhaupt mï¿œglich
ist, einen systemeigenen Typ zu verï¿œffentlichen. Wenn das nicht geht bzw nur
auf diesen Weg, der mir letzlich nichts nutzt, dann geht's eben praktisch
nicht. Mir war einfach nicht klar, ob in Assemblies nur verwaltete Typen
verï¿œffentlicht werden kï¿œnnen. Scheint wohl so zu sein. Dass make_public
einen verwalteten Typ daraus macht, wusste ich nicht. Der Doku nach liest
sich das anders - aber egal.
> IMHO kommtst Du um die Header-Datei nicht drum rum...
Was nï¿œtzt mir die Header-Datei? Ich kann ja nicht zwei Assemblys
zusammenlinken. Wenn ich in zwei Assemblies einen Typ gleichen Namens
definiere dann sind das trotzdem zwei verschiedene Typen. Und in einer
Assembly die Deklaration und in der anderen die Definition kann ja
ï¿œberhaupt nicht funktionieren.
Mein Fazit ist, dass ich lediglich mit "void*" (wie es z.B. auch
IntPtr.ToPointer() macht) arbeiten kann und dann entsprechend casten muss.
Ist zwar ï¿œrgerlich, aber ï¿œber Assembly-Grenzen hinweg ist das wohl der
einzige Weg, um native Daten auszutauschen.
Oder wenn Du's genau wissen willst:
Ich habe eine Assembly mit verwalteten Wrappen fï¿œr ein paar
DirectShow-Features geschrieben. Diese Assembly nutze ich in einer anderen
C++/CLR-Assembly. Das funktioniert alles wunderprï¿œchtig, nur muss ich in
letzterer zwangslï¿œufig irgendwann auf den nativen Interface-Pointer (z.B.
das DirectShow-Interface IBaseFilter) zugreifen. Diesen habe ich in der
verwalteten Klasse als Eigenschaft mit dem Typ ::IBaseFilter*
verï¿œffentlicht.
interface class IBaseFilter // managaed
{
::IBaseFilter* property NativePointer.... // ::IBaseFilter = native
}
Die Eigenschaft NativePointer ist in der referenzierenden Assembly auch
sichtbar (natï¿œrlich nur im C++-Client aber da brauche ich sie auch nur)
aber ich kann die Eigenschaft nicht nutzen, da ich den Wert nirgends
zuweisen kann. Ich kann zwar auch eine Variable vom
Typ ::IBaseFilter* (das native Directshow-Interface) deklarieren, aber das
ist ja nicht derselbe Typ wie der der Eigenschaft der verwalteten Klasse.
Deswegen ist auch mein Fazit, dass es immer "void* property NativePointer"
heiï¿œen muss.
Und warum ich das mache: Weil ich in VB 100x produktiver bin um die
eigentliche Anwendung zu schreiben. Ich kï¿œnnte mir auch die managed wrapper
sparen und alles in C++ schreiben, aber dann wï¿œre ich in 100 Jahren noch
nicht fertig.
Armin