Announcement

**Andreas Kosch** · 24.03.2006, 07:38

Hallo,
in derartigen Situationen kapsele ich die Automation-Zugriffe auf Excel/Word in eine mit VB geschriebene Assembly. Denn in VB kann �ber Option Strict Off die Sache ungemein erleichtert werden :-) 
Das folgende Beispiel ruft Excel �ber die ProgID auf, so dass die auf dem Rechner installierte Excel-Version keine Rolle spielt:
<pre style="font-size:10pt;font-family:Courier New;font-weight:normal;font-style:normal;color:#282828;background-color:white;">
Dim XlApp As Object
Dim XlBook As Object
Dim XlWorkBooks As Object
Dim XlSheet As Object

Try
' Versuch 1: Auf laufende Instanz aus der ROT aufschalten
XlApp = GetObject(, "Excel.Application")
Catch err As System.Exception
Try
' Versuch 2: Neue Instanz anfordern
XlApp = CreateObject("Excel.Application")
Catch ex As Exception
MessageBox.Show("Automation-Instanz von Excel kann nicht angefordert werden,", _
"Fehler", MessageBoxButtons.OK, MessageBoxIcon.Error)
End Try

End Try
XlApp.ScreenUpdating = False
XlWorkBooks = XlApp.Workbooks
XlBook = XlWorkBooks.Add
XlSheet = XlBook.worksheets(1)
XlSheet.activate()
' Spalten�berschrift
Dim Col As Integer
For Col = 1 To 3
XlSheet.cells(1, Col).font.bold = True
XlSheet.cells(1, Col) = String.Format("Spalte {0}", Col)
Next Col
XlApp.screenupdating = True
' Benutzer soll mit Excel-GUI arbeiten
XlApp.usercontrol = True
Dim ApplicationObject As Object
ApplicationObject = XlSheet.application
' Excel anzeigen
ApplicationObject.visible = True

MessageBox.Show("Excel ist sichtbar")

' Automation-Instanz von Excel schlie�en
XlBook.Close(SaveChanges:=False)
XlApp.Quit()
' Verweise auf die Interface-Zeiger freigegeben
Marshal.ReleaseComObject(ApplicationObject)
Marshal.ReleaseComObject(XlSheet)
Marshal.ReleaseComObject(XlBook)
Marshal.ReleaseComObject(XlWorkBooks)
Marshal.ReleaseComObject(XlApp)
End Sub
</pre&gt

**bigpoint** · 24.03.2006, 11:28

Hallo und vielen dank f�r die Antwort,

es ist also nicht so dass die Assembly aufw�rts kompatibel sind??
Wenn ich jetzt richtig Ihren Ansatz verstanden habe, rufen Sie dann die im VB geschriebene
Assembly im C# Programm auf um zu auf Excel zugreifen, wenn ja wie sieht dann denn Aufruf von C# aus, ist das was Sie im Beispiel anzeigen eben die VB Assembly??

Vielen Dan

**Andreas Kosch** · 27.03.2006, 06:17

Hallo,
eine PIA (Primary Interop Assembly) ist immer exakt an die Version des COM-Objekts gekoppelt, f�r die sie angelegt wurde. F�r eine C#-Anwendung, die universell auf verschiedene Excel-Varianten zugreifen muss, gibt es prinzipiell 3 Alternativen:
 
1. Mehrere Hilfsassemblies f�r jede PIA: Das C#-Programm pr�ft vor dem ersten Zugriff, welche Excel-Version installiert ist. Je nach der vorgefundenen Version wird die "richtige" Assembly geladen. F�r jede PIA wird eine separate Aufruf-Assembly bereitsgestellt, wobei alle das gleiche Interface implementieren. Die C#-Anwendung greift nur �ber das eigene Interface auf die Hilfs-Assemblies zu, so dass nur die Instanzierung abh�ngig von der Excel-Version ist (aber nicht die sp�teren Aufrufe).
 
