.NET Assembly Hell .NET auf fremden Computern

Computer: Software & Programmierung .NET & C#
#1

Hallo,

ich habe Visual Studio 2005.

Wenn ich ein .NET VC++ Programm erstelle, funktioniert es stets auf dem Computer, auf dem es kompiliert wurde.

ABER WEHE, ich versuche, das Programm auf einem anderen Computer zu starten!

Zu meiner großen Verärgerung über Microsoft funktioniert das fast nie!

Entweder kommt ‚Side-by-Side Konfiguration ungültig‘ oder, seit neuestem: ‚die Anwendung konnte nicht korrekt gestartet werden (Fehler 0xc000012d)‘

Ich bin sehr verärgert, dass nicht mal essentielle Dinge wie Programm starten funktionieren! Wofür zahle ich eigentlich hunderte von Euro für das Visual Studio?

Da war die sogenannte ‚DLL Hell‘ (s. Wikipedia) noch das geringere Übel!

Ich habe versucht, das Visual C++ 2005 Redistribution Packet auf den fremden Rechnern zu installieren, und zwar das Packet, das mit meinem VS 2005 mitgeliefert wurde. Kein Effekt, VC++ Programm startet immer noch nicht :frowning:
Auch Manifest-Datei erstellen oder Assembly-Versionen darin ändern hat nichts geholfen, oder hat zu anderen Fehlermeldungen geführt (sinngemäß: ‚Manifest ungültig‘).

Googlen hat auch nichts geholfen.

Wenn ich das Programm auf dem fremden Rechner kompiliere, funktioniert es nur dort und auch nicht auf anderen Rechnern.

Ich habe in der MSDN gelesen, aber dort sind meist nur 20+ seitige Artikel auf Englisch, die um den heißen Brei (wie kriege ich das Programm zum Laufen) herumreden, oder die Vorgehensweisen darin funktionieren nicht (Manifest-Datei erstellen hat auch nichts gebracht) oder ich verstehe das Geschriebene nicht.

Hat jemand eine SICHER Ahnung, wie ich die genannten Fehler verhindere?

#2

Hallo,

vom Gefühl (und von der Meldung) her würde ich trotz allem auf ein Versionsproblem mit dem Redistributable tippen. Auf jeden Fall auf dem Zielrechner das passende aus dem Internet installieren. Ein mit VC erstelltes Deployment sollte das auch erledigen (wobei ich nicht mehr weiß, ob VC 2005 diesen Projekttyp schon kannte…)

Die Fehlernummer 0xc000012d deutet auf Speichermangel hin und hat mit dem anderen Thema eigentlich gar nichts zu tun. Wo das nun herkommt ist auf die Dinstanz wirklich kaum zu sagen. Auf jeden Fall mal das Eventlog durchsehen… Was eine ordentliche Fehlernummer produziert sollte auch einen Eventeintrag schreiben.

Btw: Die DLL-Hölle hab’ ich nie so empfunden - wenn jeder „seine“ DLLs in „seine“ Applikationspfade kopiert hätte, wäre nie ein Problem entstanden…

Gruß

DampfHans

#3

Hallo DampfHans,

Die Fehlernummer 0xc000012d deutet auf Speichermangel hin und
hat mit dem anderen Thema eigentlich gar nichts zu tun.

danke für die Antwort. Du hast Recht, das zu startende Programm benötigt viel RAM. Auf meinem Windows-Vista Rechner lief es, wenn ich es unter Windows 7 starten möchte, kommt die besagte Fehlermeldung (0xc000012d).

Werde mal etwas zum Beheben des RAM-Problems versuchen…

#4

Nachdem ich die Auslagerungsdatei vergrößert habe, lässt sich das Programm nun ohne ‚Fehler 0xc000012d‘ starten!
Danke, du hast mir sehr geholfen!

#5

Hi,

sorry ich habe keine Erfahrung mit C++ unter .Net, schreibe alles in C#. Ist C++ vielleicht auch unter .Net unmanaged-code? Nutzst du direkte Aufrufe von Windows-API? Spricht etwas dagegen, deine Projekte auf die „voll-managed“ Art und Weise zu entwickeln? Ich hatte in meiner bisherigen Erfahrung praktisch keine Probleme, meine C#-Kompilate auf diverse Rechner mit diversen Betriebssystemen (Win 2000, XP, 2003, Vista, 7, 2008) zu deployen, das einzige was ich erlebt habe war dass vereinzelt die „richtige“ Version von .Net Framework fehlte, was sich durch einfaches Nachinstallieren lösen ließ.

