Discussion :

[StringBuilder]

Bonjour,

Je suis toujours en train de me battre avec les API de Google pour accéder au calendrier.

Je bloque sur un nouveau point : impossible de charger une assembly pourtant belle et bien présente dans mon dossier Debug

J'ai récupérer l'exemple VB de Google.
Je l'ai traduit tant bien que mal en C#.

Avec NuGet, j'ai lié à mon projet les API Google "Prerelease" Google.Apis.Calendar.v3 et toutes ses dépendances.

Ca compile bien.

Mais à l'exécution, ça me plante sur le chargement de l'assembly Microsoft.Threading.Tasks.dll

Je ne vois pas du tout pourquoi ça plante.

Est-ce que vous avez une idée ?
Je n'ai aucune erreur ni warning à la compilation.

[StringBuilder]

Pour plus de détails :

https://developers.google.com/api-cl...is/calendar/v3

J'ai recopié le code du programme d'exemple, et converti en C#.

Puis j'ai installé les API en tapant la ligne de commande qu'on trouve sur le lien "Google.Apis.calendar.v3" :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Install-Package Google.Apis.Calendar.v3 -Pre

Bref, j'ai rien fait de particulier...

J'utilise Visual Studio 2013.

J'ai essayé de compiler avec les target Framework 4, 4.5 et 4.5.1 sans aucun succès.

[Invité]

Bonjour StringBuilder,

C'est difficile de savoir comme ça sans bout de code ce qui ne va pas.

Tu parles de la référence "Microsoft.Threading.Tasks.dll"? Je ne connais pas cette référence dans le mode Windows desktop, il me semble que ça doit être une référence de Windows store app, car sous le framework normal, tout ce qui concerne les tâches sont répartis dans les assemblages "System.dll" et "mscorlib.dll"... Tu fais une application sous Windows Store App?

[StringBuilder]

Bonjour StringBuilder,

C'est difficile de savoir comme ça sans bout de code ce qui ne va pas.

Tu parles de la référence "Microsoft.Threading.Tasks.dll"? Je ne connais pas cette référence dans le mode Windows desktop, il me semble que ça doit être une référence de Windows store app, car sous le framework normal, tout ce qui concerne les tâches sont répartis dans les assemblages "System.dll" et "mscorlib.dll"... Tu fais une application sous Windows Store App?

Non, c'est une application "Desktop" (application console).
J'utilise "Visual Studio Express 2013 for Windows Desktop".