2. Die C#-Anwendung lagert die Aufrufe �ber die sp�te Bindung in eine VB-Assembly aus, wobei bei der sp�ten Bindung die installierte Excel-Version keine Rolle spielt. Die VB-Assembly stellt �ffentliche Methoden zur Verf�gung, �ber die das C#-Programm dessen Dienste nutzen kann. Wenn die C#-Anwendung die VB-Assembly als Verweis einbindet, unterscheidet sich der Zugriff nicht von den anderen .NET-Assemblies. F�r den Zugriff auf Microsoft Word k�nnte dies so aussehen:
<code>
Imports System.Runtime.InteropServices

Public Class WordLateBound

Private Const cPROGID As String = "Word.Application"
Private Const cNEWCAPTION As String = "Achtung: Word wird fernbedient !"
Private aWordApp As Object
Private aWordDoc As Object
Private sOldCaption As String
Private sCurrentDocName As String = String.Empty
 
Public Sub DoWordStart(ByVal bVisible As Boolean)
' Automation-Instanz �ber die sp�te Bindung erzeugen
aWordApp = CreateObject(cPROGID)
aWordApp.Visible = bVisible
End Sub
 
Public Function DoNewDoc(ByVal sDOT As String) As Integer
If Not aWordApp Is Nothing Then
aWordApp.Documents.Add(sDOT)
aWordDoc = aWordApp.ActiveDocument
sCurrentDocName = aWordDoc.Name
Return 1
Else
Return 0
End If
End Function
 
Public Function DoInsertAtBookmark(ByVal sBookmark As String, ByVal sTxt As String) As Integer
If Not aWordDoc Is Nothing Then
If aWordDoc.Name = sCurrentDocName Then
aWordDoc.Bookmarks(sBookmark).Range.Text = sTxt
Else
' Fehler: Es ist nicht mehr das gleiche Dokument aktiv
Return 2
End If
Return 1
Else
' Fehler: Der Verweis auf das Document-Objekt von Word ist ung�ltig
Return 0
End If
End Function
 
Public Function DoPrintCurrentDoc() As Integer
If Not aWordDoc Is Nothing Then
aWordDoc.PrintOut(Background:=False)
Return 1
Else
Return 0
End If
End Function
 
Public Function DoSaveCloseDoc(ByVal sDOC As String) As Integer
If Not aWordApp Is Nothing Then
aWordDoc.SaveAs(sDOC)
aWordDoc.Close()
sCurrentDocName = String.Empty
Marshal.ReleaseComObject(aWordDoc)
aWordDoc = Nothing
Return 1
Else
Return 0
End If
End Function
 
Public Sub DoWordStop()
If Not aWordApp Is Nothing Then
aWordApp.Quit()
Marshal.ReleaseComObject(aWordApp)
aWordApp = Nothing
End If
End Sub
End Class
</code>
 
3. Die C#-Anwendung implementiert die Aufrufe der sp�ten Bindung selbst (ohne die Mithilfe von VB), allerdings ist dies bei C# generell komplizierter, da man mit InvokeMember (Reflection) hantieren muss. Gerade bei Microsoft Excel oder Word stellt dieser Weg f�r die dort oftmals verwendeten optionalen oder benannten Parametern eine Herausforderung dar - w�hrend VB dank der sp�ten Bindung einfach die "nicht ben�tigten" Parameter beim Aufruf einer Excel-Methode weglassen darf

**Bernhard Geyer** · 27.03.2006, 07:24

> eine PIA (Primary Interop Assembly) ist immer exakt an die Version des COM-Objekts gekoppelt, f�r die sie angelegt wurde. F�r eine C#-Anwendung, die universell auf verschiedene Excel-Varianten zugreifen muss, gibt es prinzipiell 3 Alternativen:

Da bleibt mir nur der Spruch: Alles wird einfacher.

Welchen Grund hat es das es diese strikte Versionabh�nigkeit gibt?
Keine der 3 L�sungsm�glichkeiten ist f�r mich eine wirkliche alternative zu der unter Win32 gewohnten Aufw�rtskompatiblit�t auch mit der fr�hen Bindung

**Andreas Kosch** · 28.03.2006, 06:59

Hallo Bernhard,
fr�her hat bei Win32 die Versionsnummer eine DLL keine Rolle gespielt, aber unter .NET pr�ft die CLR penibel die im Manifest der Anwendung vermerkten Versionsnummern (typsicherer Zugriff). Die Medizin gegen die "DLL-H�lle" schmeckt zwangsl�ufig etwas bitter und hat stellenweise auch unverw�nschte Nebenwirkungen.
 
