erreur non implémentée lors de la signature C#

Question

Assemblée

J'ai essayé de signer un assemblage et d'obtenir cette erreur:

'Utils.Connection' does not implement interface member 'Interfaces.IConnection.BugFactory()'. 'Utils.Connection.BugFactory()' cannot implement 'Interfaces.IConnection.BugFactory()' because it does not have the matching return type of 'ThirdPartyLibrary.BugFactory'.

Cette erreur ressemble à un mensonge sale, sale! En Utils.Connection, j'ai cette méthode:

public new BugFactory BugFactory() 

Je ne pense pas que le mot-clé new est le problème parce que 1) l'enlever ne s'arrête pas l'erreur et 2) Je vais avoir la même erreur avec une autre classe qui implémente IConnection qui fait pas utiliser le mot-clé new. Mise à jour: si j'utilise override au lieu de new, je reçois cette erreur:

'Utils.Connection.BugFactory()': cannot override because 'ThirdPartyLibrary.ConnectionClass.BugFactory' is not a function

C'est parce que ThirdPartyLibrary.ConnectionClass.BugFactory est une propriété.

Il n'existe qu'une seule classe BugFactory, donc ce n'est pas un problème d'interface nécessitant un type de retour BugFactory différent de celui retourné par la méthode. Même si je marque explicitement ma méthode comme renvoyant ThirdPartyLibrary.BugFactory, j'obtiens toujours l'erreur lorsque j'essaie de nommer fortement la DLL Utils.

Cela peut-il être le résultat de ThirdPartyLibrary étant une ancienne bibliothèque COM qui n'est pas compatible CLS? Je n'ai aucun contrôle sur cette bibliothèque. Lorsque je fais pas essayez de signer l'assembly Utils, je ne reçois pas l'erreur d'interface.

Ma grande question est: comment puis-je signer cet assemblage?

Edit: voici ce que IConnection a:

using ThirdPartyLibrary; // The only using statement 
namespace Interfaces 
{ 
    public interface IConnection 
    { 
     ... 
     BugFactory BugFactory(); 
    } 
} 

Answer 1

problèmes Namespace/Version?

ThirdPartyLibrary.BugFactory pourrait être un autre type, si vous avez deux versions différentes de l'assemblage 3ème partie référencée en quelque sorte: une pendant la compilation et un autre lorsque vous vous/vérifier ..

Answer 2

Qu'est-ce que votre IConnection l'interface ressemble? Il semblerait que votre ThirdPartyLibrary ait un objet BugFactory et que vous ayez également un objet BugFactory dans votre projet ou dans une autre référence. Avez-vous essayé de changer à la fois l'interface et le type concret pour expliciter utiliser ThirdPartyLibrary.BugFactory comme type de retour pour cette méthode?

Answer 3

Je suis toujours suspect du mot-clé new pour cette erreur. Vous dites "Je ne pense pas que le nouveau mot-clé soit le problème car 1) le supprimer n'arrête pas l'erreur", mais vous devez garder à l'esprit que si votre méthode cache une méthode de base, le compilateur ajoutera new, même si vous ne le spécifiez pas, sauf si vous spécifiez explicitement override à la place.

Tout ce que le new explicite fait est d'empêcher un avertissement de compilateur (pas une erreur).

Existe-t-il vraiment une méthode pour masquer ou remplacer du tout?Que se passe-t-il si vous spécifiez virtual au lieu de new sur cette méthode. Est-ce qu'il compile? Est-ce qu'il erreur avec "aucune méthode appropriée trouvée pour remplacer?"

[Modifier en réponse à votre commentaire]

I get this error: "'Utils.Connection.BugFactory()': cannot override because 'ThirdPartyLibrary.ConnectionClass.BugFactory' is not a function." The original ThirdPartyLibrary.ConnectionClass.BugFactory is a property.

Je soupçonne que ce peut être la question. Vous remplacez une propriété par une méthode. En utilisant le nouveau mot-clé, vous masquez l'ancienne propriété à quiconque possède une référence à votre classe dérivée. Par contre, toute personne ayant une référence en tant que superclasse (celle dont vous héritez) verra l'ancienne propriété, et non votre nouvelle méthode. Pouvez-vous donner plus de code de la superclasse (ou de l'interface) avec la classe dérivée?

[Modifier en réponse à votre commentaire]

I'm trying to change the interface to have BugFactory be a property instead of a method

Le problème avec la nouvelle est qu'il semble un peu de magie, qui peut vous permettre de modifier les types d'arguments et renvoient des types, mais il est vraiment mal absolu.

Au lieu de changer les types pour tous les consommateurs du code, il ne le fait que pour les consommateurs qui sont lancés en tant que nouveau type prédominant. Cela vous met dans la position horrible où deux consommateurs à la même instance verront différentes signatures en fonction de la façon dont ils sont cast.

Voyez si vous pouvez identifier le code consommateur qui se plaint et réfléchissez à la nécessité de modifier davantage votre code pour prendre en charge les modifications de type. Aussi, y a-t-il la possibilité que vous essayiez de faire quelque chose qui soit "un peu un hack méchant"?

Answer 4

Il semble que vous ne faites que référencer la bibliothèque COM via la boîte de dialogue Ajouter une référence. Vous devez probablement créer un assembly d'interopérabilité principal pour la bibliothèque COM qui peut être signé. L'une des mises en garde de la signature d'un assemblage est que tous les assemblages auxquels il fait référence doivent également être signés.

Vous utilisez normalement le programme SDK TlbImp:

TlbImp yourcomlibrary.tlb//keyfile:yourkeyfile.snk primaire /out:yourcomlibrary.dll