Générer des DLL non bloquées

Version imprimable

13/07/2016, 16h58
Invité

1 pièce(s) jointe(s)

Générer des DLL non bloquées

Bonjour à tous,

je m'étais fais un projet de type librairie qui me sert dans mon projet Windev, chez moi, la librairie fonctionne sans incident.
Récemment, j'ai envoyé ma librairie à des hispanophones, chez eux, elle ne fonctionne pas, ils ont tous un grand nombre d'erreurs qui s'affichent.
L'un d'eux s'était renseigné sur ce dysfonctionnement et m'a dit que cela venait du fait que ma librairie devait être débloquée, comme vous pouvez le voir sur cette capture d'écran : Pièce jointe 215377

De mon côté, ce bloc d'information n'apparait pas, du coup, je me demandais s'il serait possible de ne jamais bloquer la librairie que je génère?
13/07/2016, 20h52
DotNetMatt

En gros il faut que tu "signes" tes assemblies pour qu'ils ne soient pas bloques par le CAS. Le CAS est un des modules de securite de Windows.

Tu trouveras un debut d'info ici : My application works from my local machine, but throws a SecurityException when I move it to a network share. Bon courage!
16/07/2016, 11h17
Invité

Bonjour, merci pour le lien mais je rencontre des soucis pour signer mon assembly.
Je suis aller dans les propriétés de mon projet, je suis allé dans Signature où j'ai créé un fichier snk, ce dernier se retrouve dans l'explorateur de solutions (physiquement, il se trouve dans la racine de mon projet).
Après, j'ai compris que je devais m'en servir pour justement signer mon assembly, chose que je n'arrive pas :
1- j'ai voulu mettre cette ligne de commande :

Code:

[AssemblyKeyFile("Romulus001.snk")]

mais mais AssemblyKeyFile est en erreur, disant qu'une déclaration est attendue
2- j'ai ajouté un lien externe vers l'invit de commande visual studio en suivant ce lien, j'ai tapé la ligne de commande suivante :

Code:

al /out:bin\Debug\Sunat_Firma.dll Sunat_Firma.netmodule /keyfile:Romulus001.snk

mais j'ai une erreur qui dit que Sunat_Firma.netmodule n'existe pas.
18/07/2016, 00h23
Invité

Bonsoir,

N'ayant pas réussi avec l'une des 2 solutions présentes dans mon dernier message, je me suis servi d'une autre façon qui a l'air de fonctionner (reste plus qu'à vérifier ce que ça va donner aux sud américains), je me suis servi de ce tutorial, bien qu'il était beuggé sur mon ordinateur, j'ai mis cela dans mon batch :

Citation:

del .\Signed\SUNAT_Firma.* /F
"C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\bin\ildasm.exe" .\SUNAT_Firma.dll /out:.\Signed\SUNAT_Firma.il
"C:\Windows\Microsoft.NET\Framework\v2.0.50727\ilasm.exe" .\Signed\SUNAT_Firma.il /dll /key=.\Romulus001.snk /output=.\Signed\SUNAT_Firma.dll

pause

j'ai une nouvelle dll qui est générée, sur mon ordinateur, je ne voix aucune différence par rapport à la version initiale.
18/07/2016, 05h31
clementmarcotte

Bonjour,

À tout hasard, tu as développé tes dll avec quelle version du Framework ?

Parce que, si tu as utilisé un Framework > 3.5, tu ne peux pas utiliser le runtime v2.0.50727, et probablement pas les outils liés à cette version-là.

J'avoue que si c'est cela, cela donne un message d'erreur bizarre sur Windows

Trois pistes non testées qui me passent par la tête:

1) Si tes correspondants Sud-Américains lancent ton application compilée, ou VS s'ils ont le code de l'application, en tant qu'administrateurs ? Des fois cela aide.

2) Si tu te crées un certificat de test et que tu l'appliques à ton code ? Tu peux ensuite l'appliquer à partir d'un des onglets du "MyProject". L'inconvénient c'est que ton certificat n'est valable qu'un an. Si jamais c'est suffisant, soit que tu recompiles tes dll tous les ans avec un nouveau certificat personnel, soit que tu envisages d'acheter un "Certificat Officiel" que tu vas devoir repayer périodiquement.