P.S: Auch fr�her gab es unerw�nschte Nebenwirkungen, und sei es nur deshalb, weil Microsoft in einer Word-Version die eigenen (strengen) Regeln zur Unver�nderlichkeit eines einfach ver�ffentlichten Interfaces nicht eingehalten hat. Diese Gefahrenstelle ist mit einer PIA jetzt geflickt :-

**Bernhard Geyer** · 28.03.2006, 07:28

> fr�her hat bei Win32 die Versionsnummer eine DLL keine Rolle gespielt, aber unter .NET pr�ft die CLR penibel die im Manifest der Anwendung vermerkten Versionsnummern (typsicherer Zugriff). Die Medizin gegen die "DLL-H�lle" schmeckt zwangsl�ufig etwas bitter und hat stellenweise auch unverw�nschte Nebenwirkungen.

Super. Damit darf ich jetzt jede Office-Version anpassen. Ich hoffe dieser �berpr�fung geht nicht soweit das auch jedes ServicePack oder Hotfix mit einer Versionsnnummer vergeben ist.

> Auch fr�her gab es unerw�nschte Nebenwirkungen, und sei es nur deshalb, weil Microsoft in einer Word-Version die eigenen (strengen) Regeln zur Unver�nderlichkeit eines einfach ver�ffentlichten Interfaces nicht eingehalten hat. Diese Gefahrenstelle ist mit einer PIA jetzt geflickt :-)

Das ist schon klar. Ein nicht unerheblicher Teil der normalen Arbeitszeit ist ja schon die Fehler in Anwendungen wie Office/IE oder Acrobat Reader zu umschiffen. Und jetzt unter .NET auch noch diese Baustelle zu haben macht die Sache nicht einfacher/besser.

Den VB-Umweg sehe ich auch nicht als L�sung. Sch�n und gut das man unter .NET zwar viele Programmiersprachen mischen kann, aber ich bin der Meinung das man dies m�glichst vermeiden sollte

**Andreas Kosch** · 30.03.2006, 06:03

Hallo Bernhard,
>..aber ich bin der Meinung das man dies m�glichst vermeiden sollte.
Du bist also ein Verfechter des Grundsatzes "Eine Gr��e muss allen passen" :-)
 
Das Problem bei der Automation von den Office-Anwendung ist, dass diese vom Aufbau her zu sehr an die Scriptsprachen bzw. VB angelegt sind. Aus historischen Gr�nden (siehe Word Basic) verwenden die Automation-Objekte nur als Verweis �bergebene Parameter (passed by reference) , so dass C# alle Parameter als ref �bergeben muss. Au�erdem nutzt Office sehr h�ufig optionale Parameter (die ebenfalls als Verweis interpretiert werden), was mit C# bei vern�nftigen Aufwand schon gar nicht geht. Die Liste aller Problemstellen f�r C# sieht dann so aus: 
a) �bergabe von ref-Parametern an eine Interface-Methode 
b) Verwendung von optionalen Parametern einer Interface-Methode 
c) Verwendung der sp�ten Bindung bei COM-Objekten, die nur die sp�te Bindung unterst�tzen (Beispiel: Dialogs-Objekt aus dem Word-Objektmodell) 
c) Sonderfall Excel: Parametrisierte Eigenschaften 
d) Sonderfall Word: Versteckte Zugriffsmethoden
 
Aus meiner Sicht ist es reine Selbst-Gei�elung, wenn ein Entwickler f�r den Automation-Aufruf von Office-Anwendungen zu C# greift.

**Bernhard Geyer** · 30.03.2006, 07:30

> Du bist also ein Verfechter des Grundsatzes "Eine Gr��e muss allen passen" :-)
Eher: Nicht alles verwenden was m�glich ist. Denn dann kennt sich irgendwann keiner mehr aus bzw. mu� dann die Syntax von 10 Sprachen kennen.

Wieso wurde eigentlich C# keinen �hnliche M�glichkeiten wie VB oder wie es Delphi auch kann spendiert um sowohl fr�he als auch sp�te Bindung zu unterst�tzen?

