Shell API über DllImport hinzufügen

[Grumbach, Andre]

Hallo zusammen,
ich habe vor geraumer Zeit ein Programm geschrieben, das auf die Shell32.ddl
zugreift.

Dazu habe ich einfach eine Reference auf diese DLL gemacht und kann dann
einfach drauf zugreifen.

Nachdem ich die Klasse:
Shell32.ShellClass initalisiert habe, kann ich mir über
shell.NameSpace(Pfad) den Ordner ausgeben lassen.
Das funktioniert nun auch alles ganz gut.

Nun würde ich jedoch die Referenz entfernen (da ich durch Vista immer eine
andere Version habe),
Nun ist jedoch die Frage wie ich solche funktionen neu einbinden kann.
Ich bin bisher auf Sachen wie z.B.
[DllImport("shell32.dll")] gestossen, jedoch bekomm ich immer einen PInvoke
Fehler.
wen ich folgende Methode aufrufe:

[DllImport("shell32.dll")]
public static extern object NameSpace(object dir);

Kann mir jemand sagenw ei ich Methoden aus der DLL so einbinden kann, das
der Aufruf funktioniert?

Danke schon einmal,
Andre

[Frank Dzaebel]

Hallo Andre,

Post by Grumbach, Andre
Shell32.ShellClass initalisiert habe, kann ich mir über
shell.NameSpace(Pfad) den Ordner ausgeben lassen.
Das funktioniert nun auch alles ganz gut.

ja.

Post by Grumbach, Andre
Nun würde ich jedoch die Referenz entfernen (da ich durch
Vista immer eine andere Version habe), [...]
Kann mir jemand sagenw ei ich Methoden aus der DLL so einbinden kann, das
der Aufruf funktioniert?

Brauchst Du ggf. gar nichts einbinden, da
COM-Objekt. Kannst Du z.B. versionslos über
folgende Konstruktion(en) erreichen:

(ungeprüft auf Vista)

{
Type typeShell = Type.GetTypeFromProgID("Shell.Application", true);
object shell = Activator.CreateInstance(typeShell);
object folder = Call(shell, "NameSpace", @"C:\Windows");
object folderItem = Call(folder, "ParseName", "clock.avi");
MessageBox.Show(Call(folder, "GetDetailsOf",
folderItem, 2).ToString());
}

private object Call(object target, string methodName,
params object[] parameters)
{
return target.GetType().InvokeMember(methodName,
BindingFlags.InvokeMethod | BindingFlags.OptionalParamBinding,
null, target, parameters);
}

Andere Sache:
Geht denn unter Vista das Einbinden des COM-Verweises
auf die "Microsoft Shell Controls And Automation" DLL nicht?


