Laden...

[endlich möglich] Managed Shell Extensions mit .NET 4.0?!?

Erstellt von winSharp93 vor 14 Jahren Letzter Beitrag vor 13 Jahren 7.502 Views
winSharp93 Themenstarter:in
5.742 Beiträge seit 2007
vor 14 Jahren
[endlich möglich] Managed Shell Extensions mit .NET 4.0?!?

Hallo zusammen,

in .NET 4.0 soll ja ein Feature mit dem Namen "In Process Side-by-Side CLR Hosting" eingeführt werden.

Heißt das, ich kann dann Shell Extensions in C# schreiben, ohne Gefahr zu laufen, mein System abzuschießen?

Oder ist das für etwas anderes gut?

Weiß jemand schon etwas Genaueres darüber?
Aus den bisherigen Artikeln, die ich dazu gefunden habe, geht das irgendwie nicht klar hervor...

Vielen Dank im Voraus für eure Antworten
winSharp93

//EDIT:
Titel abgeändert

6.862 Beiträge seit 2003
vor 14 Jahren

Soweit ich weiß bedeutet das einfach nur dass in einem Prozess sowohl die 2.0 als auch die 4.0 Runtime gleichzeitig laufen können.

Baka wa shinanakya naoranai.

Mein XING Profil.

winSharp93 Themenstarter:in
5.742 Beiträge seit 2007
vor 14 Jahren

Soweit ich weiß bedeutet das einfach nur dass in einem Prozess sowohl die 2.0 als auch die 4.0 Runtime gleichzeitig laufen können.

Aber das war doch soweit ich weiß immer das Problem (dass das nicht möglich war), oder?

B
342 Beiträge seit 2006
vor 14 Jahren

Hallo ihr beiden,
ich glaube, winsharp93 hat Recht. Seht euch hierzu mal das hier an:
Junfeng Zhang's Windows Programming Notes : Don't do Shell Extension Handlers in .NET
Grüße,
Big Al

Da man Spatzen nicht mit Kanonen jagt, sollte man auch nicht mit Computern auf Spatzenhirne losgehen.

winSharp93 Themenstarter:in
5.742 Beiträge seit 2007
vor 14 Jahren

Danke für eure Antworten!

ich glaube, winsharp93 hat Recht. Seht euch hierzu mal das hier an:

Hmm - eine wirkliche Antwort ist das aber nicht 😁

Mal sehen, vielleicht / hoffentlich erfährt man da in Zukunft noch was...

4.207 Beiträge seit 2003
vor 14 Jahren

Ich war diese Woche auf einer .NET 4.0-Schulung bei Microsoft, und habe dort genau diese Frage gestellt. Die Antwort lautet: Nein, geht nicht.

Das Problem ist, dass in einem Prozess nur eine Runtime zur gleichen Zeit geladen werden kann. Ist eine Anwendung beispielsweise in .NET 2.0 geschrieben, nutzt aber den OpenFileDialog von Windows (was auch nur ein Explorer ist), dann läuft das im gleichen Prozess der Anwendung. Wird dort nun eine Shell Extension verwendet, die zum Beispiel auf 1.1 basiert, knallt es. Umgekehrt natürlich ebenso.

Mit .NET 4.0 ändert sich dieses Problem teilweise: Ab .NET 4.0 ist es nämlich möglich, verschiedene Runtimes im gleichen Prozess laufen zu lassen. Insofern wäre es rein theoretisch möglich, da oben beschriebenes Problem nicht mehr auftreten kann.

ABER: Der Windows Explorer basiert derzeit nicht auf .NET 4.0, und obige Aussage gilt NUR für in .NET 4.0 kompilierte Anwendungen. Das heißt, sobald es eine Version vom Windows Explorer gibt, die .NET 4.0 unterstützt, kann man Shell Extensions problemlos in .NET schreiben.

Bis es aber so weit ist, geht das aus oben genannten Gründen noch nicht.

Wissensvermittler und Technologieberater
für .NET, Codequalität und agile Methoden

www.goloroden.de
www.des-eisbaeren-blog.de