Hat aber nicht MS f�r .NET nicht spezielle Wrapper-Klassen bereitgestellt, evtl. �hnlich den Office-Wrappern in Delphi? Oder verwechsel ich da was

**Andreas Kosch** · 31.03.2006, 06:27

Hallo Bernhard,
weil Microsoft die Sprachen C# und VB nicht als Konkurrenten betrachtet, sondern als Erg�nzung. Nicht ohne Grund unterst�tzt Visual Studio sowohl C# als auch VB (neben C++ und J#).
 
>Hat aber nicht MS f�r .NET nicht spezielle Wrapper-Klassen bereitgestellt
Ja - das folgende Beispiel ist eine von Microsoft bereitgestellte derartige Hilfsklasse f�r C# f�r den Aufruf �ber die sp�te Bindung:
<pre>
<div style="font-family: Courier New; font-size: 10pt; color: black; background: white; border-top: windowtext 1pt solid; padding-top: 0pt; border-left: windowtext 1pt solid; padding-left: 0pt; border-right: windowtext 1pt solid; padding-right: 0pt; border-bottom: windowtext 1pt solid; padding-bottom: 0pt;">public class LateBoundComHelper : IDisposable{    private Type _type;    private object _obj;     public LateBoundComHelper(string progId)        :        this(Type.GetTypeFromProgID(progId, true))    {    }     public LateBoundComHelper(Type t)    {        if (t == null) throw new ArgumentNullException("t");        _type = t;        _obj = Activator.CreateInstance(t);    }     public object Invoke(string methodName, params object[] args)    {        ThrowIfDisposed();        return _type.InvokeMember(methodName,            BindingFlags.InvokeMethod, null, _obj, args);    }     public object this[string propertyName]    {        get        {            ThrowIfDisposed();            return _type.InvokeMember(propertyName,                BindingFlags.GetProperty, null, _obj, null);        }        set        {            ThrowIfDisposed();            _type.InvokeMember(propertyName, BindingFlags.SetProperty,                               null, _obj, new object[] { value });        }    }     private void ThrowIfDisposed()    {        if (_obj == null) throw new ObjectDisposedException(GetType().Name)    }     public void Dispose()    {        if (_obj != null)        {            if (_type.IsCOMObject)            {                while (Marshal.ReleaseComObject(_obj) > 0) ;            }            else if (_obj is IDisposable) ((IDisposable)_obj).Dispose();            _obj = null;        }    }}</div>
</pre>
Es bleibt aber immer noch der Aufwand beim Aufruf der Hilfsklasse.
 
Die anderen Hilfsklassen sind die PIAs (Primary Interop Assemblies), die gem�� des Knigge nur der Herausgeber des COM-Objekts auf einem Benutzer-Rechner installieren darf (daher auch die Abh�ngigkeit von der Versionsnummern, denn das Anwendungs-Manifest listet nur die Versionsnummer der PIA auf, aber nicht die der Office-Anwendung). Wenn man sich nicht an die Regeln h�lt und die PIAs der "falschen" (�ltesten) Office-Version auf dem Anwender-Rechner registriert, kann man auch mehrere Office-Anwendunge gleichzeitig bedienen, solange die neuen Office-Versionen die Methoden-Signaturen im Interface nicht �ndern (was ja gem�� des COM-Knigge nicht zul�ssig w�re). In diesem Fall darf der Anwender aber nicht die Reparatur-Funktion der neueren Office-MSI aufrufen, denn diese w�rde ja die PIA "reparieren" :-) 
Ich gehe daher immer den sicheren Weg - auch wenn dieser etwas beschwerlicher ist, weil f�r jede Office-Version eine separate Ansteuerung notwendig wird. Au�erdem installiere ich niemals eine fremde PIA selbst, sondern verlasse mich immer auf das originale Setup. Das hat auch den Vorteil, dass dann der Herausgaber (im Fall der Office-Anwendungen als Microsoft) daf�r verantwortlich ist, bei einer ge�nderten PIA �ber eine im GAC installierte Policy-Assembly auch die Versionsnummern umzubiegen (bindingRedirect), so dass die "alten" Anwendungen trotz der gepatchten PIA immer noch laufen.
&#10

