NewtonSoft.Json of azure-function-apps dotnet

先简单记下摘要，日后更正补充。

按时间顺序故事是这样

1. 需求很简单，省去验证和配置的部分，基本流程是：定时调WebAPI获取数据->处理数据->存数据库。考虑用Azure Function App(以下简写AF)定时触发。
2. AF有两个版本：V1基于.NET Framework，V2基于.NET Core。因为依赖于.NET Framework的库 LibraryA，必须选V1（V2除了基于.NET Core的优势之外，依赖库的版本更高，依赖注入更自然，未来应当支持更多新特性）。
3. V1指定了NewtonSoft.Json = version 9.0.1, LibraryA则依赖于NewtonSoft.Json 10.0.3以上版本。因此造成了版本冲突。

尝试过失败的解决方案有

1. 在csproj文件中指定NewtonSoft.Json版本为10.0.3。
   结果： 编译可通过，执行时异常。
   细节： Module页面显示低版本的NewtonSoft.Json在AF触发时已经加载，随后执行到LibraryA有关的代码时抛出Could not load file or assembly or one of its dependencies异常（不在AF框架内执行时则无此异常）。这是官方论坛认为可以解决问题的方案，但很多开发者表示行不通，猜测是AF的bug，或者其与LibraryA具体实现相互作用的结果。
2. 为AppDomain.CurrentDomain.AssemblyResolve事件添加方法，指定加载特定程序集。
   结果： 直接加载LibraryA得到与方法一相同异常。
   细节： 随后尝试加载高版本NewtonSoft.Json并直接调用其中的方法，可以加载成功（Module显示两个版本都被加载），执行没有异常。所以猜测与LibraryA的实现有关。
3. 尝试AppDomain.CreateDomain，在新的AppDomain中加载程序集，使用完毕后Unload该AppDomain。
   结果： 反射后强转为Proxy的类型时出现了Unable to cast transparent proxy to type 异常。
   细节： Google之，没有找到极清楚的解释。此方法比较鸡肋，日后继续探究。

总结：

1. 需要更深入了解AppDomain的概念。方法一二似乎区别不大，方法二可以在入口类的静态构造函数中实现加载逻辑。第三种方法更合适的应用场景还需探索，CreateDomain后反射加强转时抛出异常在google上有一些复现的案例讲解。
2. 推测这三种方法的不适用可能有AF框架和LibraryA具体实现的原因，但由于它们两者都是黑箱，没有很多头绪继续探索下去。
3. 因为LibraryA的不能复用，基本放弃AF方案（除非LibraryA可以十分方便地编译成.NET Standard版本，转向AF V2）。AF V1不完全成熟，官方论坛推荐转向V2，并不承诺会长期维护V1（号称维护一年，但推测没有替代品之前微软应该不会轻易放弃V1）。