3 a) Ton problème pourrait aussi être dû à une procédure de sécurité de Windows (avec Windows 7, en tout cas. (Je n'ai jamais eu l'occasion de l'essayer avec Windows 8/8.1 et Windows 10)) qui empêche de modifier le registre si l'administrateur ne t'as pas donné l'autorisation de modifier la bonne clef de registre, ou d'ajouter des clefs. En principe Regedit devrait pouvoir te montrer les options de sécurité.

3 b) Aussi une vieille histoire qui fait penser à la tienne. À force de vouloir blinder Windows, c'était rendu que Windows bloquait les fichiers chm. Le déblocage commençait par un clic-droit sur le fichier dans l'Explorateur Windows, et ensuite cliquer sur l'entrée appropriée dans le menu contextuel. Mais là, cela fait trop longtemps que le je ne l'ai pas fait et je n'ai pas de fichier bloqué sous la main.

Et maintenant, je dois croiser les doigts ;)
18/07/2016, 09h46
Invité

Bonjour,

Citation:

Envoyé par clementmarcotte

À tout hasard, tu as développé tes dll avec quelle version du Framework ?
Parce que, si tu as utilisé un Framework > 3.5, tu ne peux pas utiliser le runtime v2.0.50727, et probablement pas les outils liés à cette version-là.

Je fais appel au framework 4.0 (pas la version 4.0 Client qui m'avait déjà posé pas mal de problèmes), pourtant, dans le batch, je fais bel et bien appel au runtime v2.0.50727 et tout s'était très bien passé, serait-ce un coup de chance? ou bien devrais-je faire appel à une meilleur version du runtime? J'avoue que je n'ai pas testé.

Dans le script présent dans le lien, la personne fait appel à la version 6.0A de l'exécutable ildasm.exe, or chez moi, il n'y est pas, est-ce que ça pourrait expliquer des choses?

Citation:

Envoyé par clementmarcotte

1) Si tes correspondants Sud-Américains lancent ton application compilée, ou VS s'ils ont le code de l'application, en tant qu'administrateurs ? Des fois cela aide.

Je ne génère pas d'application, simplement une DLL, mais je pourrais toujours essayer d'en parler.

Citation:

Envoyé par clementmarcotte

2) Si tu te crées un certificat de test et que tu l'appliques à ton code ? Tu peux ensuite l'appliquer à partir d'un des onglets du "MyProject". L'inconvénient c'est que ton certificat n'est valable qu'un an. Si jamais c'est suffisant, soit que tu recompiles tes dll tous les ans avec un nouveau certificat personnel, soit que tu envisages d'acheter un "Certificat Officiel" que tu vas devoir repayer périodiquement.

Dans les propriétés de mon projet, je suis allé dans "Signature", j'ai coché la case "Signer l'assembly", là, j'ai créé mon fichier .snk, pourtant, ma dll n'est signée, j'avais demandé à faire la vérification. Et l'appliquer comment dans le code? Je n'ai pas réussi à le faire avec AssemblyKeyFile.

Après, j'avais pensé à une autre solution qui me plait moyennement, ce serait de demandé à un sud américain de générer lui même ma dll avec le code source que je vais lui envoyer, normalement, le problème de sécurité devrait ne plus poser de problèmes, enfin je crois.
18/07/2016, 18h20
DotNetMatt

Citation:

Envoyé par romulus001

Après, j'avais pensé à une autre solution qui me plait moyennement, ce serait de demandé à un sud américain de générer lui même ma dll avec le code source que je vais lui envoyer, normalement, le problème de sécurité devrait ne plus poser de problèmes, enfin je crois.

En effet, mais tu peux simplement lui donner acces en lecture seule a ton gestionnaire de code source ;) Je dis ca car quand tu ecris "envoyer du code source", ca fait bizarre en 2016 :weird:

Sinon une autre solution c'est de changer la maniere par laquelle tu leur envoie la DLL. Par exemple, une DLL telechargee d'un site Web sera bloquee par defaut si le site n'est pas dans la liste des sites de confiance. Je pense que si elle est envoyee par mail, la seule solution c'est de la signer. Enfin, une autre facon de faire, c'est de la copier sur un partage reseau par exemple.
18/07/2016, 20h22
Invité

Citation:

Envoyé par DotNetMatt

En effet, mais tu peux simplement lui donner acces en lecture seule a ton gestionnaire de code source ;) Je dis ca car quand tu ecris "envoyer du code source", ca fait bizarre en 2016 :weird:

J'ai développé une application pour les sud américains afin de travailler sur un projet assez tordu, mon application donne des infos sur divers points et j'ai mis à disposition le code que j'ai mis dans ma librairie, du coup, il n'y a pas vraiment de secret pour eux.

Citation:

Envoyé par DotNetMatt

Sinon une autre solution c'est de changer la maniere par laquelle tu leur envoie la DLL. Par exemple, une DLL telechargee d'un site Web sera bloquee par defaut si le site n'est pas dans la liste des sites de confiance

J'ai mis un MSI sur mon compte dropbox où les gens peuvent justement installer l'application dont je mentionne dans ce présent post, et dedans se trouve la dll dont il est question, est-ce une bonne méthode de procéder?