**Bernhard Geyer** · 31.03.2006, 07:22

> weil Microsoft die Sprachen C# und VB nicht als Konkurrenten betrachtet, sondern als Erg�nzung. Nicht ohne Grund unterst�tzt Visual Studio sowohl C# als auch VB (neben C++ und J#).

Einer Sprache m.E. solche Einschr�nkung aufzuerlegen "nur" um die Existenzberechtigung einer anderen Sprache zu erhalten und damit sagen zu k�nnen "Seht Ihr k�nnt w�hlen was ihr wollt" hallte ich f�r Bl�dsinn. Ich kann in Delphi beide wege (fr�he/sp�te Bindung) w�hlen. Wieso soll jetzt das "viel bessere System" (.NET) mich zwingen um den gleichen Komfort zu haben jetzt neben (der m.E. prim�ren Sprache C#) auch noch eine 2te Sprache zu k�nnen?

Die "L�sung" �ber die untergeschobenen PIA's ist aufgrund der schon geschilderten Probleme auch keine.

Also bleibt, um nicht alle paar Monate ein Update der Software zu liefern, nur die Verwendung von VB.NET als Wrapper wenn man mit COM-Komponenten per Interop arbeiten muss

**Andreas Kosch** · 03.04.2006, 06:06

Hallo Bernhard,
man stelle sich nur den Aufschrei in der C-Community vor, wenn eine C-Sprache einen Teil von VB �bernimmt :-) 
Microsoft bedient mit C# und VB prim�r die eigene Sprach-Klientel, alle "Exoten" (so auch die Delphianer) m�ssen sich hier als Minderheit unterordnen

**Bernhard Geyer** · 03.04.2006, 22:10

> man stelle sich nur den Aufschrei in der C-Community vor, wenn eine C-Sprache einen Teil von VB �bernimmt :-)
Man mu� es nur gut verkaufen k�nnen. So wie ich C# eher als Java-Basierende Sprache als eine C-Basierende Sprache ansehe.
Wieviel "Eigenheiten" wurden von Java �bernommen und wieviel von C au�er der "M�chtigkeit"

**Andreas Kosch** · 04.04.2006, 05:52

Hallo Bernhard,
es gibt auch noch eine andere Theorie, wie Java entstanden ist. Das folgende Zitat (das vollst�ndige Original ist �ber die URL http://dotnetmasters.com/HistoryOfCFamily.htm abrufbar) ist ein Auszug daraus :-)


1990 � By this time, all C compilers have turned into C++ compilers. But, since most C++ programs do not use any of the object oriented features of the language, this means in practical terms that bloated code structures with pointers into the operating system are now being compiled with an object-oriented compiler.
 
1990 � After hiring some industry analysts that switched from crack to sniffing glue, Sun decides to create a language called Oak to program set-top television boxes. Since all their programmers have had stilted C syntax imprinted into their DNA by this time, the new language borrows heavily from C and C++ syntax. However the set-top boxes don�t have an operating system for bad pointers to get to, so pointers are eliminated from the language.
 
1994 � Someone at Sun finally realizes what a stupid idea it was to develop a special language just for set-top television boxes. The language is renamed Java and repositioned as an �Internet� language that is supposed to be portable to many platforms. This works well as a marketing campaign, since less than 3% of people in the industry at this time realize what the Internet is, and since hallucinating industry analysts continue to be suckers for the mythical idea of "portability to different platforms".
 
1995 - Sun offers free psychedelic mushrooms to industry analysts, who immediately start writing articles about how Java is the future of programming because of its portability and integration with the Internet.
 
Mid 1996 � 17,468,972 articles appear about how Java is the future of programming. The age of Java applets in web pages begins.
 
Late 1996 � Programmers trying to produce actual web pages with applets that really work commit mass suicide out of frustration and depression. Industry analysts increase their dosage of hallucinogens to compensate.
 
1997 � Taking the advice of hallucinating industry analysts, Corel decides to rewrite all their applications, including WordPerfect, in Java. The end result is the first known word processor that is slower to use than a typewriter.
</i&gt

Announcement

Microsoft.Office.Interop.Excel

Microsoft.Office.Interop.Excel

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment