Bonjour, 

On m'a transferé un projet contenant des bugs. Le but de ce projet est de pouvoir executer du Python depuis une applicaiton C# (WPF). Certaine des ses fonctions sont liée à notre application. Il est donc possible d'afficher un Popup dans l'application C# depuis le module de script. (Peut-être que mon thread serait plus adapter à la catégorie Python)

Je n'ai pas beacoup travailler sur ce projet et je dois maintenant le faire fonctionner. Je vais d'écrire un peu l'implémentation. Nous avons un script Runner en C# qui va simplement executer notre python.exe présent dans le dossier de la solution. La librairie protobuf va être utilisé. Elle me retourne toujours une erreure. 

File "C:\Users\Temp\tmp5561.tmp", line 2, in <module>
  response = MyApplication.ShowMessage("My Script", "Script start")
File "C:\my\solution\dir\Python38\lib\site-packages\myApplication\remote_control.py", line 12, in ShowMessage
  return cl.Services.getMyApplicationServiceStub().ShowMessage(myApplication.myApplication_service_pb2.ShowMessageRequest(title=title, content=content))
File "C:\my\solution\dir\Python38\lib\site-packages\grpc\_channel.py", line 946, in __call__
   return _end_unary_response_blocking(state, call, False, None)
File "C:\my\solution\dir\Python38\lib\site-packages\grpc\_channel.py", line 849, in _end_unary_response_blocking
   raise _InactiveRpcError(state)
grpc._channel._InactiveRpcError: <_InactiveRpcError of RPC that terminated with:
    status = StatusCode.CANCELLED
    details = "Cancelled"
    debug_error_string = "{"created":"@1664963894.275000000","description":"Error received from peer ipv4:127.0.0.1:50051","file":"src/core/lib/surface/call.cc","file_line":1070,"grpc_message":"Cancelled","grpc_status":1}"

Je ne sais pas si l'un d'entre vous a déjà eu ce problème? Le plus étrange et que mon popup s'affiche. Si je met du python "standard" il n'y aura pas d'erreur. Elle apparaît lors de l'appel à une fonction appartenant à mon application. Si je mets 2 appelle pour afficher le popup seulement un seul va s'afficher et la deuxième ligne ne sera même pas lue car à la fin de la première il y a une erreure comme mentionné.
Merci d'avance.

Faudrait voir la ligne 1070 du fichier source "src/core/lib/surface/call.cc" de l'application qui écoute sur le port 50051 de votre machine.

C'est fou ce qu'un simple message d'erreur peut indique.

Hello, j'ai oublié de préciser que sur 2 machines contenant le même fichier call.cc j'ai deux comportements différents. L'un n'a aucun soucis, l'autre a le problème décrit. Voilà la raison pour laquelle je n'ai pas preté plus d'attention a cette erreure.

Et ?

Cela ne change rien à l'analyse du message d'erreur.

bacelar a écrit:

Et ?

Cela ne change rien à l'analyse du message d'erreur.

Non c'est sûr mais cela ne m'a pas aidé. Le problème était que GRPC est très capricieux. J'ai du trouvé la bonne version de la dll System.Buffers. Pour ce faire j'ai testé toutes les versions.

>Le problème était que GRPC est très capricieux.

C'est un peu "light" comme analyse.

Le "caprice" est très certainement 'ligne 1070 du fichier source "src/core/lib/surface/call.cc"', ou en est une conséquence.

Si votre code ne fonctionne pas avec toutes les versions d'une Dll .NET, faites en sorte que seule la/les bonne(s) version(s) soi(en)t utilisée(s) via l'utilisation du manifeste .NET et de l'utilisation d'un .msi pour l'installation "correcte" du bidule.

Encore mieux, modifiez le code pour qu'il fonction avec toutes les versions de l'assemblies et ne pas profiter d'un effet de bord d'une implémentation particulière d'un assembly .NET.

Si c'est un "bug" dans un assembly, l'éditeur a déjà dû fournir un package de patch pour "isoler" les versions "boguées".