Laden...

In Applikation alternativ 32-bit oder 64-bit DLL verwenden

Erstellt von oehrle vor 2 Jahren Letzter Beitrag vor 2 Jahren 1.914 Views
O
oehrle Themenstarter:in
461 Beiträge seit 2009
vor 2 Jahren
In Applikation alternativ 32-bit oder 64-bit DLL verwenden

Hallo Community, sorry, bestimmt gibt es dazu schon einen Eintrag im Forum, habe aber mit der Suche keine Treffer finden können.
Kann man eigentlich mit Jokerzeichen suchen lassen? Jetzt aber zum eigentlichen Thema.

Ich habe eine Applikation, die wurde um einen Dokumentenansicht erweitert. Und zwar wird da eine externes System angezapft, dass mir dann die Dokumente per Filetransfer liefert.

Nun ist es so das ich dazu eine DLL bekommen habe, die mit 32-Bit Architektur erstellt ist.
Meine Applikation war auf ANY-CPU eingestellt, das heißt ja das diese selbständig bei der Installation für 64- oder 32-Bitsystem entschieden wird.
Nun habe ich die Applikation komplett auf Zielplattform 32-Bit gestellt.

Nun habe ich den Eindruck, dass die Appliaktion nun öfters abschmiert, weil diese Appliaktion sehr viele Daten vom SQL-Server saugt, unsere CAD-Programmierer mit ihren Tools auch schon viel Arbeitsspeicher brauchen und so die Ressourcen knapp werden.

Dazu kommt, dass diese Appliaktion auch noch auf WINXP laufen soll, damit haben wir noch ausgerüstete Maschinen, auf denen die Applikation läuft (da halt mit 32-Bit, deshalb waren alle eingebundenen Projekte der Applikation mit Zielplattform AnyCPU eingestellt).

Diese ganze Applikation verteile ich per ClickOnce.

Nun meine Frage, gibt es eineMöglichkeit wie ich das steuern kann ob die DLL mit 32-Bit oder 64-Bit verwendet werden soll, und das ganze weiterhin als eine einzige Appliaktion mit ClickOnce zu verteilen?

16.807 Beiträge seit 2008
vor 2 Jahren

Meine Applikation war auf ANY-CPU eingestellt, das heißt ja das diese selbständig bei der Installation für 64- oder 32-Bitsystem entschieden wird.

Nein heisst es nicht.
Die Entscheidung wird auf Prozess-Ebene getroffen, nicht bei der Installation.

Siehe meine Antwort vom 6. Juli in Softwareversion (aus Registry) wird im Release-Modus erkannt, im Debug-Modus nicht

Nun meine Frage, gibt es eineMöglichkeit wie ich das steuern kann ob die DLL mit 32-Bit oder 64-Bit verwendet werden soll, und das ganze weiterhin als eine einzige Appliaktion mit ClickOnce zu verteilen?

Du selbst kannst Das nur über die Compiler Optionen steuern (siehe auch Doku).
Im Prozess kannst Du das selbst nicht mehr ändern, weil zu diesem Zeitpunkt der Prozess schon geladen wurde.

Zumindest früher gab es Tools Exe-Dateien nachträglich entsprechend zu patche (CorFlags); aber zur Laufzeit geht das nicht (gilt aber IIRC nur für .NET Framework Dateien!).
Auch war es zumindest bei .NET Framework Anwendung möglich die jeweilige Anwendung über eine x64 bzw x86 Konsolen-Instanz zu starten, um eine AnyCPU-Anwendung mit der jeweiligen Bitness zu forcen.

6.911 Beiträge seit 2009
vor 2 Jahren

Hallo oehrle,

das ich dazu eine DLL bekommen habe, die mit 32-Bit Architektur erstellt ist

Eine .NET DLL od. eine native DLL?

Nun habe ich den Eindruck, dass die Appliaktion nun öfters abschmiert, ... viel Arbeitsspeicher

Hast du dazu eine Fehlermeldung od. einen Eintrag in der Windows-Ereignisanzeige?
32bit Anwendungen / Prozesse können auf weniger Arbeitsspeicher (korrekter: virtuellen Speicher) zugreifen als 64bit Prozesse, aber ich glaube eher nicht dass dies das Problem ist. Falls doch solltest du OutOfMemoryExceptions sehen -- die aber nicht zwangsläufig mit zu wenig Speicher zu tun haben müssen (sondern ein paar andere Gründe haben können wie hauptsächlich dass der GC keinen Platz findet um das Objekt der gewünschten Größe zu alloziieren).

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

O
oehrle Themenstarter:in
461 Beiträge seit 2009
vor 2 Jahren