ciao Frank
--
Dipl.Inf. Frank Dzaebel [MCP/MVP C#]
http://Dzaebel.NET

[Frank Dzaebel]

Post by Frank Dzaebel
Geht denn unter Vista das Einbinden des COM-Verweises
auf die "Microsoft Shell Controls And Automation" DLL nicht?

Sollte auf Vista funktionieren. Vista fügt zwar ein paar neue Schnittstellen
hinzu (z.B. IShellDispatch5, IShellFolderViewDual3, ... viele andere), aber
das sollte die alten Befehle nicht beeinflussen, ausser ggf.
"IShellExecuteHook" o.ä.. Wie immer in COM-Szenarien, gegen die niedrigste
unterstützte Interop Assembly codieren und diese ggf. mit ausliefern.

Shell shell = new Shell();
Folder folder = shell.NameSpace(@"C:\Windows\System32");
FolderItem folderItem = folder.ParseName("calc.exe");
MessageBox.Show(folder.GetDetailsOf(folderItem, 2)); //Anwendung


ciao Frank
--
Dipl.Inf. Frank Dzaebel [MCP/MVP C#]
http://Dzaebel.NET

[Grumbach, Andre]

Hi Frank,
mein Problem ist jedoch, selbst wenn ich diese COM-DLL hinzufüge und
Einstelle das keine Lokale kopie gemacht werden soll, erstellt mit VS bei
der Projektausgabe immer eine Interop.Shell32.dll.

Deshalb will ich es mal komplett ohne Referenz probieren.

Oder hast du eine Idee weshalb er mir die DLL trotz der Einstellung Lokale
Kopie=Nein trotzdem eine DLL ausgibt?

Danke,
Andre

Post by Frank Dzaebel

Post by Frank Dzaebel
Geht denn unter Vista das Einbinden des COM-Verweises
auf die "Microsoft Shell Controls And Automation" DLL nicht?

Sollte auf Vista funktionieren. Vista fügt zwar ein paar neue
Schnittstellen hinzu (z.B. IShellDispatch5, IShellFolderViewDual3, ...
viele andere), aber das sollte die alten Befehle nicht beeinflussen,
ausser ggf. "IShellExecuteHook" o.ä.. Wie immer in COM-Szenarien, gegen
die niedrigste unterstützte Interop Assembly codieren und diese ggf. mit
ausliefern.
Shell shell = new Shell();
FolderItem folderItem = folder.ParseName("calc.exe");
MessageBox.Show(folder.GetDetailsOf(folderItem, 2)); //Anwendung
ciao Frank
--
Dipl.Inf. Frank Dzaebel [MCP/MVP C#]
http://Dzaebel.NET

[Frank Dzaebel]

Hallo Andre,

Post by Grumbach, Andre
Deshalb will ich es mal komplett ohne Referenz probieren.

Das habe ich Dir schon im ersten Posting gezeigt,
wie man ohne Referenz auskommt.

Post by Grumbach, Andre
Oder hast du eine Idee weshalb er mir die DLL trotz
der Einstellung Lokale Kopie=Nein trotzdem eine DLL ausgibt?

Wenn Du früh gebunden einen Shell-Typ haben
willst, brauchst Du auch eine Klasse dafür, die
irgendwo definiert ist. Der Interop Proxy
bildet diesen Klassen. Ohne solche Klassen
kannst Du nicht früh gebunden arbeiten.

Also, wenn Du ohne Referenz arbeiten musst/
möchtest, mach es so, wie in meinem ersten
Posting, oder bilde Dir ggf. noch eigene Klassen.
DllImport ist hier normal nicht angebracht, nur wenn
Du Nicht-COM-Methoden ansprechen musst/willst, wie
etwa SHGetFileInfo o.ä..


ciao Frank
--
Dipl.Inf. Frank Dzaebel [MCP/MVP C#]
http://Dzaebel.NET

[Grumbach, Andre]

Hallo Frank,
jo ich bin auch derzeit dabei das ganze umzustellen und eigen Klassen zu
erstellen.

Bei der Lokalen kopie geht es nur um deinen Hinweis mit dem COM-Verweises
den ich gesetzt habe.
Dabei wird mir immer eine lokale kopie der DLL erstellt obwohl ich es
ausgeschalten habe.

Andre

"Frank Dzaebel" <***@daimlerchrysler.com> schrieb im Newsbeitrag news:***@g4g2000hsf.googlegroups.com...
Hallo Andre,

Post by Grumbach, Andre
Deshalb will ich es mal komplett ohne Referenz probieren.

Das habe ich Dir schon im ersten Posting gezeigt,
wie man ohne Referenz auskommt.

Post by Grumbach, Andre
Oder hast du eine Idee weshalb er mir die DLL trotz
der Einstellung Lokale Kopie=Nein trotzdem eine DLL ausgibt?

Wenn Du früh gebunden einen Shell-Typ haben
willst, brauchst Du auch eine Klasse dafür, die
irgendwo definiert ist. Der Interop Proxy
bildet diesen Klassen. Ohne solche Klassen
kannst Du nicht früh gebunden arbeiten.

Also, wenn Du ohne Referenz arbeiten musst/
möchtest, mach es so, wie in meinem ersten
Posting, oder bilde Dir ggf. noch eigene Klassen.
DllImport ist hier normal nicht angebracht, nur wenn
Du Nicht-COM-Methoden ansprechen musst/willst, wie
etwa SHGetFileInfo o.ä..


ciao Frank
--
Dipl.Inf. Frank Dzaebel [MCP/MVP C#]
http://Dzaebel.NET

[Frank Dzaebel]

Hallo Andre,

Post by Grumbach, Andre
jo ich bin auch derzeit dabei das ganze umzustellen
und eigen Klassen zu erstellen.

ja, ok.

Post by Grumbach, Andre
Bei der Lokalen kopie geht es nur um deinen
Hinweis mit dem COM-Verweises den ich gesetzt habe.
Dabei wird mir immer eine lokale kopie der DLL
erstellt obwohl ich es ausgeschalten habe.

Du brauchst diesen Verweis nicht mehr, wenn
Du es so programmierst, wie ich es im ersten Posting
beschrieben habe (LateBind).

Nebenbei, die DLL sollte aus dem Target-Path
verschwinden, wenn Du die Projektmappe neu erstellst.
Dann werden aber ggf. zur Laufzeit Fehler auftreten,
wenn die CLR versucht, den Shell-Typ aufzulösen, wenn
Du EarlyBind programmierst.

Mich würde mal interessieren, warum diese
DLL für Euch so schlimm ist.


ciao Frank
--
Dipl.Inf. Frank Dzaebel [MCP/MVP C#]
http://Dzaebel.NET