[VS2005] Libraries in VS2005 onmogelijk?

[DieterVDW]

In VS2003 was het toevoegen van gecompileerde code erg eenvoudig.
Gewoon ervoor zorgen dat je dezelfde versie van de CRT gebruikte, en dan kon je de gecompileerde .lib gewoon includen in andere projecten zonder enig probleem.

In VS2005 is de situatie blijkbaar heel wat ingewikkelder.
Ik heb een unmanaged C++ project, waarmee ik een library creëer.
Een ander project maakt gebruik van deze library.
Op mijn machine werkt dit perfect (zoals dit in VS2003 werkte).
Het 2de project is openbaar en geef ik door aan andere mensen, samen met de library uit het eerste project. De code uit het eerste project moet verborgen blijven.

Deze aanpak werkt echter totaal niet meer in VS2005.
Het project compileert én linkt perfect, maar het programma kan niet uitgevoerd worden.
De gebruiker krijgt de foutmelding:

Unable to start program 'programma'.

This application has failed to start because the application configuration is incorrect. Review the manifest file for possible errors. Reinstalling this application may fix this problem. For more details, please see the application event log.

Ik heb al uitvoerig gezocht naar de oorzaak van dit probleem. Dit wordt veroorzaakt door een nieuwe manier van linken met de CRT. Zie ook de volgende pagina:
http://www.codeproject.com/cpp/vcredists_x86.asp

Ik heb al alle oplossingen die voorgesteld worden op die pagina geprobeerd. Zelfs statisch linken werkt niet. Zelfs als ik de library file op de machine waar de applicatie zal worden uitgevoerd aanmaak, dan nog krijg ik de bovenstaande fout.

Hoe los ik dit probleem op? Het moet toch nog altijd mogelijk zijn om gecompileerde code te verdelen aan derden (cfr. de oude VS2003 manier)?
De gebruikers werken wel in Visual C++ 2005 ipv Visual Studio, maakt dit iets uit?

[eek]

'For more details, please see the application event log.'

Staat hier nog iets nuttigs in?

[whoami]

-> DTE

De code uit het eerste project moet verborgen blijven.

offtopic:
Als je geen obfuscater gebruikt, is die .NET code minder 'verborgen' dan je denkt.De IL is makkelijk te de-compilen; dat kan je makkelijk zien dmv .NET reflector

[ Voor 95% gewijzigd door whoami op 27-02-2007 16:19 ]

[DieterVDW]

Ondertussen zijn we al een stuk verder met het probleem.
De library was gegenereerd met de runtime versie 8.0, waardoor het totale programma niet wil uitvoeren als runtime versie 8.0 niet beschikbaar is, zelfs al is het programma zelf gecompileerd op een computer waar enkel versie 7.1 beschikbaar is.
Nu hebben we het probleem dus opgelost door de library te genereren voor runtime versie 7.1.

Het volgende probleem was dat het programma niet meer wil werken op een computer die enkel over versie 8.0 beschikt. Dit probleem werd veroorzaakt door het gebruikt van de /LTCG switch (Link Time Code Generation) bij het aanmaken van de library (staat blijkbaar standaard aan), die de backwards compatibilitie met versie 7.1 verhinderde.

Het probleem is dus eigenlijk opgelost.

Is er trouwens een manier om op een machine met runtime 8.0 het gebruik van een lagere runtime af te dwingen, voor compatibiliteitsredenen?

[DieterVDW]

whoami schreef op dinsdag 27 februari 2007 @ 16:17:
-> DTE

[...]

offtopic:
Als je geen obfuscater gebruikt, is die .NET code minder 'verborgen' dan je denkt.De IL is makkelijk te de-compilen; dat kan je makkelijk zien dmv .NET reflector

Het is een unmanaged C++ project, dus geen IL.
En als iemand de moeite doet om de assembler te reverse-enginieeren, dan mag 'm voor mijn part de code weten .