Creazione di una versione di rilascio: ancora problemi

[DesmoColo]

Ciao a tutti!
Vi posto di nuovo il mio problema, cercando stavolta di essere più preciso possibile.
Il mio scopo è quello di distribuire un progetto realizzato per l'università.Per farlo ho utilizzato.Net e Trolltech QT
Tenendo conto che un eventuale utente non nè QT ne .NET installato sul proprio pc ho pensato di realizzare un installer che pensasse a tutto lui (installare le ddl necessarie e le directory nel posto giusto). Mi hanno consigliato di usare inno setup per creare l'installer.
Molto probabilmente sono io che non sono capace ad usarlo, ma ho creato un installer e poi lo inviato ad un amico,ma a cui non funziona.


Ecco come è settato il mio ambiente di sviluppo:

Versione .NET: 2003
Versione QT:3.3.2

Include directories Path:
..,
C:\code\SDL-1.2.7\include,
C:\code\glew\include,
$(QTDIR)\include,
.,
d:\Programmi\Qt\3.3.2\mkspecs\win32-msvc.net


linker: additional dipendences:
qt-mt332.lib
qtmain.lib
opengl32.lib
glu32.lib
sdlmain.lib
sdl.lib
C:\code\glew\lib\glew32d.lib
kernel32.lib
user32.lib
gdi32.lib
comdlg32.lib
advapi32.lib
shell32.lib
ole32.lib
oleaut32.lib
uuid.lib
imm32.lib
winmm.lib
wsock32.lib
winspool.lib
delayimp.lib

Inoltre, se il file .exe creato si trova fuori della directory in cui viene creato. si apre e si chiude immediatamente.
Forse è perchè la working directory del debug è ".."?
Se è così, perchè l'exe non funziona in modalità di debug se tolgo .. dalla working directory?
Non esiste una via più semplice per creare un file eseguibile, (che so, un comando integrato in .Net che dica "crea la versione di rilascio")?
La ddl di QT che serve alla fine è una sola, Avrò copiato decine di ddl nell'installer fatto con inno setup, ma nisba. Mi hanno detto che l'uente dovrebbe installare sulla sua macchina il .Net framework: si può evitare questo? Se io mi metto nei panni di un utente medio, vedrei la cosa non di buon occhio (mi devo scaricare circa 20 mb per veder girare un programmino banale!)
Spero di essre stato abbastanza esauriente.
Grazie
DesmoColo

[71104]

La dipendenza dal framework dotnet non si può evitare, e secondo me questo sarà il suo più grave difetto; analogamente al Java, anche il .NET richiede una virtual machine, che è il framework, ma a differenza di una JVM, che è installata ovunque e (non credo) occupi tanto, il fw deve essere installato a parte, ed è pesantuccio assai... Windows 2000 chiaramente non ce l'ha, dev'essere installato a parte come aggiornamento, Windows Xp non mi ricordo se ce l'ha, Xp SP2 mi sembra che ce l'abbia, e Windows LH ce l'ha di sicuro.

Ora il punto è: detto francamente, credo proprio che Windows LH sarà un clamoroso flop (almeno in buona parte) perché è veramente TROPPO pesante (è assurdo richiedere 512 mega di RAM di requisiti MINIMI e 1024 CONSIGLIATI; avere risorse non vuol dire poterle sprecare), inoltre la storia dell'attivazione, già presente in Xp, è una baggianata e ha veramente rotto le scatole (finisce per infastidire solamente gli utenti onesti che hanno realmente pagato la loro copia); aggiungiamo anche che senza il nuovo file system WinFS Longhorn alla fine ha ben poco di veramente rivoluzionario (si diceva che avrebbe dovuto essere il più importante SO dai tempi di Windows 95... mmahhh!!! ).

Per questi motivi, e vista e considerata anche l'attuale situazione e lo screditamento (si dice cosi? ) che altre organizzazioni software (spesso open-source) stanno riuscendo a gettare su Microsoft (il caso IE-Firefox ne è un clamoroso esempio), posso facilmente immaginare che il numero di installazioni di LH sarà di molto inferiore a quello di XP, e di conseguenza il dotnet e il suo bel framework saranno accantonati per un bel po'; ovvio che sono tutte supposizioni.

Un vero peccato poi, perché se non fosse per la pesantezza del framework ufficiale, per il resto come interfaccia è una tecnologia molto ben disegnata: riesce molto bene ad essere semplice e potente al tempo stesso. Microsoft non si smentisce mai: dietro un'immagine e un modo di presentarsi perfetti e accattivanti a volte nasconde qualche imbroglio, e il mondo se ne sta un po' stufando...

Scusa il mio OT, e tornando alla questione principale hai due possibili scelte:
1) inserisci la dicitura ".NET framework" tra i requisiti della tua release
2) fornisci tu stesso le DLL necessarie durante l'installazione; non dimenticarti di fornire anche quelle caricate dinamicamente in runtime

[DesmoColo]

non posso cambiare ide?
mi potete dare dei consigli?
me ne occorrerebbe una che possa integrare qt.
al in teoria mi basterebbe ricompilare tutto con il nuovo ide e manda a quel paese .Net (che non e stata una mia scelta ma era imposta tra i requisiti del prof) non ci sono classi direttamente dipendenti da .Net, ho usato solo opengl

[71104]

perché cambiare ide? se hai usato il .NET suppongo che il tuo ide sia Visual Studio .NET, che è ottimo, solo che non devi usare il .NET
se il tuo è un programma che usa OpenGL, allora perché non usare il C o il C++? se non ti interessano gli aspetti + bassi della programmazione per Windows, e ti vuoi solo concentrare sull'architettura e sul funzionamento del programma, allora fatti aiutare da un wrapper delle API, come ATL o MFC, che sono due frameworks che non ti creano nessuna dipendenza (sono delle semplicissime librerie fatte da headers e sorgenti, tutto open-source e niente DLL esterne, come nel .NET); mi spiace, ma purtroppo non so cosa sia QT.
ciao