Après avoir tout pété mes packages, références et autres (en fait, je suis reparti d'un projet propre) j'ai toujours la même erreur, mais sur "Google.Apis.dll".

En pièce jointe, tu trouveras mon projet complet (attention, le fichier json d'identification est vide).

Une fois le projet chargé, il faut ouvrir la console NuGet :
- Choisir le projet "GoogleTools" et taper :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Install-Package Google.Apis.Calendar.v3 -Pre

- Choisir le projet "UpdateSync" et taper :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
Install-Package Microsoft.Bcl
Install-Package Microsoft.Bcl.Async
Install-Package Microsoft.Bcl.Build
Install-Package Microsoft.Net.Http

Ensuite à la compilation, il couine parceque log4net existe en plusieurs version. Il faut double-cliquer sur chacun des warning pour modifier le fichier app.config de chacun des projets pour forcer l'utilisation de la bonne version.

Ensuite, normalement, ça compile.
En revanche, ça plante direct quand on lance le programme car il n'arrive pas à trouver l'assembly Google.Apis

[StringBuilder]

Bon...

Super...

J'ai fini par faire marcher le truc en lançant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Install-Package Google.Apis.Calendar.v3 -Pre

Sur le projet principal (UpdateSync) aussi (je vois pas pourquoi j'en ai besoin mais bon, c'est pas ce projet qui fait appel aux assemblies...)


Par contre, une question en amène une autre :

Génial le navigateur qui s'ouvre et qui me dit que je vais bientôt mourir si je clique sur "ok".
Mais quand c'est pour faire une application backoffice, on fait comment ?

Mon programme doit tourner en tâche de fond, sur un serveur, sans la moindre interaction. Comment je peux dégager la question qui demande si j'autorise l'application à accéder à mon calendrier ?

-- Edit : tiens, si je lance une seconde fois, il me pose plus la question... est-ce que c'était du one shot ?

Franchement, les API de Google, c'est clair comme de l'eau de boudin !

-- Edit 2 : Bon, après reboot, il ne me repose plus la question... La question était là pour la forme, au tout premier appel, ou si elle risque de revenir de temps en temps ?

[Invité]

StringBuilder,
ça y est je viens de regarder ton projet.

Effectivement, dans le projet principal ça plante comme tu as dit.

En fait, c'est le genre d'erreur que j'ai déjà eu, et je vais te dire en fait ce qui s'est passé.
Il s'agit en fait d'un problème qui visiblement n'a pas été résolu encore pas Microsoft (sans doute parce que personne n'a pensé à leur remonter le pb) qui est la détection des assemblages "indirectes" au moment de la compilation pour recopier ce qu'il faut dans le répertoire de sortie. C'est assez tordu mais ça peut se voir assez facilement au niveau du symptôme.

Alors voilà pour le détail :
"UpdateSync", le projet principal, référence "GoogleTools" qui est l'une de tes DLLs. GoogleTools référence entre autres la DLL "Google.APIs". Directement, la classe "GoogleExtractor" fait appel à l'assemblage "Google.Apis.Calendar.v3.dll" qui lui-même fait appel à "Google.APIs"... Mais au moment de la compilation, studio ne l'a pas détecté! Du coup, studio juge sur le moment inutile de copier la DLL "Google.APIs" dans le répertoire de sortie de "UpdateSync" et donc lorsque, indirectement, l'assemblage "Google.APIs" doit être résolue, il ne la trouve pas.

Solution de contournement : pour que studio détecte la dépendance "indirecte" de "Google.APIs", il faudrait que tu fasses appel dans "GoogleTools" une classe de "Google.APIs". Ce que je faisais lorsque ça se produisait, c'est mettre une variable de type "Type" qui fasses appel à l'un des types de l'assemblage voulu...

Enfin, c'est comme cela que j'avais résolu le problème à l'époque... Mais j'ai essayé de faire la même chose avec ton projet mais ça ne copie toujours pas la DLL dans le rep de sortie de UpdateSync... Bizarre!... ça ne fonctionne pas cette fois... Je vais regarder un peu sur internet si je trouve qqch la dessus...

En tous cas, le problème est là...

[StringBuilder]

Pour le moment, j'ai "résolu" le problème en référençant les API de Google dans tous les projets de la solution.

C'est de toute façon nécessaire par exemple pour Microsoft.Bcl, donc autant le faire pour tout, comme ça je ne me pose plus de question (même si c'est crade).

En revanche, j'ai une tétrach*ée d'autres problèmes avec ces API.

En se basant sur le même projet, tu trouveras mes problèmes dans cet autre sujet.

Si tu veux bien prendre quelques minutes pour voir, je t'en serais reconnaissant.

http://www.developpez.net/forums/d13...n-utilisateur/

[Invité]

Au niveau de l'utilisation même des APIs Google je ne m'y connais pas mais en ce qui concerne la partie sur résolution des assemblages, c'est là que j'aurais pu au moins t'aider...
Sauf que la solution de référencer une classe de l'assemblage "Google.APIs" ça ne fonctionne pas cette fois... Bug de vs2013? Bizarre...

[StringBuilder]

Pour le moment, les V3 sont tellement buggée (béta) que je suis repassé sur les V2 (deprecated...)

J'ai plus le souci.

Je me repencherai sur la question quand les API v3 seront stabilisées.

Là depuis une mise à jour (sans release note) de ce matin, y'a plus rien qui marche (du tout)...

https://code.google.com/p/google-api...wner%20Summary

Et vu que personne ne répond même sur leur bug tracking...

[REZ_ZAK]

Bonjour,

J'ai pu importer tous les librairie via nuget mais par contre la librairie Google.Apis.Services ne la trouve pas.

Est ce que quelqu'un parmis vous a eu déja ce genre d'erreur Merci pour votre réponse.