winSharp93 Themenstarter:in
5.742 Beiträge seit 2007
vor 14 Jahren

Der Windows Explorer basiert derzeit nicht auf .NET 4.0, und obige Aussage gilt NUR für in .NET 4.0 kompilierte Anwendungen. Das heißt, sobald es eine Version vom Windows Explorer gibt, die .NET 4.0 unterstützt, kann man Shell Extensions problemlos in .NET schreiben.

Aha. Schade! 🙁

Wenn man also Kompatibilität zu Windows XP, Vista und 7 (die dann ja vermutlich alle - evtl. bis auf Windows 7 - auch in Zukunft keinen entsprechend kompilierten Explorer enthalten werden) wahren möchte, bleibt das also weiterhin ein Traum.
Mit dem Erscheinen von Windows 8 wird das dann wohl tatsächlich beginnen, ein Thema zu werden.

Danke für's Nachfragen!

4.207 Beiträge seit 2003
vor 14 Jahren

Da Windows 7 nicht mit .NET 4.0 ausgeliefert werden wird, wird es einen entsprechenden Explorer frühestens im SP1 oder eher in Win8 geben.

Wissensvermittler und Technologieberater
für .NET, Codequalität und agile Methoden

www.goloroden.de
www.des-eisbaeren-blog.de

49.485 Beiträge seit 2005
vor 13 Jahren

Hallo zusammen,

siehe auch KShellExtensions: Managed Shell Extensions

herbivore

U
208 Beiträge seit 2008
vor 13 Jahren

Hallo zusammen,

jetzt bin ich aber doch ein bisschen "verwirrt". Hier im Thread heißt es, Managed Shell Extensions wären immer noch nichts für die Praxis, da die Explorer-Version nicht auf .NET 4.0 basiert und jetzt kommt Khalid daher und behauptet einfach mal das Gegenteil, nämlich dass ShellExtension in C# seit .NET 4.0 sehr wohl möglich seien, weist aber nirgends auf irgendwelche Gefahren hin. Was ist denn jetzt genau Sache? Irgendwie blick ich da nicht so ganz durch. 😃

Danke und Gruß,

Isaac

799 Beiträge seit 2007
vor 13 Jahren

Hallo Isaac,

Khalid verlinkt in seinem Projekt auf einen MSDN-Magazinartikel der deine Frage erklären sollte. Er zitiert sogar den Absatz der klar stellt, dass sie es nun offiziell unterstützen. Schau dir den Link einfach an, dort wirst du folgenden Absatz finden:

With the ability to have multiple runtimes in process with any other runtime, we can now offer general support for writing managed shell extensions—even those that run in-process with arbitrary applications on the machine. We still do not support writing shell extensions using any version earlier than .NET Framework 4 because those versions of the runtime do not load in-process with one another and will cause failures in many cases.

Edit:/ Kein Blog, sondern Magazinartikel

As a man thinketh in his heart, so he is.

  • Jun Fan
    Es gibt nichts Gutes, außer man tut es.
  • Erich Kästner
    Krawutzi-Kaputzi
  • Kasperl
U
208 Beiträge seit 2008
vor 13 Jahren

Hallo der-schlingel,

ah, cool! Habe zwar den zitierten Text in Khalids Beitrag gelesen, aber so richtig gecheckt hab ich's wohl doch nicht. Naja, war kurz vor Feierabend, da ist man mit den Gedanken meist schon wo anders... 😁

Das heißt dann auch, dass diese Aussage von Golo, bzw. des Microsoft-Mitarbeiters, den er gefragt hat, getrost ignoriert werden kann:

Ich war diese Woche auf einer .NET 4.0-Schulung bei Microsoft, und habe dort genau diese Frage gestellt. Die Antwort lautet: Nein, geht nicht.

Weil, wurde ja von jemand höherem überstimmt, offensichtlich. 🙂

Gut gut, dann probier ich die Sache mal aus, danke noch mal für die Info!

Grüße,

Isaac

3.511 Beiträge seit 2005
vor 13 Jahren

Hallo Isaac,

