4. Diese Anwendung konnte nicht gestartet werden, weil die Anwendungskonfiguration nicht korrekt ist.

Diese Anwendung konnte nicht gestartet werden, weil die Anwendungskonfiguration nicht korrekt ist.

  • P

    Hallo,
    ich habe mit WinApi einen ganz einfachen Binär nach Dezimal Rechner programmiert. Dazu habe ich mit dem Ressourceneditor von VS.NET einfach eine schöne GUI mit modalem Dialog erstellt, also die Buttons und so erstellt und ihnen Namen gegeben.
    Diese Ressourcen-Namen habe ich dann im Source ganz normal dazu verwendet, um mit SetDlgItemText die entsprechenden Werte auszugeben.

    Das funktionierte perfekt, aber dieses Programm läuft mit der Konfiguration "Release" erstellt NUR auf meinem eigenen PC, auf verschiedenen anderen startet es nicht, sondern gibt nur die Meldung: "Diese Anwendung konnte nicht gestartet werden, weil die Anwendungskonfiguration nicht korrekt ist." aus. Obwohl die Fehlermeldung das nicht von sich gibt, vermute ich eine fehlende DLL oder sowas, die auf meinem PC durch VS.NET schon vorhanden ist.
    Das Programm läuft auf allen anderen PCs hingegen ohne Probleme, wenn ich als "Debug" erstelle. Aber dann steigt die Dateigröße der exe von 7KB auf über 400KB! Und das habe ich mir unter WinApi natürlich nicht gedacht, sonst hätte ich auch MFC nehmen können...
    Wieso funktioniert das mit der Einstellung "Release" nicht?
    Wäre nett, wenn ihr mir da weiterhelfen könntet :p
    ph4nt0m

    0
  • J

    Siehe:
    http://www.codeproject.com/useritems/vcredists_x86.asp

    Es gibt drei Möglichkeiten dies zu lösen:

    1. Du linkst Deine Anwendung mit der statischen CRT ("Statically linking the executables")
    2. Du installierst die CRT/MFC DLLs auf dem Zielrechner
    3. Du lieferst die CRT/MFC DLLs bei Deiner Anwendung mit. Dabei musst Du aber das richtige manifest der DLL mitliefern! ("Install a private assembly")

    0
  • P

    DANKE! 🙂
    Genau das war der Fehler. Ich habs jetzt statisch gelink (bei so einem mini Programm hat ein Installer und sowas keinen Sinn). Jetzt ist die exe etwas über 80KB groß. Dnekst du das ist in Ordnung, oder kann man da irgendwie noch mehr einsparen? :p
    ph4nt0m

    0
  • P

    So, ich müsste diesen alten Thread noch einmal nach oben holen. Entschuldigung, für den Doppelpost 😞
    Also, ich hab bisher doch immer noch VS2003 benutzt. Jetzt hab ich aber eine 180 Tage Version von VS.NET 2005 Pro und würde eigentlich gerne umsteigen. Allerdings wurde damals, wie ich geschrieben habe, die exe Datei mit 2005 immer ca. 80KB groß. Wenn ich aber 2003 nehme, dann hat dasselbe Programm nur 7KB, läuft aber auch auf anderen PCs.

    Meine Frage: Ist es überhaupt möglich, mit der 2005er Version genau so zu kompilieren, wie mit der 2003er? Oder muss ich diesen enormen Größenunterschied auf jeden Fall in Kauf nehmen? (dann bleibe ich nämlich lieber bei der 2003er.)

    ph4nt0m

    0
  • J

    Die VC8 CRT hat einige Security-Features mehr.
    Du kannst aber natürlich immer noch statisch linken; die EXE wird aber etwas größer (hab noch keine Vergleiche gemacht).

    0
  • P

    Jo, statisches Linken hab ich ja damals gemacht, sonst lief das ja erst gar nicht. Aber wies aussieht, werde ich dann lieber VS.NET 2003 benutzen. Den Unterschied finde ich schon beachtlich, das ist fast das 11-fache!
    Oder gibt es irgendeine Möglichkeit, mit der 2005er Version auf die "alte" lib von 2003 zu linken?

    ph4nt0m

    Edit: Anders gefragt: Da es ja an der neuen msvcr80.dll zu liegen scheint, gibt es eine Möglichkeit, mit VS.NET 2005 auf die msvcr71.dll zu linken, die ja bei XP schon vorhanden ist?

    0
  • J

    ph4nt0m schrieb:

    Anders gefragt: Da es ja an der neuen msvcr80.dll zu liegen scheint, gibt es eine Möglichkeit, mit VS.NET 2005 auf die msvcr71.dll zu linken, die ja bei XP schon vorhanden ist?

    Nein, gibt es nicht. Jeders VS bringt seine eigene CRT/ATL/MFC mit. Du könntest natürlich nur den Compiler tauschen... aber das Hilft Dir nicht viel, wenn Du noch die IDE verwenden willst...

    Ein kurzer Grössenvergleich eines "Hello world" Programmes hat ergeben:
    - VS2005 (Release, Multi-Threaded): 56 KB
    - VS2003 (Release, Multi-Threaded): 48 KB
    - VS2003 (Release, Single-Threaded): 26 KB

    Kann also Deine Beobachtung (11-fache) nicht so ganz nachvollziehen...

    PS: Die msvcr71.dll ist bei keinem OS vorinstalliert!!! Wenn es läuft, dann ist es Zufall, da es dann schon ein anderes Programm mitgebracht hat!

    0
  • P

    OK, erstmal vielen Dank für die Aufklärung. Dann wurde diese dll wohl wirklich von einem anderen Programm installiert. Wie sieht es denn mit der msvcrt.dll aus? Ich hab nämlich mal folgendes Codestück gefunden, dass für schön kleine Win32-Api Programme sorgen soll:

    // Default Routinen nicht statisch nutzen