Gruß Erich

#6

Hallo!

Du musst schlichtweg auf dem fremden Rechner alles installiert haben, was Dein Programm auch benutzt.
Nutzt Du Funktionen aus der C++ Runtime, dann musst Du das passende VCRedist auf dem Zielcomputer installiert haben.
Nutzt Du Klassen aus der .NET BCL, muss das passende .NET auf dem Zielcomputer installiert sein.

Auf Deinem Entwicklungsrechner wird all das (und noch viel mehr) mit VS mit installiert, deswegen funktioniert es dort.

Wenn Du dann ein Programm, das VC++ UND .NET nutzt, auf einem fremden Rechner aufrufst und es nicht funktioniert, es aber funktioniert, wenn Du es auf dem anderen Rechner kompilierst, dann vermutlich genau deswegen, weil Du den Compiler zusammen mit dem .NET SDK erst installiert hast und davor .NET auf dem Zielrechner nicht vorhanden war.

Je nach VS-Version (für die Express-Version brauchst Du übrigens keinen müden Cent auszugeben!) kannst Du Dir auch Setup-Projekte erstellen lassen, die es dann wirklich sehr einfach machen, ein Paket zu schnüren, das alles beinhaltet, um Dein Programm ohne große Aktionen auf einem beliebigen Rechner zum Laufen zu bringen.

In einem Manifest beschreibst Du nur (u.a.), von welchen anderen Komponenten Deine Anwendung abhängig ist. Das ist einerseits recht fehleranfällig und andererseits wird nur dadurch, dass Du dort angibst, welche Version von welchen DLLs Du gerne hättest, nichts installiert. Wenn Du also nicht Vorkehrungen triffst, sicherzustellen, dass alles Benötigte auch VOR dem Start des Programms da ist, wird es immer krachen.

Das war aber immer schon so. Binde ein beliebiges C++ Programm an eine Dll, die auf dem Zielcomputer nicht vorhanden ist und es wird Dir beim Aufruf abstürzen.

Gruß,
Martin

#7

Hallo Rainer,

so auf Ahnieb kann ich auch nur sagen, dass eine Runtime-dll fehlt.
Welche das ist könnte dir vielleicht das Prpgrämmchen „Dependency-Walker“ sagen. http://www.heise.de/download/dependency-walker.html
Wenn das Programm gestartet wird musst du deine funktionierende exe (oder auch eine dll) auswählen und es werden ALLE Abhängigkeiten aufgezeigt. Danach wiederholst du es auf dem nicht funktionierenden Rechner, und du solltest die fehlenden Dateien ausfindig machen.
Gruß
Thomas

#8

Ich benutze keine Win32 API calls.

Ist alles managed.

Habe das Programm inzwischen zum Laufen gebracht.

Trotzdem danke!

Gruß,
Rainer

#9

Freut mich dass du das Problem lösen konntest. Rein aus Neugierde: woran lag es?

#10

Die Fehlermeldung hatte nichts mit Assemblies zu tun, ich musste nur die Auslagerungsdatei von Windows vergrößern. Mein Programm kratz an der 2GB RAM-Grenze, das Maximum unter 32-bit Windows.

#11

Hallo Rainer,

erstmal finde ich Deinen Namen erstklassig ! :smile:
Leider kann ich Dir keine Patentlösung anbieten, da einfach zu viele Gegebenheiten oder Nicht-Gegebenheiten eine Rolle spielen könnten. Ich kann Dir nur aufzählen was ich in diesen Fällen immer getan habe:

  1. Erstelle immer ein Setup-Paket

  2. Überprüfe beim erstellen des Setup-Paketes immer die Programm-Abhängigkeiten. VS „übersieht“ hier und da einiges. Manchmal ist es z.B. erforderlich ActiveX-Komponenten fremder Hersteller manuell einzubinden.

  3. Trinke beim Coden keinen „Rainen“ Alkohol :smile:)))

Kannst mir ja mal Dein Projekt zukommen lassen. Vielleicht kann ich Dir dann besser helfen.

Bis dann …

#12

Hallo Ingo,

vielen Dank für deine Antwort und dein Angebot.
Ich habe das Problem allerdings schon gelöst.
Die Fehlermeldung kam nicht von den Assemblies
sondern weil die Auslagerungsdatei zu klein war
(mein Programm hat fast 2GB RAM allokiert).

Gruß und frohe Weihnachten!

#13

OMG !
Auf so einen Speicherfresser wäre ich nie gekommen. Naja, Hauptsache Problem gelöst.

Alles Gute …