Klingt für mich auch so, als würde Obsidian ganz gut passen. Vor allem, weil es Daten lokal synct, was ja offensichtlich durchaus ein relevantes Feature zu sein scheint.

Auch wenns schon ne Weile her ist, aber falls mal jemand was Ähnliches sucht:

Der SQL-Server bietet ein Feature, das nennt sich Verbindungsserver. Damit kannst Du andere Datenquellen, also auch andere SQL-Server (mit denen gehts auch am Stressfreiesten) einbinden. Und dann zentral über eine SQL-Verbindung ansprechen und auch zusammen in einer Abfrage ansprechen.

Zitat von visionmaster

Ich muss aus C# heraus eine PDF-Datei in eine Text-Datei konvertieren. Es soll eigentlich die gleiche Funktion sein, die im Dialog im ACROBAT-Reader als "Speichern unter..." zur Verfügung steht.

Wichtig wäre dabei auch, dass die Ausgabedatei die gleiche Struktur hat, die ACROBAT erzeugt.

Ob das mit dem letzten Punkt so klappt kann ich nicht sagen, aber wir haben vor paar Jahren für die reine Textextraktion die  Tesseract OCR Engine genutzt. Lief relativ gut und auch performant. Vielleicht ja nen Lösungsansatz...

Man kann zwar auch versuchen den Adobe Reader anzusprechen und zu automatisieren, aber das war immer problematisch und auch alles Andere als stabil.

Zitat von Abt

Zitat von vieledinge

Alles, was länger als 30 Zeilen ist sollte man überdenken

Mit welchem Sinn? Der Sinn von Trennung in Methoden ist Verantwortlichkeit.

Da stimme ich Dir durchaus zu.

Die 30 Zeilen sind kein Dogma. Die Praxis zeigt aber, dass es ab einer gewissen Codeblockgröße durchaus sinnvoll sein kann, da hinterher nochmal drüber nachzudenken, was man da tut und ob man das eventuell nochmal aufteilen sollte. Und wenn die Antwort "Nein" lautet, dann ist es auch gut.

Paar Punkte, die mir spontan auffallen:

Größe der Codeblöcke: Kurzer, kompakter Code ist besser verständlich. Alles, was länger als 30 Zeilen ist sollte man überdenken, ob man da nicht Teile davon sinnvoll in separate Functions oder Klassen auslagern kann.

Geschachtelte Schleifen: Würde ich versuchen zu vermeiden. Auch hier: Blöcke in Functions auslagern.

do while: Mag ich nicht (Persönliche Hassliebe). Konditionen am Ende der Schleife finde ich einfach bescheiden lesbar.

Ausgaben sinnvoll zusammenfassen, um kompakten Code zu erhalten. Die drei Varianten machen alle das Gleiche. Man muss halt ggfs. schauen, für welche Plattform(en) man entwickelt:

Console.WriteLine();
Console.WriteLine("Der eingegebene Wert muss eine Zahl sein!");
Console.WriteLine();

Console.WriteLine("\r\nDer eingegebene Wert muss eine Zahl sein!\r\n");

Console.WriteLine($"{Environment.NewLine}Der eingegebene Wert muss eine Zahl sein!{Environment.NewLine}");

Hallo zusammen,

für nen Inhouse-Projekt bräuchte ich ne Komponente, um erhaltene Rechnungs-PDFs zu prüfen, ob es sich um elektronische Rechnungen nach ZugFerd-/XRechnungs-Standard handelt und um danach die eingebetteten XML-Rechnungdsdaten zu extrahieren. Kann zwar theoretisch auch das vorhandene DMS, ich brauche aber bestimmte Infos für die korrekte Prozesseinsteuerung, BEVOR ich das Zeug ins DMS werfe.

Was ganz interessant aussieht ist https://konik.io, muss ich aber noch testen.

Gibts noch Tipps zu anderen, schlanken Tools, die man sich mal anschauen sollte?

Ansonsten findet man so einige Suiten wie PDFlib, die eher in Richtung eierlegende Wollmilchsau gehen und hier eher die Variante "mit der Wurst nach dem Schinken geworfen" wären.

VG Uwe

Zitat von Abt