#pragma comment( linker, "/NODEFAULTLIB:libc.lib" )
#pragma comment( linker, "/NODEFAULTLIB:libcd.lib" )
// ...sondern aus der MSVCRT.DLL holen
#pragma comment( lib, "msvcrt.lib" )
#pragma comment( lib, "kernel32.lib" )
#pragma comment( lib, "user32.lib" )

    Da wird anscheinend mit dieser msvcrt.dll gelinkt. Was hat es mit dieser auf sich? Ist das ein Ersatz für die msvcr71.dll? Könnte das obige Codestück dann vielleicht auch bei der 2005er Version helfen, damit ich nicht die msvcr80.dll haben muss?

    Viele Fragen, aber ich hoffe, dass du mir diese beantworten kannst. Wär wirklich sehr nett 🙂

    ph4nt0m

    0
  • J

    ph4nt0m schrieb:

    Da wird anscheinend mit dieser msvcrt.dll gelinkt.

    Nein, wird es nicht... die lib heisst immer gleich, nur verweist diese je nach VS auf die antsprechende CRT-Version...

    PS: Auch die msvcrt.dll ist nicht bei allen OS dabei!!! Erst ab W2k.

    ph4nt0m schrieb:

    Was hat es mit dieser auf sich? Ist das ein Ersatz für die msvcr71.dll? Könnte das obige Codestück dann vielleicht auch bei der 2005er Version helfen, damit ich nicht die msvcr80.dll haben muss?

    Wie gesagt: Ab VS2002 liefert jedes VS seine eigene CRT/MFC/ATL mit und die kann man nicht austauschen.

    0
  • P

    OK, wozu ist die msvcrt.dll dann überhaupt da? Aus Kompatiblitätsgründen, für Programme, die mit einem VS < 2002 kompiliert wurden? Bewirkt das obige Codestück dann überhaupt irgendwas im Bezug auf die Größe der entstehenden exe Datei?

    ph4nt0m

    0
  • I

    Hallo!

    Ich habe vor ein paar Wochen mit der Programmierung in Visual C++ begonnen und hatte das gleiche Problem und habe die Anweisung unter http://www.codeproject.com/cpp/vcredists_x86.asp#StaticLinking befolgt und habe unter Project -> Project Properties -> Configuration Properties -> C/C++ -> Code Generation -> Runtime Library die Option "Multi-Threaded DLL" auf "Multi-Threaded" umgestellt.

    Allerdings taucht jetzt beim kompilieren folgender Fehler auf: "Befehlszeile error D8016 : Die Befehlszeilenoptionen /MT und /clr:pure sind inkompatibel."

    Ich bitte um eure Hilfe.

    (Ich verwende Microsoft Visual C++ 2005 Express Edition)

    0
  • J

    Was für eine Hilfe erwartest Du?

    Die Lösungen wurde schon gesagt. Statisch Linken fällt in Deinem Fall weg, da sich dies mit /clr nicht verträgt. Somit bleibt nur das mitliefern der dll oder installieren dieser.

    0
  • ?

    Hallo

    ich habe das gleiche Problem mit VS C++ Express 2005 (mit /CLR).

    Ich habe die DLLs und die Manifest-Datei genauso mitgeliefert, wie im Abschnitt "Install a private Assembly" beschrieben.

    Wenn ich die .exe dann starte kommt jedoch eine Meldung, ich soll Framework .NET 2.0 installieren. 😞

    0
  • S

    Ich habe das gleiche Problem...

    exe von mein Kumpel laufen bei mir aber meine nicht bei ihn.

    Getestet mir der Startanwendung WinAPI, also diese mit dem Aboutfenster.
    Wir sitzten hier schon Stundenlang und testen, bisher ohne Erfolg.
    Für weitere Hilfe wäre ich sehr Dankbar.
    Gruß Silvio

    0
  • F

    Hallo,

    Ich bin der Kumpel 😃

    Also wir haben folgendes Problem:

    Ich kann seine Anwendung nicht starten! Wir haben auch schon die 3 Punkte die Jochen in dem Thema vorgeschlagen hat probiert, jedoch ohne Erfolg.

    Sein Projekt basiert auf der WinAPI. Was kann man noch tun?

    Gruß Funjoy

    0
  • ?

    Hi Leute.
    bin leider totaler anfänger ohne plan!!!!

    Ich habe auch dieses problem. habe schon alles versucht was ich so gefunden habe.
    bekomme auch den fehler "Die Befehlszeilenoptionen /MT und /clr:pure sind inkompatibel." wenn ich Runtime Library die Option "Multi-Threaded DLL" auf "Multi-Threaded" umgestelle.

    Alle rechner laufen mit XP-prof.
    Habe es nun auf vier rechner versucht. auf rechner 1 und 2 läuft das programm. 😕
    ich glaube das auf den beiden rechner (rechner 3 u. 4) auf denen es nicht klappt windows SP2 nicht installiert ist.
    "WINDOWS\Microsoft.NET\Framework\v2.0.50727" finde ich auf allen rechnern.

    Auf rechner 4 heist das windows-hauptverzeichniss nicht windows.
    habe deshalb unter projekteinstellungen\allgemein die pfade die mit "c:\Windows\...\...\system.dll" angegeben sind mit ".\%systemroot%" erweitert. ?????????
    außerdem kann ich an dem rechner auch keine systemeinstellungen ändern oder irgenwas installieren.

    wie kann ich die DLL´s mitliefern???

    aber auf dem rechner sollte das programm laufen...

    hoffe jemand kann mir helfen.....

    0
  • S

    Ich habe es so gelöst.

    Die <anwendung>.exe.manifest so geändert

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="win32" name="Microsoft.VC90.CRT" version="9.0.21022.8" processorArchitecture="x86" ></assemblyIdentity>
    </dependentAssembly>
  </dependency>
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" processorArchitecture="x86" publicKeyToken="6595b64144ccf1df" language="*"></assemblyIdentity>
    </dependentAssembly>
  </dependency>
