Génération de fichiers sur .SVC-IIS échoue lors de l'utilisation de génération de code personnalisés RIAServices.T4

Question

J'ai une application Silverlight qui utilise une coutume DomainContextGenerator et une coutume EntityGenerator:

[DomainServiceClientCodeGenerator("MainCodeGenerator", "C#")] 
public class HrCodeGenerator : CSharpClientCodeGenerator 
{ 
    protected override EntityGenerator EntityGenerator 
    { 
     get { return new HrEntityGenerator(); } 
    } 

    protected override DomainContextGenerator DomainContextGenerator 
    { 
     get { return new HrDomainContextGenerator(); } 
    } 
} 

Cette classe et les générateurs référencés sont contenus dans une bibliothèque de classes référencée par le projet hôte de l'application Silverlight.

Lors du démarrage de l'application en 2012 VisualStudio tout fonctionne bien et quand j'ouvre http: / /localhost:12345/My-Namespace-MyService.svc dans un navigateur, je peux voir la page de destination du service. Lors du déploiement de l'application à l'IIS mais la génération à la volée des fichiers .svc échoue et lors de l'ouverture http: / /dev.example.com/My-Namespace-MyService.svc Je viens de recevoir un HTTP 404.

Après avoir supprimé la classe HrCodeGenerator du projet (en supprimant le DomainServiceClientCodeGeneratorAttribute ne fera pas l'affaire), tout fonctionne très bien.

Avez-vous des indices sur la raison de ce comportement et sur ce que je peux faire pour éviter que cela ne se produise?

Answer 1

J'ai finalement résolu le problème.

Les classes responsables de la génération du code client se trouvaient dans la même bibliothèque que les services eux-mêmes. J'ai déplacé ces classes vers le projet d'application Web qui est déployé sur le serveur. Je ne comprends toujours pas comment le code qui est exécuté au moment de la compilation et qui n'affecte que le côté client de l'application peut éventuellement influencer le comportement d'exécution du côté serveur de l'application. Je ne comprends pas non plus pourquoi le déplacement des composants vers un autre projet a résolu le problème. Mais comme un de mes collègues l'affirme: "Parfois, l'ingénierie ne se distingue pas de la magie ..."