Blöderweise liegen im ERP-Verzeichnis div. weitere DLLs (MS, 3rdParty), die so auch von den DMS-DLLs benötigt werden. Aber natürlich andere Versionsstände und irgendwas beißt sich da und das ERP zickt rum, wenn ich da die neueren Versionen nutzen will.

Verschiedene Versionen beißen sich immer, sofern Du Dich in einer App Domain befindest. Da hilft auch ein anderer Ordner nicht.

Das war vielleicht bisschen unglücklich ausgedrückt: Ich selbst nutze in meinen Komponenten indirekt nur eine Version der DLLs (die, die von der DMS-Software benötigt werden). Da ich aber dem ERP-System meine DLL nicht an einem beliebigen Ort zur Verfügung stellen kann, sondern die blöderweise zwingend im ERP-Verzeichnis liegen muss, habe ich das Dateikonflikt-Problem.

Habe ich ne Möglichkeit die Verweis-Komponenten der DLL in der Runtime-Umgebung in einem anderen Verzeichnis unterzuschieben? Also so, dass meine DLL immer noch im ERP-Verzeichnis liegt, alle zugehörigen Verweis-DLLs aber z.Bsp. in nem Unterverzeichnis \DMS?

Oder kann ich der DLL auch ne app.config unterschieben?

Es gibt auch dll.configs, wobei die ursprünglich einen anderen Zweck haben.
Könnte sein, dass aber assembly bindings ebenfalls unterstützt werden.

Ok, also mal testen.

Hallo zusammen,

ich stecke bisschen in der DLL-Klemme....

Ich baue eine Funktionserweiterung als DLL für eine Serverkomponente unseres ERP-Systems. Meine DLL muss zwingend in das dortige Programmverzeichnis, damit die von den ERP-Komponenten richtig angesprochen wird. Das kann ich leider nicht ändern.

In meinem Projekt nutze ich wiederum andere DLLs (DMS, Dokumentenmanagementsystem)

Blöderweise liegen im ERP-Verzeichnis div. weitere DLLs (MS, 3rdParty), die so auch von den DMS-DLLs benötigt werden. Aber natürlich andere Versionsstände und irgendwas beißt sich da und das ERP zickt rum, wenn ich da die neueren Versionen nutzen will.

Habe ich ne Möglichkeit die Verweis-Komponenten der DLL in der Runtime-Umgebung in einem anderen Verzeichnis unterzuschieben? Also so, dass meine DLL immer noch im ERP-Verzeichnis liegt, alle zugehörigen Verweis-DLLs aber z.Bsp. in nem Unterverzeichnis \DMS?

https://mycsharp.de/forum/threads/119961/programm-dll-s-in-anderen-ordner-legen?page=1 habe ich schon gefunden, aber das bezieht sich ja auf Standalone-Projekte. Oder kann ich der DLL auch ne app.config unterschieben?

Jemand ne Idee?

Schöne Adventszeit!

Zitat von Abt

Das Control, siehe Docs, bietet Dir von Haus aus nur einen Click-Event an.

Schade. Manchmal überliest man ja was...

Nur als Hinweis: VSTO ist schon seit über 10 Jahren abgekündigt und alles moderne geht nur noch über die JavaScript Schnittstellen.
Dort hast Du auch mehr UI Möglichkeiten, als es in VSTO jemals gab.

Soweit bekannt. Es gibt da aber interne Abhängigkeiten und Vorgaben. Irgendwann gibts dann halt mal ein größeres Migrationsprojekt...

Hallo zusammen,

Eigenes Office-Plugin (VSTO, Office 2016) mit div. Ribbons.

Ich nutze in den Ribbons RibbonSplitButtons mit untergeordneten RibbonButtons. Funktioniert soweit alles super. Allerdings klicken manchmal Anwender auf den RibbonSplitButton und wundern sich, dass erst mal nichts passiert. Weil die eigentlichen Funktionsaufrufe alle an den untergeordneten RibbonButtons hängen. Das ist so prinzipiell gewollt.

Bekomme ich den RibbonSplitButton irgendwie per Code aufgeklappt? Das könnte man ja dann ins dortige Clieck-Event packen.

Google war leider wenig hilfreich.