</assembly>

    und dann eine Microsoft.VC90.CRT.mainfest mit folgenden Inhalt erstellt

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
 <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
    <assemblyIdentity type="win32" name="Microsoft.VC90.CRT" 
 version="9.0.21022.8" processorArchitecture="x86"></assemblyIdentity>
    <file name="msvcr90.dll"></file>
    <file name="msvcp90.dll"></file>
    <file name="msvcm90.dll"></file>
 </assembly>

    Wichtig dabei ist das die Versionnummern und du die DLL's im Programmverzeichis mitlieferst. Sollte die ...exe auf deinen Rechner nicht starten dann hast du irgendeinen Fehler in deiner Mainfest.

    0
  • ?

    bin noch nicht dazugekommen diese Lösung zu versuchen. habe es aber mitlerweilen auf einen anderen weg geschafft.
    wie gesagt, das .net Framework\v2.0.50727 ist auf allen rechnern vorhanden.

    nachdem ich dann doch vcredist_x86.exe auf den zielrechnern installiert hatte und einige .dll wie schon so oft beschriebn mit in das zielverzeichnis am zielrechner kopiert habe laüft das prog.

    aber, ich kann nicht auf jeden rechenr das vcredist_x86.exe installieren, außerdem habe ich bemerkt das es schon genügt sich als anderer benutzer anzumelden um die gleichen probleme wieder zu bekommen.

    anscheinend steht und fällt alles mit vcredist_x86.exe. wie kann man das umgehen???

    @Sillo:
    kannst du mir deine antwort viell. etwas für leihen verständlicher machen.
    was tust du da und was bewirkt das???

    mfg Andy

    0
  • D

    hallo erstmal,

    ich habe ein programm geschrieben und nun versucht es auf einem anderen rechner zum laufen zu bringen, dort kommt allerdings immer, das die anwendungskonfiguration nicht korrekt. nun wollt ich fragen, ob mir jemand sagen kann, was ich wo einbinden linken muss oder mit dem prog mitliefern, muss, sodass es auf anderen rechnern läuft. zur info: ich progge mit vc 2005.

    greetz 😕

    0
  • J

    Screencast: Static link to the C-Runtime to prevent vcredist and overcome “Application configuration” problems
    http://blog.kalmbach-software.de/2008/03/03/screencast-statically-link-to-the-c-runtime-to-prevent-vcredist-and-overcome-application-configuration-problems/

    0
Anmelden zum Antworten