es passiert mir recht selten, das ich mal eben etwas behaupte 😃 Meist lassen sich alle meine Behauptungen irgendwie bergünden. Und der verlinkte MSDN Artikel ist ein ziemlich guter Grund.

Glauben konnte ich es bis vor einigen Tagen auch noch nicht. Aber es ist ab .NET 4.0 "general supported". Und d.h. bei MS nunmal, das es erlaubt ist etwas zu benutzen, ohne Supportansprüche bei MS zu verlieren. Man muss sich nur an die Bedingungen halten, und die sind klar gesteckt: Nur .NET 4.0 und höher! Nichts dadrunter! Oder anders gesagt: Nur CLR 4.0.
Es ist z.B. nicht erlaubt eine CLR 4.0 Extension zu schreiben, und zusätzlich eine CLR 2.0 Extension, da der Side-By-Side Process dies ermöglichen könnte. Sowas ist nicht supported.

Da ich in einem MS Certified Unternehmen arbeiet, stehe ich in guten Kontakt zu MS und ich werde mir in den nächsten Tagen dazu noch die 100%ige Bestätigung einholen. Wobei der Artikel eigentlich Bestätigung genug ist.

Das heißt dann auch, dass diese Aussage von Golo, bzw. des Microsoft-Mitarbeiters, den er gefragt hat, getrost ignoriert werden kann:

Das verwirrt mich ebenfalls etwas. Deswegen will ich mir zusätzlich nochmals die Bestätigung einholen.

"Jedes Ding hat drei Seiten, eine positive, eine negative und eine komische." (Karl Valentin)

winSharp93 Themenstarter:in
5.742 Beiträge seit 2007
vor 13 Jahren

Hmm - also jetzt doch? 🤔

Ich habe mal - ganz optimistisch - den Titel umgeändert 😁

M
120 Beiträge seit 2009
vor 13 Jahren

Also mir kommt das auch noch etwas komisch vor. Man darf keine 2.0 Extension schreiben; aber 4.0 Extensions sind erlaubt, weil 4.0 das ja unterstützt und 2.0 eben nicht.
Aber solch eine "Erlaubnis" von Microsoft impliziert dann ja auch, dass eine 2.0 Anwendung kein Problem damit hat, wenn z.B. durch den "Datei öffnen"-Dialog eine 4.0 (Shell) Extension benutzt wird!?

3.971 Beiträge seit 2006
vor 13 Jahren

Hallo Golo,

Mit .NET 4.0 ändert sich dieses Problem teilweise: Ab .NET 4.0 ist es nämlich möglich, verschiedene Runtimes im gleichen Prozess laufen zu lassen.

Ist das dann möglich pro AppDomain seperat anzugeben oder muss ich jeweils mittels Managed C++ eine eigene CLR hosten?

Es gibt 3 Arten von Menschen, die die bis 3 zählen können und die, die es nicht können...

3.511 Beiträge seit 2005
vor 13 Jahren

Hallo Marsti,

das sind auch zwei verschiedene Sachen. Das nutzen von der Shell unter .NET geht seit .NET 1.0. Denn da nutzt man nur die Shell, bzw. man greift auf dessen Methoden zu (Win32 API). Und das passiert im .NET Framework an sich überall (Forms, IO, usw...).

Das laden eines eigenen Prozesses innerhalb der Shell war bis dato nicht erlaubt. Denn dann wird einmalig beim Starten des Explorers das .NET Framework hochgefahren, weil z.B. eine COM Komponente dieses benötigt. Das fatale daran war bis jetzt, das die Shell ja nicht weis in welcher Reihenfolge das .NET Framework gestartet werden soll.

Wenn also z.B. eine Extension .NET 1.1 braucht und dieses in den kompletten Explorer Prozess hochfährt und danach ein .NET 2.0 auftaucht, macht es Bumm. Und zwar gewaltig 😃. Da hilft auch der abgesicherte Modus nicht weiter...

"Jedes Ding hat drei Seiten, eine positive, eine negative und eine komische." (Karl Valentin)

502 Beiträge seit 2004
vor 13 Jahren

Hallo zusammen,

