-
Edité par XiouzanaxyXeon 25 juin 2020 à 4:46:53

Bonjour,

Si tu cherches a utiliser des API de microsoft, utilises soit les paquets Nuget soit les assembly (références). (quand tu es dans un projet, clique droit sur "références")

un fichier CPP, est un fichier C++, donc je ne comprends pas ce que tu dis.

La vidéo indique comment utiliser une librairie ayant une API C depuis du code C++, pas à partir d'un code en C#.

Je rejoins l'avis de mon VDD.

Merci pour vos réponse.

pour ce que est du projet en cours (donc ouvert) j'ai pus trouver nuget , projet --> installer les pakage nuget.

matosio a àcris

" assembly (références). (quand tu es dans un projet, clique droit sur "références") "

j'ai rien trouvé à ce sujet nulle part dans le soft. Je pense que tu utilise la version 2017 de Visual studio 

malgrés la longue liste des paket nuguet j'ai pas trouvé l'api recherchée. que dois je faire par exemple pour avoir accès à la l'API  GetipAddrTable

Pourquoi "sortir" de .NET ?

https://stackoverflow.com/questions/7885256/any-alternative-of-getipaddrtable/7969925#7969925

XiouzanaxyXeon a écrit:

matosio a àcris

" assembly (références). (quand tu es dans un projet, clique droit sur "références") "

j'ai rien trouvé à ce sujet nulle part dans le soft. Je pense que tu utilise la version 2017 de Visual studio 

Bon, vous cherchez les emmerdes, c'est parti.

Une librairie avec une interface C, c'est pas un assembly .NET, alors la "Add Reference", vous vous la mettez derrière l'oreille.

Documentez-vous sur comment appeler des fonctions C depuis un assembly .NET :

https://docs.microsoft.com/fr-fr/dotnet/api/system.runtime.interopservices.dllimportattribute?view=netcore-3.1

-
Edité par bacelar 26 juin 2020 à 14:20:59

Je ne réponds pas la dessus, je lui indique juste qu'un clique droit sur "références" dans un projet VS permet d'ajouter des assembly ainsi que des packages NuGet.

Mais en tout cas, merci pour l'information.

Merci pour votre aide, 

bacelar a ecrit:

Bon, vous cherchez les emmerdes, 

Si seulement c'était vrai :

Bon ce truc  est une horreur a utiliser apres bon cest pas moi code des api en C pour le systeme.

Matioso: a ecrit

 je lui indique juste qu'un clique droit sur "références" dans un projet VS permet d'ajouter des assembly

non pas dans le projet que j'ai choisi  si tu te fait un projet bureau (sans console), 

bon je vai ouvrire un autre poste  car j'ai pas mal fouiner déja , mai trouver l'api dans un *.net c est chaud vu la quandtiter d'information a lire

Merci de m'avoir lu  et de votre patience

-
Edité par Anonyme 26 juin 2020 à 18:03:56

Je comprends toujours pas pourquoi vous voulez absolument utiliser une librairie C toute pétée des année 1990 à la place d'une API .NET bien plus simple (à utiliser) et bien plus puissante.

Un projet "bureau", ça n'existe pas car il existe plusieurs framework différent dans ce "cadre".

Et le "Add Reference" existe dans toutes les variantes des framwork "Desktop".

barcelar a écrit:

Je comprends toujours pas pourquoi vous voulez absolument utiliser une librairie C toute pétée des année 1990 à la place d'une API .NET bien plus simple (à utiliser) et bien plus puissante.

.-

ben si tu me trouve comment obtenir les processus + les adress ip/port /protocol sur la machine je suis preneur et pour le moment j'ai rien trouver de complet:

et oui j'ai pas mal chercher:

IPGlobalProperties properties = IPGlobalProperties.GetIPGlobalProperties();
            TcpConnectionInformation[] connections = properties.GetActiveTcpConnections();
            foreach (TcpConnectionInformation c in connections)
            {
                Console.WriteLine("{0} <==> {1}",
                                  c.LocalEndPoint.ToString(),
                                  c.RemoteEndPoint.ToString(),
                                  c.State.ToString());
            }

Cela ne donne pas l'application  ... comme c' est dommage , il me manque quelque chose mai j'ai rien trouvé. donc c'est peut être vieux, mais c' est tout ce que j'ai trouvé.

Merci pour ta réponse (XiouzanaxyXeon   a un souci  de compte )

-
Edité par Anonyme 29 juin 2020 à 7:31:11

Je ne vois pas pourquoi vous trouvez "évident" que la relation socket/application soit une bijection (ou tout du moins une injection).

Une socket (protocole + @ip local + numéro de port local + @ip distant + numéro de port distant ) peut facilement être partagé par plusieurs processus.

Si vous êtes dans du bricolage :

https://bsmadhu.wordpress.com/2012/09/11/identifying-process-using-tcp-port-in-net/

IPGlobalProperties semble plus simple à utiliser (mais plus limité que WMI):

https://docs.microsoft.com/fr-fr/dotnet/api/system.net.networkinformation.ipglobalproperties?view=netcore-3.1

bacelar a écrit:

Je ne vois pas pourquoi vous trouvez "évident" que la relation socket/application soit une bijection (ou tout du moins une injection).

