Version imprimable
Bonjour j'essaye de construire un programme win32/Com console avec visual studio community 2013 et j'ai un probleme de linkage :
error reading instrumentation file, taskchange.pgd not found.
je suis en release 64 bits.cela viendrait il des entetes pch ou une autre option de mon projet ? ce projet console inclue des librairies win32 et je linke avec les versions static de libc et libc++.
je pense que le probleme vient de la rubrique linker/optimisation
Vous avez activé l'option d'optimisation par profiling.
https://msdn.microsoft.com/en-us/lib...v=vs.120).aspx
Si vous ne savez pas ce que cela fait, ne l'utilisez pas.
merci bacelar, mais avec default ou/LTCG j'ai d'autres erreurs de link :
Pièce jointe 241817
j'ai l'impression qu il a mal pris en compte mon link avec libcmt.lib et libcpmt.lib
c'est ce programme d'exemple (le 1er) que j'ai modifié pour arriver à mes fins :
https://msdn.microsoft.com/en-us/lib...(v=vs.85).aspx
OK c'etais bien cela d'une part j'ai mis le /LTCG et en plus j'avais oublié le /MT comme j'utilise les libc et libc++ statiques...c'est resolu....
@Bacelar, en fait mon pb n'est pas completement résolu....peut on changer les settings d'une tache planifiée et notamment put_DisallowStartIfOnBatteries, grace à ITaskSettings ? car mon programme apparement ne semble pas le faire.
deja je fais cela :
ou taskName est un BSTR et argv[1] un wchar_t * puisque je suis en unicode pour tester si le nom de ma tache correspond à mon argv[1]Code:
2
3
4
5
ensuite je recupere le ITaskSettings* de la tache et je fais cela :
et j'execute ce programme dans une console en admin et cela me mets tache executée avec succes mais il doit manquer quelquechose car ces options (de ne pas demarrer la tache si sur batterie) sont encore cochees dans le planificateur de tache sur ma tache.....Code:
2
3
4
5
6
7
8
9
je viens de resoudre le pb pour les deux options de batterie en faisant un ITaskFolder::RegisterTaskDefinition .l'autre option ne fonctionne toujours pas...peut etre qu il n'aime pas le BSTR etl=NULL;
Je pense qu'il faut explicitement sauvegarder tes changements avec ITaskFolder::RegisterTaskDefinition(..., TASK_UPDATE, ...).
La documentation indique que NULL est autorisé :
https://msdn.microsoft.com/en-us/lib...(v=vs.85).aspx
Utilisez un débogueur et vérifiez systématiquement les valeurs de retour des fonctions.
merci bacelar et medinoc,je vais ressayer demain en passant directement NULL à la fonction (c'est avec mingw64 qu il faut mettre ce que j'avais mis BSTR etl=NULL; je pense car j'avais utilisé cela dans un autre programme win32/COM) mais comme là pour le moment j'essaye avec visual studio.....-en attendant que j'ai fait un .def pour mingw64 pour creer un .a ensuite-
j'ai tout essayé BSTR etl=NULL; et aussi en passant NULL et BSTR() à la fonction put_ExecutionTimeLimit, et à chaque fois elle me renvoie S_OK vu le test que je fais mais "arreter la tache si elle s'execute plus de trois jours" est toujours coché dans le planificateur des taches (les deux options de batterie sont bien decochees par contre, donc cela fonctionne pour la batterie)
OK ce probleme est resolu la doc de microsoft est à moitié correcte :ils disent de passer NULL à la fonction ou de passer L"PT0S" en fait NULL ne fonctionne pas mais L"PT0S" fonctionne.ce pb là est resolu.
derniere question: tant que j'utilise visual studio pour cela, j'aimerais savoir si cet executable utilisant des lib win32 et les libc et libc++ linkées statiquement a besoin quand meme des redistribuables microsoft ou d'autres choses pour fonctionner ou s'il peut fonctionner en stand alone ?
oui apparemment il fonctionne sur un windows vierge.
Ok, la documentation est piégeuse, effectivement.
NULL=> Valeur par défaut => 3 jours
infini <= 0 <= L"PT0S"
Citation:
les libc et libc++ linkées statiquement a besoin quand meme des redistribuables microsoft ou d'autres choses pour fonctionner ou s'il peut fonctionner en stand alone ?
Un Windows "vierge", cela ne veut rien dire de vraiment concret. (Windows Update, surcouche EOM du constructeur, etc...)Citation:
oui apparemment il fonctionne sur un windows vierge.
Le truc du "stand alone", ce n'est qu'un miroir aux alouettes. Vous avez besoin, au minimum, d'un énorme truc qu'on appelle l'OS, et qui change de version plusieurs fois par an.
Prenez la peine de faire installateur MSI avec ce qui est nécessaire à l'application, c'est vraiment quelques minutes, pas plus.
Pour les Dll, si votre IDE, ne les gèrent pas correctement dans un projet de déploiement, vous en aurez la liste exhaustive avec dependency walker (http://www.dependencywalker.com/)
merci bacelar,j'ai essayé dependencywalker dessus.
en fait ce programme est ajouté à ceux d'un setup d'une application faite avec Qt et mingw64 (c'est pour cela j'aurais prefere le faire avec mingw64 mais bon pour le moment on utilisera la version visual studio).j'en ai besoin car le programme schtasks de microsotf n'est pas complet et lorsque on cree une tache planifiee avec, elle est cochee pour s'arreter au bout de trois jours et si l'on est sur batterie,ce que je ne veux pas,donc c'est pour cela que j'ai fait ce programme additionnel qui s'execute lors du setup (fait avec inno setup) dans un batch et decoche ces trois options dans la tache planifiée crée....
Par contre pour le moment ce programme additionnel est construit pour le moment avec le sdk win 7.0A (donc je suppose de windows 7) et idealement comme ces options de tache planifiées sont a partir de windows vista, il aurait fallu le compiler avec le sdk win 6.0 mais j'ai des problemes dans les includes du sdk 6.0....(ca me mets une erreur sur NMHDR dans Prsht.h (l.667)dans le sdk 6.0 et j'avais essayé en incluant dans ce fichier WInUSer.h mais j'ai toujours l'erreur)
j'ai trouvé un sdk 6.1 pour vista et 2008 et je vais essayer avec....
Bon probleme definitivement resolu : en definissant la constante WINVER en plus de WIN32_WINNT et utilisant le sdk windows 6.1 ca build et cela fonctionne sans probleme
Vous êtes sûr que l'option /XML ne permet pas de faire le nécessaire ??? :weird:Citation:
.j'en ai besoin car le programme schtasks de microsotf n'est pas complet
Mais bon, on a toujours un meilleur contrôle des erreurs en utilisant les API Win32 qu'en gérant les valeurs de retour des exécutables dans un BATCH.
Il est assez facile et pas trop pénalisant pour un petit utilitaire de ne pas avoir de dépendance vers les Dll du Redistribuable Visual C++. OK.
Dependency Walker permet de voir si on n'a rien oublié dans les réglages pour supprimer ces dépendances.
Un SDK n'est pas associé à un système en particulier !!!Citation:
le sdk win 7.0A (donc je suppose de windows 7)
Effectivement, souvent, lors du la mise sur le marché d'un nouvel OS, un nouvel SDK est publié avec les nouvelles fonctionnalités du dit OS (en plus de toutes les autres fonctionnalités disponibles sur les autres OS).
MAIS, c'est la nouvelle version du seul et unique SDK, elle "fonctionne" avec tous les OS précédents, AUSSI.
Vous devez spécifier la plateforme cible de votre programme avec les constantes de compilation WINVER et WIN32_WINNT, quelque-soit le SDK utilisé.
Les versions suivantes du SDK, en plus d'ajouter les nouvelles fonctionnalités d'un OS ou même d'un Service Pack, corrigent souvent des bugs et autres problèmes.
Utilisez toujours la dernière version du SDK, en spécifiant les constantes de compilation WINVER et WIN32_WINNT correspondant à votre plateforme cible.
