.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

.NET 2.0?
Hallo,

Tja, .NET 2.0 und welche Zielplattform?

Vielleicht hilft das.

oder kurz zusammengefasst: Versuche folgenden Eintrag in der app.config:

Gruß
fb

#3

Hi,
ist auf dem Zielrechner das .net Framework installiert? Und wenn ja in welcher Version?

Lg Knerd

#4

Hallo ,

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

Wie erstellst Du das denn genau ?
Werden die DLL’s mit ins Setup übernommen ?
Wie ist dein Setup aufgebaut. ?

Wie sind die Einstellungen bei der Installationsroutine ?
Brauch das Programm irgendwelche resoucen in der regstry etc ?

Wie genau gehst du vor , beim compilieren ?
welche einstellungen ? nimmst du auch die release version ?

und so weiter und so …

und warum du geld zahlst , nicht dafür das das programm magisch alles selber kann wofür mna bildung braucht und wer english nciht mächtig ist muss sich bei solchen produkten nicht wundern , haus baust du ja auch nciht via klick und kurz anleitung gell. Warum sollte das beim bau von Programmen und setups anders sein.

Aber mach erstmal Angaben die mehr sagen als du hast was angeklickt und das ergebnis gefällt nicht.

#5

Hallo

Eine sichere Antwort habe ich nicht, aber vielleicht ist es so ähnlich wie bei VB5, auch eine heute ältere Version:

Projektdateien, bzw, Programme, die einem Projekt zugehörig sind, aber noch keine .exe darstellen, laufen nicht ohne weiteres auf anderen Rechnern, weil die Projektdateien rechnergebunden sind. Irgendwo ist eine ID eingetragen.

Wurde jedoch das Programm zu einer *.exe bzw. *.dll(was fertiges eben) Datei kompiliert und alle notwendigen Dateien mitgegeben(siehe auch Hinweis Installationsroutine, Registrierung usw.), dann läuft das prima auf jedem Windows ab 95.

Diese Begriffe wie „Manifest“ und so manche mehr sind sehr wahrscheinlich Projektbezogen.

Abhängigkeiten: Wenn Dein Programm ein älteres .NET benötigt, sollte es trotzdem auf einer neueren laufen.
Und ganz zuletzt gibts noch die Möglichkeit ganz auf .Net zu verzichten. Ich hab da sowieso nicht ganz den Durchblick, was da so besonderes dran ist.

Im übrigen ärger ich mich auch über so manches.
Hinterher, wenn man es rausgefunden hat, möchte man meistens seinen Zorn aber lieber nicht geäußert haben, weil, man war dann doch nur etwas doof.
Zuletzt habe ich mich z.B. darüber geärgert, das ich kein schnelles Kamerafenster(Für Video, bzw. Webcam) in VB erzeugen konnte, obwohl VB da gar nichts selbst macht. Genau dasselbe, aber auch nicht unlösbar, die direkte Entschlüsselung des Video Datenstromes am USB-Port oder die Benutzung des entsprechenden Treibers.

MfG
Matthias

#6

hoi,

jaa der gute alte ärger mit dem deployment von (halb)nativen programmen :smile:
du solltest prüfen welche vc++ laufzeiten von deinem programm genutzt werden (sprich welches vc-redistributable wird aktuell von deinem compiler verwendet, NICHT von Visual Studio), und sicherstellen das dieses beim setup deines programmes mitinstalliert wird!
des weiteren ist es sinnvoll zu prüfen welche abhängigkeiten dein programm weiterhin nutzt (zb. MFC v.4, oder drittanbieter-dlls), diese MÜSSEN beim setup genauso mit ausgerollt werden, und entweder sich im lokalen ordner, sprich wo auch deine binary liegt, gesichert werden, oder was leider auch oft der fall ist, richtig korrekt beim ausrollen auf dem zielsystem registriert werden (regsvr32)! auch die zielplatform muss beachtet werden (s.u.)!

etwas anders ist es allerdings wenn du eine C++/CLI (.net) anwendung hast! hier kommt es GANZ STARK darauf an ob du „reines“ .net verwendest, oder ob du gemischten code hast (sprich native funktionen, oder die alte/neue MFC). beim ersten fall sollte es kein problem sein wenn einfach nur das passende ziel-framework installiert ist, bei letzterem MUSST du darauf achten das sowohl das fw, als auch die benötigten vc-redistributables auf dem zielsystem installiert sind, und diese bei bedarf nachziehen (lassen)! bei gemischtem code ist auch die zielplatform von interesse:

  • welches OS ist installiert,

  • welcher prozessor(typ),

  • 32, oder 64 Bit umgebung

nebenbei eine manifestdatei ist nur in verbindung mit der UAC (user account control) wichtig, und vor allem nötig wenn dein prog. erhöhte rechte benötigt.

so viel zur allgemeinheit, für mehr informationen wäre ein quelltext-ausschnitt nicht schlecht, genauso wie korrekte fehlercodes, und eventuelle debugging-informationen.

greetz, me