Zugriff von 64-Bit auf 32-Bit Dll, Elegantere lösung als über 32-Bit COM?

Eventuell ist die Thema schon mal besprochen.

Wir wollen komplett auf 64-bit Anwendungen umstellen, auf Any-CPU genau gesagt.

In gründe alle Hindernisse beseitigt bis auf eine.

Die eine Software, die wir intern verwenden, war immer bei uns als 32-bit Client installiert, obwohl es auch 64-Bit gibt, aus spezifischen gründen.

Nun ist es jetzt ein Großes Problem, da nämlich unsere 64-Bit Anwendung nicht auf 32-Bit Dll zugreifen darf.

Einfach wäre bei allen 64-bit nachinstallieren, geht aber bei dem Kundenmenge schlecht.

Alles was ich im Netz finde ist nur Option, zugriff auf eine COM Bibliothek auszulagern (die 32-bit wäre), dann ginge es.

Aber da tritt nächste Problem, um die zu registrieren ist wiederum Adminrechte erforderlich. Was 90% Benutzer nicht haben.... dann kommt halt nächste Theater.

Weiß eine eventuell elegantere lösung?

Any CPU ist nicht garantiert 64 Bit. Es kommt auf den Prozess an.
Wenn der Prozess x64 ist, dann lädt JIT auch 64 Bit, wenn 32 eben 32 Bit. Wie der Prozess gestartet wird entscheidet dann zB. das .NET Framework anhand des darunterliegenden Systems.

x64 hat nicht überall Vorteile und ich kenn genug, die ihre Applikationen bewusst via x86 verfügbar machen, wenn sie keine x64 Vorteile haben.
Nur sagen, "wir wollen x64, weil wirs wollen" macht hier auch relativ wenig sinn.

Ich hör jetzt aus Deinem Text nicht raus, warum ihr bewusst alles auf x64 umstellen wollt.
Insofern dass ihr Any CPU fokussiert scheint mir, dass ihr es halt wollt, weil ihr es wollt - nicht weil es sinn macht. Im Gegenteil; der Faktor 32-Bit-Dlls spricht eigentlich dagegen.

Warum wir es brauchen ist ganz einfach:

Unsere Programme sind Speicher intensiv, viele Daten, viel Vorschau (PDF, Word), die 32-Bit hat bekanntlich Obergrenze von ca. 1GB, dann kommt "Out of Memory" und Feierabend. 64-Bit hat es nicht.

Dass AnyCPU unter 32-Bit Betriebssystem 32-Bit läuft ist mir klar, aber unter 64-Bit dementsprechend 64-Bit, das ist vorteil. Man muss nicht zwei Versionen kompilieren.

Dass AnyCPU unter 32-Bit Betriebssystem 32-Bit läuft ist mir klar, aber unter 64-Bit dementsprechend 64-Bit, das ist vorteil. Man muss nicht zwei Versionen kompilieren.

In deinem Fall aber auch eher ein Nachteil. - Wir hatten bisher immer die Regelung im Unternehmen unter AnyCPU zu kompilieren. Als unser Kundenstamm dann immer mehr Richtung 64bit Systeme gegangen ist, mussten wir aufgrund deren Lizensen für verwendete Reporting-Bibliotheken auch explizit auf x86 kompilieren. Das sollte jedoch kein Problem sein.

Im Zweifel bietet sich eventuell an, mehrfach Kompilierung durchzuführen? Das heißt, auf neue Systeme wo ihr die 64bit DLL habt, wird AnyCpu installiert, auf allen anderen x86.

..aber unter 64-Bit dementsprechend 64-Bit, das ist vorteil.

Nein, das ist ein Irrglaube. Unter x64 läuft eine .NET Anwendung mit Any CPU nicht zwangsläufig auch via x64.
Im Gegenteil: Any CPU Anwendungen laufen aufgrund der "prefer x86 process on x64 system" meistens weiterhin als x86. Sieht man am *32 Sternchen im Task Manager.

Ich sehe bei euch viel mehr Gründe gegen x64 und für x86 als andersrum.
Die Obergrenze 1GB unter x86 gibt es nicht. Die ist sogar thereotisch bei 3,25 GB. Das .NET Framework aber hat durch eigenen Overhead ein eigenes Limit unter x86, das irgendwo bei 1.8 GB erreicht wird.

Auch in x64 gibt es dieses Limit noch.
Es muss bewusst über die Konfiguration gcAllowVeryLargeObjects freigegeben werden. Denn wenn man das braucht, dann ist es in 99,9% schlechter Code, der das verursacht.

Das mit dem Kompilieren ist auch ein Irrglaube.
Ob die .NET Runtime etwas mit 32 oder 64 Bit ausführt, steht im Portable Header.
Mit Corflags kannst Du jederzeit den PE Header ändern.

Das mit dem Kompilieren ist auch ein Irrglaube.
Ob die .NET Runtime etwas mit 32 oder 64 Bit ausführt, steht im Portable Header.
Mit
> kannst Du jederzeit den PE Header ändern.

Option 32-Bit bevorzugen ist erst ab Framework 4.5 vorhanden.

Wenn ich AnyCpu kompiliere oder x64 ist es im Taskmanager in beiden Fällen kein zusatz (32 bit).
und in Ausgabe von VS 2015 bei Debuggen ist zu sehen das bei AnyCPU als auch x64 werden einige Bibliotheken aus C:\WINDOWS\Microsoft.Net\assembly\GAC_64 gezogen werden. Belegt das es 64x läuft.

Wenn ich richtig Microsoft deute:

Plattform

Dann ist es nur ZielPlatform, nicht mehr nicht weniger.

Das mit dem Kompilieren ist auch ein Irrglaube.
Ob die .NET Runtime etwas mit 32 oder 64 Bit ausführt, steht im Portable Header.
Mit
> kannst Du jederzeit den PE Header ändern.

Kleines Beispiel:

List<MB100> list = new List<MB100>();

        private void button1_Click(object sender, EventArgs e)
        {
            int i = 0;
            try
            {
                while (i < 1000)
                {
                    list.Add(new MB100());
                    i++;
                }
            }
            catch(Exception exp)
            {
                Text = exp.Message;
            }
        }

class MB100
    {
        byte[] _array = null;
        internal MB100()
        {
            int anzahl = 100 * 1024 * 1024;
            _array = new byte[anzahl];
        }
    }

Wenn ich Projekt x86 ausführe steig es mit OutOfMemory Exception bei 18 Elementen in der liste, also ca. 1,8 GB was Sie schon gesagt haben.

Wenn ich Projekt x64 oder AnyCPU ausführe, steig es bei 228 Elementen in der liste, also ca. 22 GB. Das ist schon unterschied.

Aber bei der Glaubensfrage was besser ist x86/x64/AnyCPU zu kompilieren.

Beantwortet es nicht, an sich, meine frage, ob es elegnatere möglichkeit gibt auf 32 Bit Bibliothek aufzurufen aus 64 bit anwendung.....

Du musst nicht mehrfach kompilieren, der Compiler setzt ein Flag, was festlegt, ob die .NET Runtime einen 32 oder 64 Bit Prozess startet.

Elegante Lösungen gibt es nicht, da das auf Betriebssystem-Ebene so festgelegt ist - siehe hier.

Das ist schon unterschied.

Du nennst es Unterschied. Ich nenne es...

Denn wenn man das braucht, dann ist es in 99,9% schlechter Code, der das verursacht.

Das Code-Beispiel von Dir ist auch nur dazu da, dass man die Größenverhältnisse darstellen kann.
Ich bleib aber erstmal aufgrund meiner Erfahrung dabei: euer Code könnte so umgesetzt werden, dass man das gar nicht braucht.

Das Code-Beispiel von Dir ist auch nur dazu da, dass man die Größenverhältnisse darstellen kann.
Ich bleib aber erstmal aufgrund meiner Erfahrung dabei: euer Code könnte so umgesetzt werden, dass man das gar nicht braucht.