Hallo Abt, danke für die Info. Der Beitrag liegt schon etwas zurück, aber habe mich erst heute damit beschäftigt.
Also, wenn ich das richtig verstehe, dann muss ich die Applikation jeweils wür 32-Bit-Systeme und für 64-Bit-Systeme erstellen.
Die Anwender müssen dann entscheiden, was sie installieren (je nach Windows-Version, bei uns gibt es noch XP 😉

In der Applikation kann ich nicht entscheiden, welche DLL geladen werden soll? Sonst könnte man ja bestimmt die Architektur abfragen?

Ja, gfoidl meint ja das etwas mit dem GC nicht stimmt. OutofMemory-Ex ist schon aufgetreten. Ich denke da wo das hauptsächlich passiert, die nutzen noch eine andere RAM-lüsterne Applikation da diese auch Simulationen durchführt, und diese ist als 32-Bit aktiv.
Wie kann ich das nachsehen, im Taskmanager, sehen was sich die Appliaktionen an RAM greifen?

16.807 Beiträge seit 2008
vor 2 Jahren

Also, wenn ich das richtig verstehe, dann muss ich die Applikation jeweils wür 32-Bit-Systeme und für 64-Bit-Systeme erstellen.

Jo, wie das seit vielen vielen Jahren bei vielen vielen Anwendungen der Standard-Fall ist und nach und nach nur noch 64 Bit Anwendungen gibt.

In der Applikation kann ich nicht entscheiden, welche DLL geladen werden soll? Sonst könnte man ja bestimmt die Architektur abfragen?

Siehe oben: Nein, nicht mehr wenn die Anwendung schon gestartet ist.

Wie kann ich das nachsehen, im Taskmanager, sehen was sich die Appliaktionen an RAM greifen?

Einfach Task Manager öffnen und die RAM-Reservierungen anschauen...?

O
oehrle Themenstarter:in
461 Beiträge seit 2009
vor 2 Jahren

Hallo, habe gerade an dem Projekt nochmal getestet.
Was dazu sagen kann: Bei manchen Arbeitsplätzen läuft noch eine Software mit Simulation, die ist auch als 32-Bit installiert, die braucht auch heftig RAM. Bei diesen Arbeitsplätzen passiert auch der Absturz, da ist der RAM auch sehr ausgenutzt (haben 16 GB RAM, aber 32-Bit kann das ja nicht nutzen). Wenn nun beide Applikationnen sehr RAM-durstig sind, dann kämpfen die um die gleichen Speicherzellen bis 4.2 GB, oder? Darüber kommen die Anwendungen ja nicht ran, wegen 32-Bitgrenze.

Dann noch eine andere Frage: Wenn ich eine Applikation habe die aus mehren Projekten zusammen besteht, und die Hauptapplikation (Startprojekt) wird mit Target "x64" eingestellt, dann müssen ja alle anderen Projekte in der Applikation auch auf "x64" eingestellt sein, korrekt ?? Ist ein Projekt auf "x32", dann funktioniert die Applikation nicht, korrekt?

Folgende Überlegung: Meine Applikation besteht aus 10 Projekten. 8 Projekte sind relativ keline brauchen wenig RAM, zwei Projekte können aber schon relativ viel Speicher brauchen.
Wäre es möglich, das ich diese beiden speicherhungrigen Projekte als EXE erstelle und dann von meiner Applikation aben starte? Dann könnte diese als 64-Bit laufen, alles andere bleibt wie gehabt ?? Und das hätte den Vorteil, das ich dann von WinXP diese zwei speicherhungringen Projekte auch als 32-Bit aufrufen könnte, und das somit auf WinXP noch läuft (Anmerkung: auf den WinXP-rechner läuft keine andere Ramdurstige Anwendung).

Wäre das ein Weg?

16.807 Beiträge seit 2008
vor 2 Jahren

Wenn nun beide Applikationnen sehr RAM-durstig sind, dann kämpfen die um die gleichen Speicherzellen bis 4.2 GB, oder? Darüber kommen die Anwendungen ja nicht ran, wegen 32-Bitgrenze.

Ne, so funktioniert die RAM-Verwaltung nicht.
Das Betriebssystem kann prinzipiell den Applikationen mehr RAM zur Verfügung stellen als das system physikalisch hat, zB durch Auslagerungsdateien.
Auch wird Dein Prozess niemals auf Speicherzellen-Basis agieren. Aber Dein Prozess kann nicht mehr Speicher allokieren als die Bitness zulässt. Völlig wurst wie Dein System aussieht.
Wenn Du es verstehen willst, dann musst die Grundlagen von Betriebssystemen verstehen, also Handles, Thread, Processes, Memory Management etc.

Sollen Deine Anwendung mehr Speicher nutzen können dann kommst Du niemals um x64 rum.

dann müssen ja alle anderen Projekte in der Applikation auch auf "x64" eingestellt sein, korrekt ?? Ist ein Projekt auf "x32", dann funktioniert die Applikation nicht, korrekt?Wäre das ein Weg?

Das steht alles in dem Link, der Dir gegeben wurde: die Bitness muss immer übereinstimmen.
Any CPU hat man nur der .NET Runtime zu verdanken, die dem Entwickler hier viel abnimmt; und eben der WOW64 Emulation von Windows.
Gäbe es das nicht, dann müsste der Entwickler hier viel mehr Eigenorganisation ins Spiel bringen.

Wäre es möglich, das ich diese beiden speicherhungrigen Projekte als EXE erstelle und dann von meiner Applikation aben starte?

Probiers doch einfach aus?

Möglich ist alles, immer nur eine Frage des Aufwands.

O
oehrle Themenstarter:in
461 Beiträge seit 2009
vor 2 Jahren
EXE als X86 erstellen und bei anderer Platform verweden

Hallo Abt, ist schon wieder ein bischen her, aber habe aus dem einen Projekt eine EXE erstellt, mit Übergabeargumenten versehen (bei Programmstart zur Steuerung).
Das funktioniert, kann diese dann aus einerHaptanwendung die z.B. mit "Any CPU" kinfiguriert ist aufrufen und laufen lassen.
Verwende dich die DLL der Applikation, dann geht das nicht (eine SAP-DLL ist wohl nur für X86 ausgelegt, die bekomme ich nicht anders her).

Also würde das mit der EXE soweit funktionieren. Diese rufe ich dann mit "Process.Start" in meiner Applikation auf.

Dazu hätte ich noch einer Frage: Gibt es eine Möglichkeit, bei "Process.Start" einen Rückgabewert aus der aufgerufenen EXE auszuwerten, um dann in der Haupapplikation zu entscheiden, ob die EXE-Ausführung das was sie machen soll auch machen konnte.

Die EXE ruft Daten aus einer Applikation ab. Mißlint dies, gibt die Anwendung "FALSE" zurück. Kann ich die in "Process.Start" auswerten? Da gibt es etwas, aber scheint aber nicht genau das zu tun.

Ich weiss, das ist nicht der korrekte Weg, aber ich muss mit da jetzt erst mal so behelfen.

T
2.219 Beiträge seit 2008
vor 2 Jahren

Process.Start liefert dir die Process Instanz.
Diese wiederrum liefert dir im ExitCode den Wert welchen Main zurückgibt.

Dort kannst du dann einen entsprechenden int Wert aus deiner Anwendung liefern lassen und entsprechend auswerten.
Dazu muss die Main Methode einfach einen int zurück liefern, der dann den entsprechenden Status liefert.

Info:
Process.ExitCode Eigenschaft (System.Diagnostics)

Nachtrag:
Ich verstehe nur nicht was du mit deiner DLL an der Stelle hast.
Ich habe auch eine DLL für SAP in einer Anwendung.
Diese muss dann aber explizit für die jeweilige Variante(32/64 Bit) erstellt werden.
Hier ist mir dann aber nicht klar in welcher Verbindung dies zu deinem Process.Start Problem steht.

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

O
oehrle Themenstarter:in
461 Beiträge seit 2009
vor 2 Jahren

Danke für T-Virus für die Antwort.
Das mit der DLL hat mti SAP zu tun, das habe ich von einem externen Kollegen bekommen, darinsind Anmeldemethodik und Abfragemethodik enthalten. Da ist eine mit X86 wohl erstellt, die aber dann in meiner Hauptanwendung (wenn diese auf "Any CPU" eingestellt ist) nicht läuft. Ist die Hauptanwendung mit "X86" eingestellt, dann kein Problem.
Das war das Problem zu der DLL.
Erstellt ist alles in FW 4.0.

O
oehrle Themenstarter:in
461 Beiträge seit 2009
vor 2 Jahren

Hallo, so ich nun wieder.
Habe mit den DLL's nochmal rumgespielt und auch die neue von SAP gezogen. Leider keine Veränderung.

Nun habe ich aber noch ein Projekt, das in einer anderen Appliaktion verwendet wird. Da ist folgendes zugange:
Für das Projekt hatte ich nur Basis-DLL's die in VB eingebunden werden konnten. Also, was habe ich gemacht, ein VB-Projekt, habe meien Grundmethoden in VB programmiert, und verwende das ganze nun in einem C#-Projekt.

Das VB-Projekt war bisher immer mit x86 eingestellt, das C#-Hauptprojekt (Hauptapplikation) auch. Jetzt habe ich die C#-Hauptapplikation auf AnyCPU gestellt, dann bekomme ich die Meldung:
"An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B)"

Stelle ich das VB-Projekt auf AnyCPU kommt das auch.
Wo leigt nun das Problem? Müssen die Basis-DLL's vom VB-Projekt eine bestimmte Konfiguration haben, wenn ja wie kriege ich das raus?

Oder könnte es sein, weil ich Mehthoden im VB-Projekt mit Interger-Rückgabewerten versehen habe die mit der Typisierung "Int32" definiert sind?

16.807 Beiträge seit 2008
vor 2 Jahren

Jetzt habe ich die C#-Hauptapplikation auf AnyCPU gestellt, dann bekomme ich die Meldung:
"An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B)"

Stelle ich das VB-Projekt auf AnyCPU kommt das auch.

Hast Du meine Antwort gelesen, was AnyCPIU bedeutet? Das erklärt auch Dein anderes Problem bereits.
Wenn Du konkrete Bitness supporten musst, zB wegen externen Abhängigkeiten oder referenzierten DLLs, dann arbeite auch mit konkreten Bitness Angaben und nicht mit AnyCPU.

Und ja: die müssen alle komplett zusammen passen - auch mit der Umgebung.
Wenn Du DLLs in eine andere Anwendung einbinden musst, dann musst Du diese auch mit der korrekten Bitness zur Verfügung stellen.
Die meisten Anwendungen haben sauber dokumentiert, was möglich / nötig ist.

Zumindest in .NET sind die Typen durch Compiler/Runtime Features nicht an die Bitness gekoppelt.
Daher: Nein.

O
oehrle Themenstarter:in
461 Beiträge seit 2009
vor 2 Jahren

Hallo Abt.
Gibt es eventuell eine Möglichkeit, das gesamte Projekt aus einem Guss zu machen, aber einfach die DLL's dann über die Einstellung von Platform zu steuern? Gibt es da die Möglichkeit, in der *.csprj über die Platform die betreffende DLL zu verwenden?
Falls das möglcih wäre, funktioniert aber die Installation mit ClickOnce auch noch?

Hintergrund der Frage. Ich hätte somit den geringeren Aufwand und muss nicht 2 Projekte pflegen.

16.807 Beiträge seit 2008
vor 2 Jahren

Ich hab etwas das Gefühl (was täuschen mag) Du gehst unstrukturiert an die Sache ran oder unwillig die Doku zu lesen, auf die Du nun mehrfach hingewiesen wurdest.
Du wirst nicht drum rum kommen Dich mit dem Thema beschäftigen. Les die Dokumentation.

Ich hätte somit den geringeren Aufwand und muss nicht 2 Projekte pflegen.

Musst Du auch nicht, wenn Du es richtig machst und nicht Basteln versuchst Workarounds zu erfinden.
Verwende in Deiner Projektdatei entsprechende Conditions für Abhängigkeiten in der Plattform.

Das ist alles vollständig dokumentiert.
Gemeinsame MSBuild-Projekteigenschaften - MSBuild
Du findest hunderte Beispiele, Empfehlungen und Hintergrunde mit einer einfachen Google Suche dazu: Google Suche nach "csproj multi platform"

O
oehrle Themenstarter:in
461 Beiträge seit 2009
vor 2 Jahren

Hallo Abt. Habe mir gestern für das Problem beinahe den ganzen Tag Zeit genommen und mal nachrecherchiert.
Also, ich finde das passende zu finden ist erst mal nicht so einfach, da meistens auch die beschriebenen Dinge englisch verfasst sind. Zudem binich auch nicht der abdolute Informatiker, und bei MS findet man zu diesem Problem auch nicht gerade so viele Beschreibungen.
Also, ich habe mich dann ma an folgenden Link gehalten:
conditionally-use-32-64-bit-reference-when-building-in-visual-studio
Dann habe ich von der Applikation die aus mehreren Projekten besteht, erst mal eines genommen, wo es die DLL's für 32-Bit und 64-Bit gibt. Dieses Projekt handelt die SAP-Anbindung für Zeichnungsbetrachtung ab, die ich für 32-Bit Systeme (WINXP die haben wir noch) und auch 64-Bit Syteme benötige. Der Code der Appliaktion bleibt ja für beide Zustände gleich (ob 32 - oder 64-Bit).
Dann habe ich die beiden DLL's mal versucht einzubinden. Die 64-Bit-Varinate schien zu laufen, aber als ich auf die 32-Bit-Variante zurückgeschalten hab, funktionierte die nicht.
Eingebunden habe ich die folgendermaßen:


<ItemGroup>
    <Reference Include="PresentationCore" />
    <Reference Include="PresentationFramework" />
    <Reference Include="sapnco, Version=3.0.0.42, Culture=neutral, PublicKeyToken=50436dca5c7f7d23, processorArchitecture=x64">
      <SpecificVersion>False</SpecificVersion>
      <HintPath>..\..\..\DLLS\SapZeichnungen\x64\sapnco.dll</HintPath>
      <Private>True</Private>
    </Reference>
	   <Reference Include="sapnco, Version=3.0.0.42, Culture=neutral, PublicKeyToken=50436dca5c7f7d23, processorArchitecture=x86">
      <SpecificVersion>False</SpecificVersion>
      <HintPath>..\..\..\DLLS\SapZeichnungen\x86\sapnco.dll</HintPath>
      <Private>True</Private>
    </Reference>
    <Reference Include="sapnco_utils, Version=3.0.0.42, Culture=neutral, PublicKeyToken=50436dca5c7f7d23, processorArchitecture=x64">
      <SpecificVersion>False</SpecificVersion>
      <HintPath>..\..\..\DLLS\SapZeichnungen\x64\sapnco_utils.dll</HintPath>
      <Private>True</Private>
    </Reference>
	 <Reference Include="sapnco_utils, Version=3.0.0.42, Culture=neutral, PublicKeyToken=50436dca5c7f7d23, processorArchitecture=x86">
      <SpecificVersion>False</SpecificVersion>
      <HintPath>..\..\..\DLLS\SapZeichnungen\x86\sapnco_utils.dll</HintPath>
      <Private>True</Private>
    </Reference>

Kann es sein, das hier die "processorArchitecture=x64" falsch ist, und MSIL stehen sollte?

Zudem finde ich verwirrend, wie die genaue Einstellung gemachtr wird, das einmal die "32-Bit" oder "64-Bit" - Erstellung angestoßen wird.
Habe mal noch ein Bild dazugehängt.

6.911 Beiträge seit 2009
vor 2 Jahren

Hallo oehrle,

ich hab in diesem Thread den Faden (😉) verloren. Kannst du bitte zusammenfassen was hier das Problem ist od. trifft es das:* SAP-DLL mit 32bit und 64bit vorhanden

  • .NET Framework 4
  • soll im Idealfall zur Laufzeit die passende native DLL laden und funktionieren

?

Das geht natürlich, aber bitte um Rückmeldung dann kann ich dir ein Demo basteln.

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

O
oehrle Themenstarter:in
461 Beiträge seit 2009
vor 2 Jahren

Hallo gfoidl, genau um das geht es.
Wie mache ich das Projekt auf x86 und x64 lauffähig, wenn es die einzubindenden DLL's als 32- und 64-Bit gibt. Applikation soll auf 32- und 64Bit Betriebsystem laufen, ohne zwei Projekt fahren zu müssen.
Danke.

6.911 Beiträge seit 2009
vor 2 Jahren

Hallo oehrle,

ich mach ein wenig später dazu ein Demo, dann siehst du wie es möglich ist.

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

6.911 Beiträge seit 2009
vor 2 Jahren

Hallo oehrle,

mir ist gerade 32bit/64bit unmanaged DLL "importen" - wie? wieder eingefallen.
Wenn du also die nativen DLLs ins entsprechende Unterverzeichnis kopierst, so kannst du vie den dort beschriebenen Weg das einfac per [DllImport] (P/Invoke) einbinden.
Ist wohl der einfachste Weg ohne Win-API Hilfen od. (ab .NET Core 3.1 via NativeLibrary).

Probier das einmal aus (dann brauch ich kein Demo basteln 😉).

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

4.931 Beiträge seit 2008
vor 2 Jahren

Hallo gfoidl,

bei den beiden DLLs handelt es sich aber um .NET-Assemblies (keine nativen): SAP Connector for Microsoft .NET 3.0
(sonst könnten sie ja auch nicht als Verweis zum Projekt hinzugefügt werden)

Wichtig scheint nur zu sein, daß man die "Microsoft C++ Runtime DLLs version 10.0" in der passenden Version (x86, x64) installiert hat.

O
oehrle Themenstarter:in
461 Beiträge seit 2009
vor 2 Jahren

Hui, das hört sich ja fast noch komplizierter an als das in der CSPROJ-Datei einzutüteln ...
Ist das wirklich einfacher? das habe ich so noch nie gemacht (P/Invoke).
Bleibt im Code auch alles gleich bei beiden Vesionen (x86 oder x64, aber du sagtest ja "AnyCPU" verwenden). Wie rufe ich dann von den DLL's die Methoden auf?
Und wie mache ich das, wenn das Projekt mit ClickOnce veröffentlicht wird. Muss ich dann alle DLL's mit den diversen Bittigkeiten in das Projekt verlinken oder zufügen ?

Dann noch eine Frage. Habe ein Bild von einem der beien DLL-typen gemacht (x86/x64). Wenn ich das richtig verstehe, dann ist das managed DLL, korrekt?
Das heißt dann, das müßte ohen das ganze von oben beschrieben funktionieren?

6.911 Beiträge seit 2009
vor 2 Jahren

Hallo oehrle,

ich kenn mich nicht mehr aus, jetzt wieder alles anders als bei meiner Nachfrage oben. Du machst das Helfen nicht unbedingt leicher... 😉

Auch wenn es hier wohl nicht mehr passt, hab ich ein Demo für native Dlls erstellt --> 32bit/64bit unmanaged DLL "importen" - wie?

Hallo Th69,

bei den beiden DLLs handelt es sich aber um .NET-Assemblies (keine nativen): SAP Connector for Microsoft .NET 3.0

ah, das sind dann wohl C++/CLI Dlls. Gut zu wissen.

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

O
oehrle Themenstarter:in
461 Beiträge seit 2009
vor 2 Jahren

Hallo gfoidl, habe mir das geerade runtergeladen und angesehen.
Die beiden DLL's sind ja managed, aber wie du sagst wohl in C++. Das heißt ic nehme die "NetFull"-Variante (hbe FW 4.0 in Verwendung), oder egal, das unterstützt noch alle Frameworks, korrekt?
Ich binde die beiden DLL's ein und mache in der App.xamls.cs die Auswertung auf 32- oder 64-Bit, dazu wir dann die statische Klasse "NativLib" aufgerufen.
In der Klasse definiere ich die DLL doer mehrere DLL's mit der/den Variablennamen denen ich DLL-Namen zuweise.

Wenn ich mehrere DLL's habe, muss ich noch jede DLL anlegen oder wie nennt man das:
==> [DllImport(LibName, EntryPoint = "getBitnessMessage")]

Korrekt?

Ansonsten muss ich im Code nichts machen, alles bleibt wie es war?

4.931 Beiträge seit 2008
vor 2 Jahren

Hallo oehrle,

nein, der Ansatz von gfoidl ist nur für das Laden nativer DLLs (d.h. in C oder C++ entwickelt), nicht für managed DLLs (C#, VB.NET, C++/CLI) - das hilft dir hier nicht weiter.

Dann habe ich die beiden DLL's mal versucht einzubinden. Die 64-Bit-Varinate schien zu laufen, aber als ich auf die 32-Bit-Variante zurückgeschalten hab, funktionierte die nicht.

Was genau funktionierte nicht, d.h. gab es eine Fehlermeldung oder ...?

O
oehrle Themenstarter:in
461 Beiträge seit 2009
vor 2 Jahren

Also, ohne groß auszuholen.
Ich habe versucht das in der CSPROJ einzubinden, das bei unterschiedlicher Prozessorarchitektur (x86/x64).

Schritt 1:
Habe dem Projekt bei den Verweisen die beiden DLL's als x64 eingebunden.
Dann habe das Projekt gestartet, einmal als "AnyCPU" und einmal als "x64" laufen lassen.
Beides mal hat es funktioniert.

Habe ich "x86" angewählt,dann ging es nicht.

Aktueller Aufbau der "CSPROJ":


<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="15.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <Import Project="$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props" Condition="Exists('$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props')" />
  <PropertyGroup>
    <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
    <Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
    <ProjectGuid>{8CBB9BA6-BCF3-476A-BDBA-005913EA9A0E}</ProjectGuid>
    <OutputType>WinExe</OutputType>
    <AppDesignerFolder>Properties</AppDesignerFolder>
    <RootNamespace>SapZeichnungsViewer</RootNamespace>
    <AssemblyName>SapZeichnungsViewer</AssemblyName>
    <TargetFrameworkVersion>v4.0</TargetFrameworkVersion>
    <FileAlignment>512</FileAlignment>
    <Deterministic>true</Deterministic>
    <TargetFrameworkProfile>
    </TargetFrameworkProfile>
  </PropertyGroup>
  <PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Debug|x86'">
    <DebugSymbols>true</DebugSymbols>
    <OutputPath>bin\x86\Debug\</OutputPath>
    <DefineConstants>
    </DefineConstants>
    <DebugType>full</DebugType>
    <PlatformTarget>x86</PlatformTarget>
    <LangVersion>7.3</LangVersion>
    <ErrorReport>prompt</ErrorReport>
  </PropertyGroup>
  <PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Release|x86'">
    <OutputPath>bin\x86\Release\</OutputPath>
    <DefineConstants>
    </DefineConstants>
    <Optimize>false</Optimize>
    <DebugType>pdbonly</DebugType>
    <PlatformTarget>x86</PlatformTarget>
    <LangVersion>7.3</LangVersion>
    <ErrorReport>prompt</ErrorReport>
  </PropertyGroup>
  <PropertyGroup>
    <StartupObject>SapZeichnungsViewer.App</StartupObject>
  </PropertyGroup>
  <PropertyGroup />
  <PropertyGroup>
    <SignAssembly>false</SignAssembly>
  </PropertyGroup>
  <PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Debug|AnyCPU'">
    <DebugSymbols>true</DebugSymbols>
    <OutputPath>bin\AnyCPU\Debug\</OutputPath>
    <DebugType>full</DebugType>
    <PlatformTarget>AnyCPU</PlatformTarget>
    <LangVersion>7.3</LangVersion>
    <ErrorReport>prompt</ErrorReport>
    <NoWarn>0168</NoWarn>
  </PropertyGroup>
  <PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Release|AnyCPU'">
    <OutputPath>bin\AnyCPU\Release\</OutputPath>
    <DebugType>pdbonly</DebugType>
    <PlatformTarget>AnyCPU</PlatformTarget>
    <LangVersion>7.3</LangVersion>
    <ErrorReport>prompt</ErrorReport>
  </PropertyGroup>
  <PropertyGroup>
    <NoWin32Manifest>true</NoWin32Manifest>
  </PropertyGroup>
  <ItemGroup>
    <Reference Include="PresentationCore" />
    <Reference Include="PresentationFramework" />
    <Reference Include="sapnco">
      <HintPath>..\..\..\DLLS\SapZeichnungen\x64\sapnco.dll</HintPath>
    </Reference>
    <Reference Include="sapnco_utils">
      <HintPath>..\..\..\DLLS\SapZeichnungen\x64\sapnco_utils.dll</HintPath>
    </Reference>
    <Reference Include="System" />
    <Reference Include="System.Configuration" />
    <Reference Include="System.Core" />
    <Reference Include="System.Web.Extensions" />
    <Reference Include="System.Xaml" />
    <Reference Include="System.Xml.Linq" />
    <Reference Include="System.Data.DataSetExtensions" />
    <Reference Include="Microsoft.CSharp" />
    <Reference Include="System.Data" />
    <Reference Include="System.Xml" />
    <Reference Include="WindowsBase" />
  </ItemGroup>
  <ItemGroup>
    <Compile Include="App.xaml.cs">
      <DependentUpon>App.xaml</DependentUpon>
    </Compile>
    <Compile Include="MainWindow.xaml.cs">
      <DependentUpon>MainWindow.xaml</DependentUpon>
    </Compile>
    <Compile Include="Properties\AssemblyInfo.cs" />
    <Compile Include="Zusatzklassen\ECCDestinationConfig.cs" />
    <Compile Include="Zusatzklassen\SAPFunctions.cs" />
    <Compile Include="SapViewerMethods.cs" />
    <Compile Include="Zusatzklassen\Tools.cs" />
    <Compile Include="Zusatzklassen\ViewFiles.cs" />
  </ItemGroup>
  <ItemGroup>
    <PackageReference Include="PDFsharp-MigraDoc-GDI">
      <Version>1.51.5186-beta</Version>
    </PackageReference>
    <PackageReference Include="System.ValueTuple">
      <Version>4.5.0</Version>
    </PackageReference>
  </ItemGroup>
  <ItemGroup>
    <Content Include="App.config">
      <CopyToOutputDirectory>Always</CopyToOutputDirectory>
    </Content>
  </ItemGroup>
  <ItemGroup>
    <ApplicationDefinition Include="App.xaml">
      <Generator>MSBuild:Compile</Generator>
      <SubType>Designer</SubType>
    </ApplicationDefinition>
    <Page Include="MainWindow.xaml">
      <SubType>Designer</SubType>
      <Generator>MSBuild:Compile</Generator>
    </Page>
  </ItemGroup>
  <ItemGroup>
    <None Include="Doc-SapZeichnungsViewer.docx" />
  </ItemGroup>
  <ItemGroup>
    <ProjectReference Include="..\AdditionalFuncs\AdditionalFuncs.csproj">
      <Project>{86b31f9e-ef5b-46b0-8559-b4a5043dffd3}</Project>
      <Name>AdditionalFuncs</Name>
    </ProjectReference>
  </ItemGroup>
  <Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
</Project>

Schritt 2:
Ich habe die "CSPROJ" abgeändert, damit auch die "32-Bit"-Variante passen soll. Aber macht eigentlich keinen Sinn wenn das "managed" ist.
Bei den Verweisen habe ich nichts verändert.
"x64 / AnyCPU" läuft, aber "x86" nicht, Fehlermeldung liegt bei.

Hier die abgeänderte CSPROJ-Datei (neuer Teil ist gekennzeichnet):


<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="15.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <Import Project="$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props" Condition="Exists('$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props')" />
  <PropertyGroup>
    <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
    <Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
    <ProjectGuid>{8CBB9BA6-BCF3-476A-BDBA-005913EA9A0E}</ProjectGuid>
    <OutputType>WinExe</OutputType>
    <AppDesignerFolder>Properties</AppDesignerFolder>
    <RootNamespace>SapZeichnungsViewer</RootNamespace>
    <AssemblyName>SapZeichnungsViewer</AssemblyName>
    <TargetFrameworkVersion>v4.0</TargetFrameworkVersion>
    <FileAlignment>512</FileAlignment>
    <Deterministic>true</Deterministic>
    <TargetFrameworkProfile>
    </TargetFrameworkProfile>
  </PropertyGroup>
  <PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Debug|x86'">
    <DebugSymbols>true</DebugSymbols>
    <OutputPath>bin\x86\Debug\</OutputPath>
    <DefineConstants>
    </DefineConstants>
    <DebugType>full</DebugType>
    <PlatformTarget>x86</PlatformTarget>
    <LangVersion>7.3</LangVersion>
    <ErrorReport>prompt</ErrorReport>
  </PropertyGroup>
  <PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Release|x86'">
    <OutputPath>bin\x86\Release\</OutputPath>
    <DefineConstants>
    </DefineConstants>
    <Optimize>false</Optimize>
    <DebugType>pdbonly</DebugType>
    <PlatformTarget>x86</PlatformTarget>
    <LangVersion>7.3</LangVersion>
    <ErrorReport>prompt</ErrorReport>
  </PropertyGroup>
  <PropertyGroup>
    <StartupObject>SapZeichnungsViewer.App</StartupObject>
  </PropertyGroup>
  <PropertyGroup />
  <PropertyGroup>
    <SignAssembly>false</SignAssembly>
  </PropertyGroup>
  <PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Debug|AnyCPU'">
    <DebugSymbols>true</DebugSymbols>
    <OutputPath>bin\AnyCPU\Debug\</OutputPath>
    <DebugType>full</DebugType>
    <PlatformTarget>AnyCPU</PlatformTarget>
    <LangVersion>7.3</LangVersion>
    <ErrorReport>prompt</ErrorReport>
    <NoWarn>0168</NoWarn>
  </PropertyGroup>
  <PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Release|AnyCPU'">
    <OutputPath>bin\AnyCPU\Release\</OutputPath>
    <DebugType>pdbonly</DebugType>
    <PlatformTarget>AnyCPU</PlatformTarget>
    <LangVersion>7.3</LangVersion>
    <ErrorReport>prompt</ErrorReport>
  </PropertyGroup>
  <PropertyGroup>
    <NoWin32Manifest>true</NoWin32Manifest>
  </PropertyGroup>
  <ItemGroup>
    <Reference Include="PresentationCore" />
    <Reference Include="PresentationFramework" />
    <Reference Include="sapnco">
      <HintPath>..\..\..\DLLS\SapZeichnungen\x64\sapnco.dll</HintPath>
    </Reference>
    <Reference Include="sapnco_utils">
      <HintPath>..\..\..\DLLS\SapZeichnungen\x64\sapnco_utils.dll</HintPath>
    </Reference>
	
	<!-- START - Neu eingstellt -->
	
	<Reference Include="sapnco, version=3.0.0.42, culture=neutral, publickeytoken=50436dca5c7f7d23, processorarchitecture=x64">
      <HintPath>..\..\..\DLLS\SapZeichnungen\x64\sapnco.dll</HintPath>
    </Reference>
    <Reference Include="sapnco_utils, version=3.0.0.42, culture=neutral, publickeytoken=50436dca5c7f7d23, processorarchitecture=x64">
      <HintPath>..\..\..\DLLS\SapZeichnungen\x64\sapnco_utils.dll</HintPath>
    </Reference>
	
	<!-- ENDE - Neu eingstellt -->
	
	<Reference Include="sapnco">
      <HintPath>..\..\..\DLLS\SapZeichnungen\x64\sapnco.dll</HintPath>
    </Reference>
    <Reference Include="sapnco_utils">
      <HintPath>..\..\..\DLLS\SapZeichnungen\x64\sapnco_utils.dll</HintPath>
    </Reference>
	
	
    <Reference Include="System" />
    <Reference Include="System.Configuration" />
    <Reference Include="System.Core" />
    <Reference Include="System.Web.Extensions" />
    <Reference Include="System.Xaml" />
    <Reference Include="System.Xml.Linq" />
    <Reference Include="System.Data.DataSetExtensions" />
    <Reference Include="Microsoft.CSharp" />
    <Reference Include="System.Data" />
    <Reference Include="System.Xml" />
    <Reference Include="WindowsBase" />
  </ItemGroup>
  <ItemGroup>
    <Compile Include="App.xaml.cs">
      <DependentUpon>App.xaml</DependentUpon>
    </Compile>
    <Compile Include="MainWindow.xaml.cs">
      <DependentUpon>MainWindow.xaml</DependentUpon>
    </Compile>
    <Compile Include="Properties\AssemblyInfo.cs" />
    <Compile Include="Zusatzklassen\ECCDestinationConfig.cs" />
    <Compile Include="Zusatzklassen\SAPFunctions.cs" />
    <Compile Include="SapViewerMethods.cs" />
    <Compile Include="Zusatzklassen\Tools.cs" />
    <Compile Include="Zusatzklassen\ViewFiles.cs" />
  </ItemGroup>
  <ItemGroup>
    <PackageReference Include="PDFsharp-MigraDoc-GDI">
      <Version>1.51.5186-beta</Version>
    </PackageReference>
    <PackageReference Include="System.ValueTuple">
      <Version>4.5.0</Version>
    </PackageReference>
  </ItemGroup>
  <ItemGroup>
    <Content Include="App.config">
      <CopyToOutputDirectory>Always</CopyToOutputDirectory>
    </Content>
  </ItemGroup>
  <ItemGroup>
    <ApplicationDefinition Include="App.xaml">
      <Generator>MSBuild:Compile</Generator>
      <SubType>Designer</SubType>
    </ApplicationDefinition>
    <Page Include="MainWindow.xaml">
      <SubType>Designer</SubType>
      <Generator>MSBuild:Compile</Generator>
    </Page>
  </ItemGroup>
  <ItemGroup>
    <None Include="Doc-SapZeichnungsViewer.docx" />
  </ItemGroup>
  <ItemGroup>
    <ProjectReference Include="..\AdditionalFuncs\AdditionalFuncs.csproj">
      <Project>{86b31f9e-ef5b-46b0-8559-b4a5043dffd3}</Project>
      <Name>AdditionalFuncs</Name>
    </ProjectReference>
  </ItemGroup>
  <Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
</Project>

Hilft das weiter?
Kann das Problem sein:

  • Muss ich was in der PropertyGroup machen, anstatt in der ItemGroup ??
  • Muss ich bei den Verweisen was anders machen ??
  • Muss ich eigentlich nur "AnyCPU" verwenden, oder geht das nicht weil die beiden DLL's eventuell C++-DLL's sind ??

Kann ich sonst noch eine Info geben??

6.911 Beiträge seit 2009
vor 2 Jahren

Hallo oehrle,

du machst dir hier das Leben wohl selbst unnötig schwer (und das schon seit Juli).
Dieser Thread hier ist kaum mehr nachvollziehbar (für mich) und es geht um mehrere Dinge zusammen. Warum hast du nicht schon zu Beginn geschrieben* WPF Anwendung basierend auf .NET 4 (da auch noch Win-XP unterstützt werden muss)

  • verteilt werden soll per ClickOnce
  • SAP-DLL mit 32 bit und 64 bit vorhanden (C++/CLI)
  • möchte nur ein Projekt verwalten müssen

dann wäre allen klar worum es geht und es könnte direkt geholten werden. Aber so kommen die Infos nur sehr schwerlich daher.
Gut, dass die SAP-DLLs C++/CLI konntest du nicht wissen, aber nur durch das Erwähnen von den SAP-DLLs hätte vermutlich jemand in der Community das gewusst bzw. lässt sich wenn eine ".NET-DLL" in verschiedenen Bittigkeiten vorliegt annehmen dass es keine reine managed Assembly ist und z.B. per ILSpy hineingucken ob es überhaupt eine .NET-DLL od. eine rein native.

Dann stellt sich auch die Frage warum nicht nur eine 32 bit Variante reicht. Also für dein WPF-Projekt nicht auf "AnyCpu" stellen, sondern eine Konfiguration für "32 bit" erstellen, damit es zur 32 bit SAP-DLL passt, und diese einfach per ClickOnce verteilen.

OK, dazu schreibst du etwas von mehr RAM-Bedarf und dass es wenn möglich doch 64 bit sein soll, die 32 bit eher nur für alten XP-Kisten da sein sollen.
Somit brauchst du neben der 32 bit Konfiguration in der gleichen Solution / Projekt eine Konfiguration für "64 bit".
"AnyCpu" sollte dabei entfernt werden, da es sonst potentiell Probleme geben kann wenn jemand zufällig wieder auf das zurückstellen sollte.

Jetzt haben wir je eine Konfiguration für 32 bit und eine für 64 bit. Damit die SAP-DLLs je nach gewählter Konfiguration eingebunden werden können, kann in der csproj per Condition die Konfiguration gewählt werden (quasi ein if für MsBuild). Dazu hat Abt aber schon in In Applikation alternativ 32-bit oder 64-bit DLL verwenden einen Hinweis auf die Doku gegeben. Diesen Hinweis kann ich hier nur wiederholen. Schau dort rein od. suche nach "msbuild condition". Das ist hier der entscheidende Punkt.

Der aktuelle stand wäre somit, dass je nach gewählter Konfiguration das Projekt / Solution mit 32 bit od. mit 64 bit erstellt wird, dabei die dazu passende SAP-DLL mit ins Ausgabeverzeichnis kopiert wird (CopyToOutputDirectory=PreserveNewest vorausgesetzt).
D.h. es gibt vom Projekt zwei verschiedene EXE, anders funktioniert es so hier nicht.* In Visual Studio kann per Batch-Build beide auf einmal erstellt werden.

Für ClickOnce gibts dann Google Suche nach "clickonce 32bit 64bit", welches u.U. zu Identifying target machine (32bit or 64bit) with ClickOnce deployment.
Ist nicht sonderlich mehr Aufwand.
Od. du stellst zwei verschiedene ClickOnce Deployments her. Eine für 32 bit (für die XP-Kisten) als "legacy" und einmal 64 bit für aktuellere Maschinen.

* Außer du verzichtest auf die Referenz (per Condition eingebunden) in deinem Projekt (<- das ist "Binding zur Entwicklungszeit) und setzt auf spätes Binding zur Laufzeit, via Reflection. Da würde von deinem Projekt eine EXE reichen, da so zur Laufzeit je nach Bittigkeit des Prozesses die passende SAP-DLL geladen werden kann.
Aber alle Zugriffe per Reflection zu machen hat auch eine Menge nachteile, deren Aufzählung ich mir hier erspare.

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

O
oehrle Themenstarter:in
461 Beiträge seit 2009
vor 2 Jahren

Hallo. Ja, das ganze hat sich echt verwurschtelt.
Bis jetzt konnte das erst mal so laufen. Aber nach und nach leuchten so die die Dinge auf, hatte damit auch vorher noch keine Berührung.
Und das mit den Net. C++ DLL's das diese anders zu behandeln sind, ja, muss man wissen. Aber dann geht es erst mal immer noch nicht (bei mir, aber denke das liegt an mir).
Ich würde das ganze schon gerne richtig verstehen, ich denke ich bin da auch schon näher dran.

Punkt 1:

  • Die DLL's (in meinem Fall Net. C++-Dll's ins Projekt in differenzierte Ordner ablegen. Mit Differennziert meine ich, im Projektmappenexplorer zwei Verzeichnisse anlegen, klassischerweise mit **x86 **und x64 (hat den Vorteil das man später mit den Conditions vonMSBuild zu arbeiten). Die DLL's darin ablegen (in der Regel haben die auch den identischen Namen)

Punkt 2:

  • Handelt es sich wie in meinem Fall um die Net. C++ - DLL / DLL's, dann muss das Projekt in der Konfiguration für x86 und x64 ausgerichtet werden (einstellen), indiesem Fall auch "AnyCPU" entfernen

Punkt 3:

  • Es muss die CSPROJ-Datei vom Projekt (Hauptprojekt) angepasst werden, mit den MSBUILD-Conditions. Ich denke hier liegt jetzt das Problem, ich schreibe auch hier erst mal nicht mehr dazu, bevor das Problem gelöst ist. Wenn das bei mir funktioniert, werde ich den Prozess mal genau beschreiben, falls auch noch andere so dappig wie ich sind

Habe das mal bis Punkt 3 beschrieben. In der CSPROJ die ich editiert habe, kann ich mir nicht erklären was genau falsch laufen soll. Ich habe zusätzlich zwei <ItemGroup> angelegt, in denen ich die Plattformeinstellung kontrolliere, dementsprechen sollen die DLL's gezogen werden.

Wenn ich aber das Projekt starte, in der VStudiooberfäche x86 oder x64 einstellen, dann bringt die Umgebung viele Fehler "Typ ooder Namespace "SAP" wurde nicht gefunden, und in der Datei sind sämtliche Klassen, Eigenschaften rot unterkringelt, und in der Fehlerliste wird ausgegeben das eine using-Direktive oder der Assemblyverweis fehlt.

Was mir noch aufgefallen ist:

  • Warum steht in der CSPROJ ganz oben noch ein Eintrag mit "AnyCPU", die habe ich entfernt, das kann nur noch bei der "Zielplattform" in Projekt-Eigenschaften-Build eingestellt werden.
  • In den beiden <ItemGroup> habe ich keine Condition für DEBUG oder RELEASE, habe es aber mit und ohne die Zusätzliche Condition geändert, macht keinen Unterschied.

So, jetzt habe ich eine Menge geschrieben, evenntuell kann das Problem analysiert werden ...

Also ich sehe jetzt den Fehler vorerst nicht, was ich falsch gesetzt habe. Ich stelle hier nochmal die CSPROJ ein:


<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="15.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <Import Project="$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props" Condition="Exists('$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props')" />
  <PropertyGroup>
    <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
    <Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
    <ProjectGuid>{8CBB9BA6-BCF3-476A-BDBA-005913EA9A0E}</ProjectGuid>
    <OutputType>WinExe</OutputType>
    <AppDesignerFolder>Properties</AppDesignerFolder>
    <RootNamespace>SapZeichnungsViewer</RootNamespace>
    <AssemblyName>SapZeichnungsViewer</AssemblyName>
    <TargetFrameworkVersion>v4.0</TargetFrameworkVersion>
    <FileAlignment>512</FileAlignment>
    <Deterministic>true</Deterministic>
    <TargetFrameworkProfile>
    </TargetFrameworkProfile>
  </PropertyGroup>
  <PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Debug|x86'">
    <DebugSymbols>true</DebugSymbols>
    <OutputPath>bin\x86\Debug\</OutputPath>
    <DefineConstants>
    </DefineConstants>
    <DebugType>full</DebugType>
    <PlatformTarget>x86</PlatformTarget>
    <LangVersion>7.3</LangVersion>
    <ErrorReport>prompt</ErrorReport>
    <NoWarn>0168</NoWarn>
  </PropertyGroup>
  <PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Release|x86'">
    <OutputPath>bin\x86\Release\</OutputPath>
    <DefineConstants>
    </DefineConstants>
    <Optimize>false</Optimize>
    <DebugType>pdbonly</DebugType>
    <PlatformTarget>x86</PlatformTarget>
    <LangVersion>7.3</LangVersion>
    <ErrorReport>prompt</ErrorReport>
  </PropertyGroup>
  <PropertyGroup>
    <StartupObject>
    </StartupObject>
  </PropertyGroup>
  <PropertyGroup />
  <PropertyGroup>
    <SignAssembly>false</SignAssembly>
  </PropertyGroup>
  <PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Debug|x64'">
    <PlatformTarget>x86</PlatformTarget>
    <OutputPath>bin\x64\Debug\</OutputPath>
  </PropertyGroup>
  <PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Release|x64'">
    <PlatformTarget>x64</PlatformTarget>
    <OutputPath>bin\x64\Release\</OutputPath>
  </PropertyGroup>
  <ItemGroup>
    <Reference Include="PresentationCore" />
    <Reference Include="PresentationFramework" />
    <Reference Include="System" />
    <Reference Include="System.Configuration" />
    <Reference Include="System.Core" />
    <Reference Include="System.Web.Extensions" />
    <Reference Include="System.Xaml" />
    <Reference Include="System.Xml.Linq" />
    <Reference Include="System.Data.DataSetExtensions" />
    <Reference Include="Microsoft.CSharp" />
    <Reference Include="System.Data" />
    <Reference Include="System.Xml" />
    <Reference Include="WindowsBase" />
  </ItemGroup>
  <ItemGroup>
    <Compile Include="MainWindow.xaml.cs">
      <DependentUpon>MainWindow.xaml</DependentUpon>
    </Compile>
    <Compile Include="Properties\AssemblyInfo.cs" />
    <Compile Include="Zusatzklassen\ECCDestinationConfig.cs" />
    <Compile Include="Zusatzklassen\SAPFunctions.cs" />
    <Compile Include="SapViewerMethods.cs" />
    <Compile Include="Zusatzklassen\Tools.cs" />
    <Compile Include="Zusatzklassen\ViewFiles.cs" />
  </ItemGroup>
  <ItemGroup>
    <PackageReference Include="PDFsharp-MigraDoc-GDI">
      <Version>1.51.5186-beta</Version>
    </PackageReference>
    <PackageReference Include="System.ValueTuple">
      <Version>4.5.0</Version>
    </PackageReference>
  </ItemGroup>
  
  <!-- Start - eingefügte ItemGroups -->
  
  <ItemGroup Condition="'$(Platform)' == 'x64'">
    <Content Include="Zusatzklassen\x64\sapnco.dll">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </Content>
    <Content Include="Zusatzklassen\x64\sapnco_utils.dll">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </Content>
  </ItemGroup>
  <ItemGroup Condition=" '$(Platform)' == 'x86'">
    <Content Include="Zusatzklassen\x86\sapnco.dll">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </Content>
    <Content Include="Zusatzklassen\x86\sapnco_utils.dll">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </Content>
  </ItemGroup>
  <ItemGroup>
    <Content Include="App.config">
      <CopyToOutputDirectory>Always</CopyToOutputDirectory>
    </Content>
  </ItemGroup>
  
  <!-- Ende - eingefügte ItemGroups -->
  
  <!-- <ItemGroup> -->
  <!-- <Content Include="App.config"> -->
  <!-- <CopyToOutputDirectory>Always</CopyToOutputDirectory> -->
  <!-- </Content> -->
  <!-- <Content Include="Zusatzklassen\x64\sapnco.dll"> -->
  <!-- <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory> -->
  <!-- </Content> -->
  <!-- <Content Include="Zusatzklassen\x64\sapnco_utils.dll"> -->
  <!-- <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory> -->
  <!-- </Content> -->
  <!-- <Content Include="Zusatzklassen\x86\sapnco.dll"> -->
  <!-- <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory> -->
  <!-- </Content> -->
  <!-- <Content Include="Zusatzklassen\x86\sapnco_utils.dll"> -->
  <!-- <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory> -->
  <!-- </Content> -->
  <!-- </ItemGroup> -->
  
  
  <ItemGroup>
    <Page Include="MainWindow.xaml">
      <SubType>Designer</SubType>
      <Generator>MSBuild:Compile</Generator>
    </Page>
  </ItemGroup>
  <ItemGroup>
    <None Include="Doc-SapZeichnungsViewer.docx" />
  </ItemGroup>
  <ItemGroup>
    <ProjectReference Include="..\AdditionalFuncs\AdditionalFuncs.csproj">
      <Project>{86b31f9e-ef5b-46b0-8559-b4a5043dffd3}</Project>
      <Name>AdditionalFuncs</Name>
    </ProjectReference>
  </ItemGroup>
  <ItemGroup />
  <Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
</Project>

6.911 Beiträge seit 2009
vor 2 Jahren

Hallo oehrle,

die SAP-DLLs sind bei dir als Content hinzugefügt, du brauchst aber Reference.

Nimm ein ganz neues einfaches Konsolen-Programm, füg dort via VS die Referenz zu SAP-x64 hinzu und schau dir den Abschnitt in der csproj an. Das kopierst du dann in deine csproj und fügst die Conditions (die sind korrekt) entsprechend hinzu.

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

O
oehrle Themenstarter:in
461 Beiträge seit 2009
vor 2 Jahren

Habe das mal probiert, aber ich denke ich bin zu doof dafür, aber es war dann doch noch ein Erfolg zu verzeichnen.

Habe eine Konsolenanwerndung in mit FW4.0 als WPF erstellt.
Habe im Projektverzeichnis zwei Ordner (x86 und x64) angelegt, habe jeweils die beiden DLL's da abgelegt.
Die Projektkonfiguratin hat nur x86 und x64.

Habe die Applikation erstellen lassen, ohne eine Zeile Code eingefügt zu haben.

Was zeigt mir die CSPROJ ? Es ist plötzlich was mit AMD64 drin, hui:


<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="15.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <Import Project="$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props" Condition="Exists('$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props')" />
  <PropertyGroup>
    <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
    <Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
    <ProjectGuid>{539E4982-E159-4FDD-99AB-E1666BC0B1CE}</ProjectGuid>
    <OutputType>Exe</OutputType>
    <RootNamespace>ConsoleAppDlltest</RootNamespace>
    <AssemblyName>ConsoleAppDlltest</AssemblyName>
    <TargetFrameworkVersion>v4.0</TargetFrameworkVersion>
    <FileAlignment>512</FileAlignment>
    <Deterministic>true</Deterministic>
  </PropertyGroup>
  <PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Debug|x64'">
    <PlatformTarget>x64</PlatformTarget>
    <OutputPath>bin\x64\Debug\</OutputPath>
  </PropertyGroup>
  <PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Release|x64'">
    <PlatformTarget>x64</PlatformTarget>
    <OutputPath>bin\x64\Release\</OutputPath>
  </PropertyGroup>
  <PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Debug|x86'">
    <PlatformTarget>x86</PlatformTarget>
    <OutputPath>bin\x86\Debug\</OutputPath>
  </PropertyGroup>
  <PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Release|x86'">
    <PlatformTarget>x86</PlatformTarget>
    <OutputPath>bin\x86\Release\</OutputPath>
  </PropertyGroup>
  
  <ItemGroup>
    <Reference Include="sapnco, Version=3.0.0.42, Culture=neutral, PublicKeyToken=50436dca5c7f7d23, processorArchitecture=AMD64">
      <SpecificVersion>False</SpecificVersion>
      <HintPath>..\..\..\DLLS\SapZeichnungen\x64\sapnco.dll</HintPath>
    </Reference>
    <Reference Include="sapnco_utils, Version=3.0.0.42, Culture=neutral, PublicKeyToken=50436dca5c7f7d23, processorArchitecture=AMD64">
      <SpecificVersion>False</SpecificVersion>
      <HintPath>..\..\..\DLLS\SapZeichnungen\x64\sapnco_utils.dll</HintPath>
    </Reference>
    <Reference Include="System" />
    <Reference Include="System.Core" />
    <Reference Include="System.Xml.Linq" />
    <Reference Include="System.Data.DataSetExtensions" />
    <Reference Include="Microsoft.CSharp" />
    <Reference Include="System.Data" />
    <Reference Include="System.Xml" />
  </ItemGroup>
  
  
  <ItemGroup>
    <Compile Include="Program.cs" />
    <Compile Include="Properties\AssemblyInfo.cs" />
  </ItemGroup>
  <ItemGroup>
    <Content Include="x64\sapnco.dll">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </Content>
    <Content Include="x64\sapnco_utils.dll">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </Content>
    <Content Include="x86\sapnco.dll">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </Content>
    <Content Include="x86\sapnco_utils.dll">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </Content>
  </ItemGroup>
  <Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
</Project>

Zuerst hatte ich gedacht es geht immer noch nicht, habe es dann aber nochmal probiert, und die beiden <Reference> mtit "AMD64" in die CSPROJ vom anderen Projekt eingbaut, dann nochmal eingebaut für "x86", siehe:


  <ItemGroup Condition="'$(Platform)' == 'x64' ">
    <Reference Include="sapnco, Version=3.0.0.42, Culture=neutral, PublicKeyToken=50436dca5c7f7d23, processorArchitecture=AMD64">
      <SpecificVersion>False</SpecificVersion>
      <HintPath>..\..\..\DLLS\SapZeichnungen\x64\sapnco.dll</HintPath>
    </Reference>
    <Reference Include="sapnco_utils, Version=3.0.0.42, Culture=neutral, PublicKeyToken=50436dca5c7f7d23, processorArchitecture=AMD64">
      <SpecificVersion>False</SpecificVersion>
      <HintPath>..\..\..\DLLS\SapZeichnungen\x64\sapnco_utils.dll</HintPath>
    </Reference>
  </ItemGroup>
  <ItemGroup Condition=" '$(Platform)' == 'x86' ">
    <Reference Include="sapnco, Version=3.0.0.42, Culture=neutral, PublicKeyToken=50436dca5c7f7d23, processorArchitecture=x86">
      <SpecificVersion>False</SpecificVersion>
      <HintPath>..\..\..\DLLS\SapZeichnungen\x86\sapnco.dll</HintPath>
    </Reference>
    <Reference Include="sapnco_utils, Version=3.0.0.42, Culture=neutral, PublicKeyToken=50436dca5c7f7d23, processorArchitecture=x86">
      <SpecificVersion>False</SpecificVersion>
      <HintPath>..\..\..\DLLS\SapZeichnungen\x86\sapnco_utils.dll</HintPath>
    </Reference>
  </ItemGroup>

Dann hat es auch nun funktioniert. Was ich noch teste ich, wenn die DLL's nur verlinkt sind.
Was komisch ist:
-Warum steht jetzt bei Prozessorarchitektur plötzlich **AMD64 **??

Ich werde da noch etwas sran herumspielen, mit Einbindung weiterer Projekte in die Projektmappe.

Eine , zwei weitere Fragen die mich jetzt gerade noch nachdenklich machen: Was passiert, wenn ich ein anderes Projekt oder eine andere Projekt-DLL in dieses Projekt aufnehme, das komplett in C# und nur mit Net-DLL's arbeitet (also keine Net. C++-Dll's)? Muss ich diese Projekt aomit auch mit x86 und x64 - Konfiguration ausstatten, damit alles funktioniert?

Wenn ich umgekehrt jetzt diese DLL mit den Net. C-Dll's in einem anderen Projekt verwenden, muss ich das andere Projekt auch für x86 und x64 konfigurieren.
Das bedeutet, kein ANYCPU in projekten verwenden, sobald wie hier Net. C
-Dll's mit 64Bit verwendet werden, ist das korrekt?

16.807 Beiträge seit 2008
vor 2 Jahren

Warum steht jetzt bei Prozessorarchitektur plötzlich **AMD64 **??

Weil das halt so heisst. AMD64

Erster Google Treffer: Was bedeutet die AMD64-Bezeichnung für CPUs?

Muss ich diese Projekt aomit auch mit x86 und x64 - Konfiguration ausstatten, damit alles funktioniert?

Das wurde Dir aber schon weiter oben erklärt und auch verlinkt.
Das kommt drauf an. In 99% der Fälle reicht hier AnyCPU und die Runtime übernimmt das für Dich.
Lies doch einfach bitte ein bisschen die Basics. 👍

O
oehrle Themenstarter:in
461 Beiträge seit 2009
vor 2 Jahren

Hallo, habe das nun soweit hingekriegt, vielen Dank an EUCH !!!
Es war noch ein Problem mit einem weiteren Projekt, das ich in der Solution eingebunden habe. Das Projekt ist in VisualBasic programmiert, das habe ich so gemacht, da ich die DLL' s der externen Firma nicht in C# einbinden konnte. Dazu sind die DLL's einmal mit 32 - und 64-Bit ausgezeichnet. Also hatte ich das alles in VB gemacht, mit den Funktionen die ich brauche und habe dann die erstellte DLL somit in meiner Hauptapplikatin verwendet. Das Problem war jetzt, das ich die 64-Bit-Version nun auch noch erstellen mußte, dazu waren Anpassungen notwendig, egal, habe ich gemacht und dann hatte ich eine DLL für 32- und 64-Bit, die ich nun verwende.
Meine Frage: Zuvor hatte ich in der Hauptapplikation dieses VisualBasic-Applikation als "Projekt" eingebunden.
Gibt eigentlich eine Möglichkeit, das man immer noch das Projekt einbindet, und beim Erstellen werden in der VisualBasicapplikation auch die korrekt bittigen DLL's gezogen?

Das Hauptproblem das ich noch habe ist aber Excel. Ich lese in einem Projekt auch Exceldateien ein ("XLS"-Format, nicht "XLSX"). Da benutze ich die "Interop"-DLL und dazu noch die "Microsoft.Jet.OLEDB.4.0". Da motzt das System bei x64.
Wie kann ich das machen, das es auf x86 und x64 läuft? Das Excelgedöns mit "NPOI" erschlagen ?? Oder gibt es da auch etwas für MSBuild mit "Referenz" ? Das was ich im Nezt gesehen habe, war mit Registrierungen über regsvr32 dieverser DLL's, aber ich kann nicht an zig Rechnern durchgehen und das Zeugs registrieren, das muss pragmatischer laufen.
Hat jemand eine Idee?

16.807 Beiträge seit 2008
vor 2 Jahren

Wie kann ich das machen, das es auf x86 und x64 läuft? Das Excelgedöns mit "NPOI" erschlagen ?? Oder gibt es da auch etwas für MSBuild mit "Referenz" ?

Will Deine Applikation x64, dann muss bei Interop-Zugriffen die Applikation als x64 Version vorliegen.
Das heisst: willst Du Interop nutzen, muss Office in der gleichen Bitness installiert sein, wie Du es brauchst.
Musst also eine Bitness fokussieren, oder eben beide und dann anhand eines Installers ermitteln, welche Version Du brauchst und dann installieren.
Völlig üblich in dieser Bitness-Matching-Welt.

Side by Side bei Office selbst wird nicht unterstützt. Dazu gibts auch nen Hinweis im Office Installer Howto.
Übrigens (auch) einer der Gründe, wieso VSTO keine Zukunft mehr hatte und alle neuen Plugins in Office JavaScript vorsehen.

Alternativ: ja, alles was Bitness-Matching erfordert (COM, Interop).. halt weglassen und andere Wege nehmen.

Vielleicht liest Dir wirklich mal die Technik durch, wie so ein PC und wie Prozesse sowie Bitness funktionieren.
Dann ersparst Dir auch so versuche mit Registry-Hacks, weil Du dann schon weißt, dass das halt keine Lösung sein kann 😉
Damit verbrätst halt nur Deine eigene Zeit, die Du ja lieber in die Lösungen stecken kannst.

das muss pragmatischer laufen.

Tjo, das sind harte Regeln. Pragmatisch ist da nicht viel.