Newtonsoft.Json de référence se plaindre sur Azure Fonctions

@JustInChronicles, je suis en ajoutant ce là une réponse à la référence, mais le comportement attendu devrait être que les dépendances de privé assemblages sont résolus, à partir de votre bin dossier, comme prévu.

J'ai mis en place le test suivant pour reproduire votre scénario:

• Créé une bibliothèque de classe simple avec un type simple qui utilise Json.NET pour sérialiser un objet et le retour de la chaîne JSON. Cette assemblée références Json.NET 8.0.3. Le résultat comprend l'Json.NET la version de l'assembly c'est à l'aide de
• Créé une fonction qui fait référence à ce type seulement avec un #r "DependencyWithJsonRef.dll" et renvoie le résultat produit par la méthode mentionnée ci-dessus
• Déployé DependencyWithJsonRef.dll et Newtonsoft.Json.dll (8.0.3) à ma fonction de bin dossier

L'invocation de la fonction produit le résultat attendu.

Ici est la fonction, pour référence:

#r "DependencyWithJsonRef.dll"

using System.Net;

public static string Run(HttpRequestMessage req, TraceWriter log)
{
    var myType = new DependencyWithJsonRef.TestType();
    return myType.GetFromJson();
}

Comme vous pouvez le voir, aucune référence explicite à indirects dépendances (Json.NET) requis.

C'est le résultat que j'obtiens:

{
    "Prop1":"Test",
    "Prop2":1,
    "AssemblyName": "Newtonsoft.Json, Version=8.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed"
}

Rapide remarque: Une chose que vous voudrez peut-être vérifier, surtout si vous avez mis à jour que la dépendance, tout en développant votre fonction est que la résolution de l'assemblée les résultats n'ont pas mis en cache. Un moyen sûr pour s'assurer que vous commencez avec une ardoise propre est d' (après le déploiement de votre fonction et assemblées) aller à Kudu et de tuer les non-scm processus w3wp pour voir si cela aide. Je serais curieux de savoir si ce n'est le truc qu'il y a quelques choses que nous pouvons pour améliorer ce si elle n'.

Après quelques essais et d'erreurs. J'ai trouvé que le problème était là.

@FabioCavalcante m'a donné un indice à l'aide d'un fichier de la base de référence,

#r "Newtonsoft.Json.dll"

Il ne fonctionne pas réellement. J'ai copié ces quatre fichiers Azure Fonctions' bin répertoire:

• AzureFunctionsSample.Services.dll
• AzureFunctionsSample.Services.pdb
• Newtonsoft.Json.dll
• Newtonsoft.Json.xml

- Il encore m'a donné la même erreur, même si je n'ai que le fichier de la base de référence. Puis, j'ai trouvé un autre fichier, AzureFunctionsSample.Services.dll.config qui définit réellement l'assemblée de liaison des redirections comme:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-8.0.0.0" newVersion="8.0.0.0" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
</configuration>

Après j'ai copié ce fichier de configuration à l'Azur des Fonctions de bin répertoire, il a travaillé!

---

Les Leçons Apprises

• Utiliser le fichier de la base de référence pour Newtonsoft.Json, #r "Newtonsoft.Json.dll", si votre assemblée a également une référence à elle.
• Assurez-vous que l'assemblée de liaison de configuration de la redirection existe dans Azure Fonctions' bin répertoire.

Corrigez-moi si je suis toujours mal.

Acclamations,