Auf 64-Bit rät z.B. schon DevExpress, wir nutzen deren Komponente, die sind schon AnyCPU.
Das Programm an sich braucht vielleicht nicht so viel speichern 300-600 MB max, aber die Kunden kaufen sich 2-3 27 Zoll Monitore mit höherem Auflösung. Und schauen sich x-Dokumente meist gleichzeitig mit Zoom von 300%, dann muss es irgendwohin ob du es willst oder nicht....

Mit MemoryProfiler ist alles mögliche gescannt, keins Speicherlecks.

Also Fazit:

1. Ihr rät 2-Verzeichnisse "Normal" sprich x86 kompiliert, andere mit 64x Programmen. AnyCPU schlecht.
2. Gar auf x86 bleiben.
3. Meine variante, auf Grund kunden Gegebenheiten ist immer noch glaube besser AnyCPU.

.....
Sehe ich es richtig?

Hallo,

wenn du native DLLs als Abhängigkeiten hast, dann macht es keinen Sinn AnyCPU zu verwenden, außer du lädst diese dynamisch, so dass beide Architekturen funktionieren.
Die meisten Bibliotheken, werden als AnyCPU vorliegen, da diese eben keine nativen Abhängigkeiten haben und damit von x86 und x64 Anwendungen verwendet werden können. Das ist gerade das tolle, dass du eine reine .NET Anwendung eben nicht fix auf eine Architektur kompilieren musst.

Wenn dies nicht der Fall ist, dann kompiliere entweder als x86 oder als x64. Bei uns ist dies nur bei der .exe der Fall, da diese entscheident ist. Alle (.NET) DLLs sind AnyCPU.

Grüße
spooky

dann muss es irgendwohin ob du es willst oder nicht...

MIR ist das Latte. Wegen mir machste den Krempel auf AnyCPU und lebst mit der damit verbundenen Mehrarbeit in Zukunft.

Keiner sagt hier, dass AnyCPU schlecht ist. Spätestens Spook hat mit seiner Lösungsmöglichkeit den Sinn von AnyCPU beschrieben.
Es ist eben für Deinen Fall, als ausführende Anwendung, ungeeignet - von allen 3 Möglichkeiten die ungeeignetste, da Du externe Abhängigkeiten hast. Vermutlich wird Spooks Vorgehen auch für euren Fall passen, vermutlich. Aber da wurde Dir ja weiter oben ebenfalls schon empfohlen.
Zudem halt noch die falschen Erwartungen, die Du hier offensichtlich (wegen nicht ganz vollständigem Wissen, vermutlich - aber nicht weiter tragisch!) hast.

Auch von Speicherlecks hat niemand geredet, sondern von Logik, wann man Sachen im Speicher lässt und wann nicht.
Ist inhaltlich eher wie Performantere Alternative um 200.000+ Einträge im DataView durchzuscrollen? gemeint: macht kein Sinn alles zu Laden, wenn der Nutzer nur einen Teil sieht. Das exemplarisch als Beispiel.

Genug Lösungsmöglichkeiten haste ja mittlerweile bekommen.
Jetzt kannste Dich stur anstellen und selbst die Erfahrungen hier mit AnyCPU machen oder die Lösungsvorschläge hier mal ordentlich evaluieren 😉

Ich glaube die Diskussion ist völlig in die Falsche Richtung gelaufen.

Die Native DLL wird dynamisch gebunden, daher gibst kein Stress wieder bei AnyCPU noch x64/x86.

Ich stelle mich auch nicht stur, ich überlegen mir wie wir da besser verfahren können,
Problem ist, wenn es richtig installiert ist:

Windows 32-Bit, Fremdsoftware (Pervasive) 32-bit
Windows 64-Bit, Fremdsoftware (Pervasive) 64-bit. Da gibt'es null Probleme läuft bereits.

Sowohl x86, als x64 oder AnyCPU. Es wird richtige Native Dll dynamisch gebunden.

Es wurde aber immer 32-bit Installiert, egal ob 32 oder 64 Windows war. Warum ist jetzt irrelevant.

Unsere Software in 64 -bit Process erkennt es, aber es kann dann nicht auf 32 bit dll zugreifen, aus bekannten gründen.

Und das war eigentliche Frage von mir, ob es irgedwie geht ohne umweg über COM....nicht mehr nicht weniger