auch wenn der Thread schon etwas älter ist - hat mittlerweile irgendjemand eine "qualifizierte" Aussage seitens MS über das Thema? Ich hab sowohl hier als auch auf diversen Microsoft- und Nicht-Microsoft-Seiten und -Blogs immer wieder dieselben Argumente gelesen... Aber niemand der mal klar sagt "Ja das geht problemlos (unter folgenden Bedingungen...)" oder "Nö, besser nicht".

Irgendwie scheint sich MS um die Antwort herumzudrücken. Alles was ich bisher aus technischer Sicht gesehen hab, spricht dafür dass es erlaubt und unterstützt ist. Sogar das Microsoft'sche Windows API Code Pack hat mittlerweile ein entsprechendes Beispiel mit drin. Andererseits hab ich auch X-mal gelesen, dass das auch mit .net 4.0 nicht Supported ist und man es deshalb nicht tun "sollte".

Bart Simpson

Praxis ist wenn alles funktioniert und keiner weiss warum.
Theorie ist wenn man alles weiss, aber nichts funktioniert.

Bei uns wird Theorie und Praxis vereint: Nichts funktioniert und keiner weiss warum...

3.511 Beiträge seit 2005
vor 13 Jahren

With the ability to have multiple runtimes in process with any other runtime, we can now offer general support for writing managed shell extensions—even those that run in-process with arbitrary applications on the machine. We still do not support writing shell extensions using any version earlier than .NET Framework 4 because those versions of the runtime do not load in-process with one another and will cause failures in many cases.

Ist doch eine sehr klare Aussage, oder?

"Jedes Ding hat drei Seiten, eine positive, eine negative und eine komische." (Karl Valentin)

3.728 Beiträge seit 2005
vor 13 Jahren
Windows Explorer in .NET?

ABER: Der Windows Explorer basiert derzeit nicht auf .NET 4.0, und obige Aussage gilt NUR für in .NET 4.0 kompilierte Anwendungen. Das heißt, sobald es eine Version vom Windows Explorer gibt, die .NET 4.0 unterstützt, kann man Shell Extensions problemlos in .NET schreiben.

Ähm, ist der Windows Explorer nicht in C++ geschrieben?
Soweit ich weiß ist der Windows Explorer keine verwaltete Anwendung.
Das heißt, er unterstützt keine .NET Version mehr als eine andere.

Oder habe ich da was verpasst?

6.862 Beiträge seit 2003
vor 13 Jahren

Nein hast nichts verpasst. Die Aussage war damals schon net korrekt. Es geht ja darum das der Process die Runtime laden muss um managed Shell Extensions ausführen zu können. Das geht auch problemlos, Problem ist eher das bis 4.0 dann keine andere Version mehr geladen werden konnte, was einfach heißt - leb mit der Runtime die geladen wurde, alles was irgend eine andere Version benötigt ist zum scheitern verurteilt.

Mit 4.0 änderte sich das dann, die 4er Runtime erlaubt auch das laden weiterer Versionen. Aber, damit sind nicht die bisherigen gemeint, sondern zukünftige. Bei den bisherigen Runtimes bleibt alles beim alten.

Baka wa shinanakya naoranai.

Mein XING Profil.

795 Beiträge seit 2006
vor 13 Jahren

Mit 4.0 änderte sich das dann, die 4er Runtime erlaubt auch das laden weiterer Versionen. Aber, damit sind nicht die bisherigen gemeint, sondern zukünftige. Bei den bisherigen Runtimes bleibt alles beim alten.

Endlich mal jemand, der es vernünftig in Worte fasst.

`There are 10 types of people in the world: Those, who think they understand the binary system Those who don't even have heard about it And those who understand "Every base is base 10"`
winSharp93 Themenstarter:in
5.742 Beiträge seit 2007
vor 13 Jahren

Sogar das Microsoft'sche
>
hat mittlerweile ein entsprechendes Beispiel mit drin.

...und es gibt inzwischen auch eine Tutorial-Reihe:
Writing Windows Shell Extension with .NET Framework 4 (C#, VB.NET) - Part 1
Writing Windows Shell Extension with .NET Framework 4 (C#, VB.NET) - Part 2