Une socket (protocole + @ip local + numéro de port local + @ip distant + numéro de port distant ) peut facilement être partagé par plusieurs processus.

Si vous êtes dans du bricolage :

https://bsmadhu.wordpress.com/2012/09/11/identifying-process-using-tcp-port-in-net/

IPGlobalProperties semble plus simple à utiliser (mais plus limité que WMI):

https://docs.microsoft.com/fr-fr/dotnet/api/system.net.networkinformation.ipglobalproperties?view=netcore-3.1

merci pour ta réponse pour ce qui est du brocollage sa passe par le cmd.exe et netstat.exe, deux programe qui risque de poser probleme pour pas mal de raison. l'interprosses est a mon avis pire que d'utiliser une dll qui a fait ces preuve

pour l'autre ben voici le code:

            IPGlobalProperties properties = IPGlobalProperties.GetIPGlobalProperties();
            TcpConnectionInformation[] connections = properties.GetActiveTcpConnections();
            foreach (TcpConnectionInformation c in connections)
            {
                Console.WriteLine("{0} <==> {1}",
                                  c.LocalEndPoint.ToString(),
                                  c.RemoteEndPoint.ToString(),
                                  c.State.ToString());
            }

il ne manque plus que le numero/nom du processus, il me manque égalment les connections en ecoute j'ai rater quelque chose ?

>deux programe qui risque de poser probleme pour pas mal de raison

On n'est tout à fait d'accord.

>les connections en ecoute

GetActiveTcpListeners ?

https://docs.microsoft.com/fr-fr/dotnet/api/system.net.networkinformation.ipglobalproperties.getactivetcplisteners?view=netcore-3.1

Pour le processus, comme ce n'est pas une "injection", il faudrait passer par quelques heuristiques.

bacelar a écrit:

il faudrait passer par quelques heuristiques.

Et que vu tu dire plus précisement ?

j'avais vu le lien , mai sans le proessus sa reste aux point mort 

j'ai vraiment passer du temp a trouver un moyen et rien de concret.

Une socket n'est pas liée à UN processus, comme un fichier n'est pas lié à un processus non plus.

Chaque processus peut avoir un handle sur une même connexion.

Après, c'est très souvent qu'une connexion ne soit utilisée que par un seul programme mais c'est pas toujours le cas.

-
Edité par bacelar 1 juillet 2020 à 14:45:07

Ok j'ai compris bon certain projet/soft existe donc c est possible reste à trouver comment c'est pénile de ne pas trouver une api qui fasse le job 

merci pour ta réponse, je laisse le post ouvert  dans l'attente d'un réponse sur la question..

Ces projet/soft font des assertions et utilisent des heuristiques pour trouver une relation entre une "socket/connexion" et un processus particulier.

Une API système qui utilise des heuristiques, c'est une API "peau de banane" car rien n'est certain avec une heuristique.

Bon, après un peu de recherche, le Kernel associe un processus à une connection comme "owner" de celle-ci.

Et comme je l'ai déjà indiqué, WMI dispose d'une API attaquable en .NET et c'est ce qu'il y a de plus puissant :

https://wutils.com/wmi/root/standardcimv2/msft_nettcpconnection/cs-samples.html

Pourquoi chercher ailleurs ?

bacelar a écrit:

Ces projet/soft font des assertions et utilisent des heuristiques pour trouver une relation entre une "socket/connexion" et un processus particulier.

Une API système qui utilise des heuristiques, c'est une API "peau de banane" car rien n'est certain avec une heuristique.

Bon, après un peu de recherche, le Kernel associe un processus à une connection comme "owner" de celle-ci.

Et comme je l'ai déjà indiqué, WMI dispose d'une API attaquable en .NET et c'est ce qu'il y a de plus puissant :

https://wutils.com/wmi/root/standardcimv2/msft_nettcpconnection/cs-samples.html

Pourquoi chercher ailleurs ?

Merci pour ta réponse, pour ce qui est du code il est compilable après avoir ajouter le paquet  en référence aux projet.

le souci c est que l'affichage boucle bien , mai aucun résulta avec ....  ???

voila ce que sa me renvoie:

AggregationBehavior :
AggregationBehavior :
AggregationBehavior :
AggregationBehavior :

etc etc

Je creuse cherche du coter de la requête mai ou ce trouve donc ces information ??

Ce ne sont que des exemples, qui datent, donc avec des réglages au niveau visibilité/cache qui peuvent avoir changé.

Je pense que vous devriez changer le code pour voir les propriétés disponibles de manière reflexive.

WMI est assez chiant pour ce qui est de la mise en cache de certaine propriété et pas d'autres.

Attention, il n'y a pas que la requête qu'il faut regarder, et comme en SQL, le "SELECT *" n'est pas gage de fiabilité.

Ca peut aider :

https://archive.codeplex.com/?p=wmie

je met le lien du soft pour ceux que sa interesse: https://github.com/vinaypamnani/wmie2/releases

Merci pour ta réponse bon je vais fouiner un peux c est nouveau pour moi les wmi 

voila je pense ce qu'il me faut : https://docs.microsoft.com/en-us/windows/win32/etw/tcpip-v0-typegroup1

-
Edité par Anonyme 2 juillet 2020 à 14:36:43