Imports Microsoft.Office.Interop - wenn kein Word installiert ist

  • VB.NET
  • .NET (FX) 4.5–4.8

Es gibt 6 Antworten in diesem Thema. Der letzte Beitrag () ist von petaod.

    Imports Microsoft.Office.Interop - wenn kein Word installiert ist

    Hallo Leute,

    ich würde Imports Microsoft.Office.Interop in meinem Projekt benötigen.

    Da es mittlerweile ettliche Office-Versionen gibt und jeder User eine andere Version installiert hat (manche gar keine), wie ist hier am Besten vorzugehen?

    Wenn ich die Microsoft.Office.Interop als Verweis in mein Projekt einfüge und dann aber die Software auf einem Rechner läuft wo Word nicht drauf ist,
    dann bekomme ich ja eine Fehlermeldung?

    Welchen Verweis füge ich ein? Ich habe auf meinem Entwicklungsrechner zwar Office mit Word installiert, ich finde aber keinen Verweis zur Microsoft.Office.Interop.

    Ich würde es gerne so handhaben:
    Wenn der User Word installiert hat, dann kann er die Word-Spezifischen Teile meiner Software verwenden.
    Wenn der User kein Word installiert hat, dann sind diese Funktionen gesperrt.

    Wie würdet Ihr das machen?

    PS: ich würde das Imports Microsoft.Office.Interop in einem Modul verwenden.
    Bilder

    • 22122021104055.jpg

      101,57 kB, 786×543, 103 mal angesehen
    Liebe Grüße
    Roland Berghöfer

    Meine aktuellen und kostenlos verwendbaren Tools (mit VB.NET erstellt): freeremarkabletools.com | priconman.com | SimpleCalendar | AudibleTouch | BOComponent.com | bonit.at

    Wenn man Interop.Word benötigt muss auf dem Zielsystem Word installiert sein, sonst läuft dein Programm nicht bzw. auf Fehler.
    Ich kann jetzt gar nicht ausprobieren, wann es auf einen Fehler läuft, da ich Rechner ohne Office in meinem Umfeld gar nicht habe.

    Um von der Word-Version nicht abhängig zu sein empfiehlt es sich nicht das installierte Interop zu benutzen sondern das NuGet Packet "Microsoft.Office.Interop.Word" ins Projekt einzubinden.
    Dann wird dir auch automatisch der Verweis eingepflegt und du musst die Komponente nicht suchen. Bei meiner D365-Word-Version wüßte ich nicht mal wo ich suchen sollte, würde ich ggf. Tante Google nach fragen.
    Brauch ich aber nicht, ich benutze das NuGet-Packet.

    Mein Word befindet sich zum Beispiel im Pfad: C:\Program Files\WindowsApps\Microsoft.Office.Desktop.Word_16051.14701.20262.0_x86__8wekyb3d8bbwe\Office16
    Wobei auf C:\Program Files\WindowsApps selbst wird der Zugriff für User ohne Adminrechte verhindert. Sich durchzuhangeln ist also keine Option. Man müsste dann ja auch testen, ob eine gültige Lizenz vorliegt, auf vielen Rechner liegt eine vorinstallierte Version, die man aktivieren kann aber nicht aktiviert haben muss. Also alles ziemlich fraglich. Ich hätte ja auch lieber eindeutige Antworten gegeben...

    dive26 schrieb:

    Imports Microsoft.Office.Interop
    Diese Interop-DLLs sind .NET-Wrapper für ein OCX. Ob dem die vorhandene Version egal ist, glaube ich nicht.
    Du musst einfach mal ein wenig experimentieren.
    Und wenn Du Deine Software verteilst, musst Du Anforderungen definieren, die auf dem Zielrechner erfüllt sein müssen.
    Dann klappt es auch mit der Nachbarin. ;)
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    @Dksksm

    Vielen Dank für den Tipp.
    Ich habe das mit dem NuGet ausprobiert (Version 2013) und das mit der vorhandenen Version 2016 der interop.
    Beide verhalten sich identisch auf Zielsystemen:

    Zielsystem ohne Word: keine Funktion (fange ich mit Try-Catch ab und gebe eine entsprechende Meldung aus)
    Zielsystem mit Word 2016 - alles funktioniert, inkl. speichern des Word-Dokumentes als PDF.
    Zielsystem 1 mit Word 2007 - alles funktioniert, inkl. speichern des Word-Dokumentes als PDF.
    Zielsystem 2 mit Word 2007 - das exportieren als PDF funktionierte nicht (Feature nicht installiert - siehe nächster Absatz)

    Bei älteren Word-Versionen bleibt das System bei der Funktion objDocument.SaveAs2(FileName:=ZielDatei, FileFormat:=17) hängen.
    Mit objDocument.ExportAsFixedFormat(ZielDatei.ToString, Word.WdExportFormat.wdExportFormatPDF) funktionierte es beim Zielsystem 1 mit Word 2007.
    Beim Zielsystem 2 mit Word 2007 kam die Meldung "Fehler beim Exportieren, weil dieses Feature nicht installiert ist".

    Also passt das schon so.
    Ich verwende nun objDocument.ExportAsFixedFormat(ZielDatei.ToString, Word.WdExportFormat.wdExportFormatPDF).
    Da meine Anwendung ohnehin erst ab Windows 10 funktioniert, wird da wohl auch eine "kompatible" Word Version drauf sein.
    Liebe Grüße
    Roland Berghöfer

    Meine aktuellen und kostenlos verwendbaren Tools (mit VB.NET erstellt): freeremarkabletools.com | priconman.com | SimpleCalendar | AudibleTouch | BOComponent.com | bonit.at

    Hallo,

    ich verwende in einem meiner Projekte "ClosedXML" (github.com/ClosedXML/ClosedXML) um auch auf PCs ohne Office-Installation Excel Datei zu öffnen und auszulesen.
    Ich weis jetzt nicht was genau Du mit den Word-Dateien in Deinem Programm machen möchtest, aber evtl. gibt es auch etwas ähnliches wie ClosedXML für Word-Dokumente?

    Gruß

    Es geht um das Exportieren des Word-Dokuments als PDF. Eine Funktion die meines Wissens nach nur mit Interop-Funktionen zu bekommen ist.
    Ich kenne auch für Excel keine Fremd-Tools, die das können.
    Tatsächlich benutze ich für Excel EPPlus, aber selbst das wirklich geniale Werkzeug kann 2 Dinge nicht, die Interop kann: Anlagen als Objekte einfügen und diesen PDF-Export. Jedenfalls nicht in der Version 4.5.3.3 und neuere Versionen installiere ich auch lizenzrechtlichen Gründen nicht.

    Nur geht es hier gar nicht um Excel, sondern um Word. Excel scheint gefragter zu sein, so dass immer alle aus der Ecke heraus schiessen.