Umfrage zu neuem Buch zur Visual Studio Add-in Programmierung

Hallo,

seit einiger Zeit, arbeite ich nun an einem Buch zur Add-in Programmierung für Visual Studio. Letzt Woche hatte ich wieder die Gelegenheit auf der BASTA eine Session zum Thema Add-in Programmierung zu halten. Dabei ist mir aufgefallen, dass man nicht wirklich auf alle Bereiche und Anforderungen an ein Add-in alleine denken kann. Darum würde ich hier gerne jedem die Möglichkeit geben, zum Inhalt meines Buches etwas beizutragen. Also hier die Fragen an Euch, die Ihr hoffentlich fleißig beantwortet:
1.Was erwartet ihr euch von einem deutschen Buch, zur Add-in Programmierung für Visual Studio 2005? 1.Würdet ihr es begrüßen, dass trotz deutscher Sprache, die Fachbegriffe (wie Command, Tool, SolutionExplorer etc.) in Englisch geschrieben sind, oder sollten alle Begriffe ins deutsche übersetzt werden so das es ein Glossar am Ende des Buches geben wird? 1.Welche kniffeligen Situationen hattet ihr schon bei der Add-in Entwicklung, die ihr gerne mal näher beleuchtet hättet? 1.Was fandet ihr an den Büchern, die ihr vielleicht zu dem Thema schon gelesen habt gut und was weniger gut? 1.Favorisiert ihr mehr Bilder oder mehr Code-Samples in den Buchseiten? 1.Wie wichtig wäre für euch das Thema Add-in Deployment? Setup / Copy &Paste.

Vielen Dank

TOM_MUE

Hallo TOM_MUE,

da ich kein VS einsetze, hier nur die Antworten auf die übergreifenden Fragen:

zu 2. Fachbegriffe sollten englisch beleiben, wenn eben das englische Wort der übliche Begriff ist. Wenn es gleichwertige deutsche Fachbegriffe gibt, sollten diese verwendet werden. Bei Verben ist es wohl meist sinnvoller, auf deutsche Alternativen auszuweichen: "heruntergeladen" statt "downgeloaded".

zu 5. Codebeispiele, die den Kern zeigen, also nicht mehr als 10-15 Zeilen lang sind, finde ich hilfreich, seitenlangen Code eher störend. Wenn ein Bild mehr sagt als tausend Worte, dann sollte man es vorziehen, aber andererseits nicht versuchen alles in Bilder zu pressen, was man besser anders ausdrücken kann. Auch die Strukturierung des eigentlichen Texts (Zwischenüberschriften, Listen, Einrückungen, Textrahmen, ...) finde ich wichtig und hilfreich.

Eine Danksagung an die Mitglieder von myCSharp.de wäre nicht schlecht, wenn du hier wesentliche Hilfen bekommen hast. 😃

herbivore

Hallo herbivore,

vielen Dank für das Feedback. Werde Deine angesprochenen Punkte auf jeden Fall mit aufnehmen.

Warum sollte bei guter Zusammenarbeit einer Nennung von MyCSharp in dem Buch etwas im Wege stehen 😉

Grüße

TOM_MUE

Wir lesen auch gerne Quer, wenn es gewünscht ist 😉

1 <-- Wenn ich wüsste was Add-in ist.
2. <-- Herbivore
5. <-- Herbivore

Ich setze VS05 ein, habe aber noch nie Add-Ins dazu entwickelt und kenne mich mit der Thematik und potentiellen Schwierigkeiten selber nicht aus.

zu 1:

Ich würde erwarten, dass ich danach fähig bin auch komplexere Add-Ins umzusetzen, ich müsste danach also mit den Paradigmen und vorgesehenen Design Patterns der VS API vertraut sein. Ich würde nicht unbedingt eine "klassiche" VS API Referenz erwarten - wenn ja, dann im Anhang, nicht im Haupttext. Ich würde erwarten dass ich recht früh im Text ein triviales Add-In selber schreiben könnte, und dass spezielle Aspekte im Detail später seperat aufgearbeitet werden, sodass ich nach den Basics auch direkt zu einem solchen Teil springen kann (ohne alle anderen Aspekte durchgelesen haben zu müssen). Und schlussendlich würde ich einige Beispiele erwarten, u.a. auch solche die sich direkt mit dem Source-Editor befassen und solche die direkt mit dem aktuellem Sourcecode integargieren.

zu 2: Ack zu herbivore.

In Code-Beispielen bevorzuge ich persönlich alles (bis auf Kommentare und String-Literale) auch englisch, also auch alle Members und Klassennamen.

Ich setze selber ein englisches VS ein, aber falls in der deutschen Version statt "Solution Explorer" etwas anderes im Fenster steht sollte eher diese deutsche Version benutzt werden - ausser der Text bezieht sich gezielt auf eine entsprechend englisch benannte Klasse aus dem Framework / VS Add-In API.

zu 5: Ack zu herbivore.

Hatte aber auch schon die Situation erlebt dass ich die einzlnen kurzen Codeausschnitte/Beispiele selber nicht wirklich (= nur mit viel Mehraufwand) zu etwas ganzem kombinieren konnte. Hilfreich wäre da vielleicht schon auch ein grösseres komplettes Beispiel, dies aber nicht abgedruckt sondern auf der Website oder vielleicht einer beigelegten CD (ohne dass es aber notwendig wird sich das lange Beispiel auch tatsächlich anzusehen um dem Text folgen zu können).

zu 6:

Ein Add-In sollte idealerweise einfach weitergegeben werden können. Wäre sicher hilfreich wenn das Thema so behandelt wird dass ich danach mein Add-In verpacken kann auch ohne bereits viel eigene Erfahrung mit Deployment zu haben; ohne aber allgemein in das Thema Deployment einzusteigen.

hth,
Chris

Hallo TOM_MUE,

zu 1.: Eine gute Qualität
EDIT: Sieh Dir dazu vielleicht mal Java Head First an (gibt's inzwischen auch in Deutsch). Ich fand den Ansatz fantastisch und sehr effektiv.

zu 2.: da stimme ich mit Herbivore überein.

3.: ich möchte hier den Ansatz wählen, dass ich die Situationen als Fragen beschreibe, die es dann zu beantworten gäbe.
Beim Thema Enhancer stößt man vielleicht darauf, dass ein eine isolierte Add-In-Assembly nicht direkt auf Code oder Ressourcen in einer anderen Assembly zugreifen kann.
Was macht man da, um das Problem zu vermeiden oder zu umgehen?
Mit einem besonderen Sicherheitssatz können AddIns in der Sandbox ausgeführt werden, wie macht man das? Was ist die Sandbox?
Wie funktioniert die ganze Speicherverwaltung, da ja über AppDomains oder Prozessgrenzen hinaus operiert werden kann.
Wie kann man die ganze Entwicklung hier - vielleicht mit Attributen - unterstützen, um sich ein eigenes noch besseres Framework aufzubauen?
Welche Stolperfallen und Lösungen gibt es beim Debugging?
Können Add-Ins in den GAC und dann mit NGen binär übersetzt und entwickelt werden, ist das überhaupt sinnvoll?

Soweit ich weiss, hatte ich mal das Problem dass eine domänenunabhängige Assembly nicht entladen werden kann – selbst dann nicht, wenn alle Anwendungsdomänen,
die diese Assembly verwenden, entladen wurden. Was macht man dagegen?

Das trat auf, als ich versuchte einen Enhancer direkt in ein eigenes Add-in für Visual Studio zu codieren, dabei kommt es mit Reflection zu problemen.
Normalerweise lädt man ein zu durchsuchendes Assembly mit Assembly.LoadFrom. Dieses Assembly bleibt dann aber geladen, solange der Enhancer läuft. Die Folge ist, dass ich spätestens beim zweiten Build Probleme bekommen, da der Compiler das Assembly nicht überschreiben darf, so lange es geladen ist. Die Lösung ist, den Reflection-Code in eine eigene Exe oder AppDomain auszulagern.

4.: Habe noch kein Buch zu dem Thema gelesen, aber das Debugging Thema, wie es Microsoft ansprach, dass man quasi nicht direkt debuggen kann,
Hatte mich schon etwas geschockt.

5. Wie schon gesagt wurde, solange die Aussagekraft eines Bildes stark genug ist, bleibt seine Aussagekraft unumstritten,
überladene Bilder können aber ihre Aussagekraft eindeutig wieder schmälern.
Da gilt es den goldenen Weg zu finden. Was sicher nicht immer einfach ist. 🙂

6. Fände ich sehr interessant und wichtig auch in Bezug auf was muss codiert werden, damit man sich das erleichtert.
Was sollte man gleich am Anfang beachten, damit man sich nichts verbaut.

@Armitage: Das ist doch wohl ein Witz. Den Post hättest du dir wirklich sparen können.

Stimme meinen Vorrednern soweit zu, daher hier nur Add-Ons:
1. Das es wie ein englisches Buch geschrieben ist. Ich finde den Schreibstil vieler deutscher Autoren knochentrocken. Es klingt immer so, als wenn sie gerade eine Enzyklopädie schreiben würden. Das macht ein Buch, das man durchlesen und -arbeiten soll sehr mühsam.
2. Wie meine Vorredner, allerdings möchte ich deutlicher auf den Code zu sprechen kommen. Ich finde es sehr wichtig, dass der Code wie aus einem Guss wirkt. Und da die Programmiersprache unabänderbar englisch ist, sollte sich der eigene Code auch daran orientieren (sprich: alles englisch).
3. Habe zwar noch nie ein Add-In für VS programmiert, aber wie dr4g0n76 ansprach, kann es viele Probleme geben. Um schnell die Lösung zu einem konkreten Problem zu finden, ist eventuell ein eigenes Kapitel als schnelle Referenz derartiger Probleme empfehlenswert.

Hallo,

sorry das ich mich hier so spät melde. Da ich aber in meinem Job sehr viel unterwegs bin, kann nur selten hier im Forum vorbeischauen.

Vielen Dank an alle die bisher geantwortet haben! Eure Vorschläge decken sich in jeden Fall mit meinen Gedanken, bringen neue Ideen und geleichen der Mail-Flut, die ich über mein Blog zu diesem Thema bekomme.

@Armitage:

Das zeigt mir, das in jedem Fall in der Beschreibung des Buches auch die User gefesselt werden müssen, die noch nie etwas mit diesem Thema zu tun hatten 😉

@cdr:

Es wird schwierig sein ein Add-in ohne viel beschreibenden Text weiter zu geben, wenn sich als Add-in-Entwickler nicht mit Deployment beschäftigen möchte. Es zeigt mir aber auch das es die handgriffe über den Setup-Designer des VS2005 erklärt sein sollten. Wenn man die verinnerlicht hat, dann ist der Rest kein Problem und in kurzer Zeit umgesetzt. Danke auch für die anderen Punkte von Dir!

@dr4g0n76

Danke für Deine Antwort! Zu Deinem Punkt 3 muss ich aber sagen, dass es sich dabei um Grundsätze der .NET Entwicklung handelt. Oder war das nur als Gedankenansatz gedacht? Aber AppDomains, Speicherverwaltung etc. sind weniger Schwerpunkte der Add-in-Entwicklung. Das Laden und Entladen von Assemblies übernimmt das VS2005. Selbst muss ich mur bei einer eigenen Add-in-implementierung in meiner eigenen Anwendung kümmern. Aber hier kann die mit VSTA geholfen werden 😉

@Borg

Danke für Deine Antworten! In Punkt eins stimme ich Dir voll zu! Dies war auch mein erster Ansatz für die Erstellung des Buches. Hoffen wir mal dass es auch von mir so umgesetzt werden kann 😉 Dieser Wunsch kommt übrigens auch sehr viel über das Mailing aus der Umfrage aus meinem Board.

@ FZelle

Danke für Deine Antwort! Querlesen wird in jedem Fall beachtet. 😉

Noch Mal für Alle. Wenn es zeitlich funktioniert, möchte ich mit dem Inhalt des Buches sehr offen umgehen und eine Art BlogTage-Buch dazu einführen. Hier wird es dann Ausschnitte zu den Einzelnen Kapiteln geben, auf die man dann bei begründeten Einwand auch noch Einfluss haben kann.

Also dann, tausend Dank noch mal an Alle

TOM_MUE

@TOM_MUE:

Oder war das nur als Gedankenansatz gedacht?

Ja!

Original von TOM_MUE
Würdet ihr es begrüßen, dass trotz deutscher Sprache, die Fachbegriffe (wie Command, Tool, SolutionExplorer etc.) in Englisch geschrieben sind, oder sollten alle Begriffe ins deutsche übersetzt werden so das es ein Glossar am Ende des Buches geben wird?

Würde ich englisch belassen, macht es leichter im Internet nach weiteren Infos zu suchen, die ja zu 95% nur über englische Suchbegriffe zu finden sind.

Welche kniffeligen Situationen hattet ihr schon bei der Add-in Entwicklung, die ihr gerne mal näher beleuchtet hättet?

Entwickelt hab ich noch nicht, aber Probleme hatte ich zuhauf. Dabei vor allem: Lokalisierung. Offenbar klappen Menü- und Tastaturbindungen nur mit explizit lokalisierten Versionen der AddIns. So verliert der Resharper sämtliche Shortcut-Bindungen in einem deutschem VS. War für mich mit ein Grund von der deutschen VS-Version Abstand zu nehmen.

Wie wichtig wäre für euch das Thema Add-in Deployment? Setup / Copy &Paste.

Fände ich sehr wichtig. Was nützt einem ein AddIn, welches sich nicht sauber (de-)installiert?

@TOM_MUE: Wie wäre es, wenn wir die einzelnen Kapitel probedurcharbeiten können?
Dann erfährst Du unsere "Hänger" und auf welche Probleme wir sonst noch stoßen.
Vielleicht versteht der eine von uns den einen Abschnitt so und der andere genau andersherum.

Wie wäre das? Ich denke ein besseres Feedback kannst Du eigentlich nicht bekommen.

Entweder arbeitet dann jeder jedes Kapitel durch oder man könnte das aufteilen.
Was Du davon hältst, kannst Du ja gerne selber entscheiden.