2018-8-20//Visual Studio 2017 pro//FBXSDK2015.1
1.想通过托管的方式，打包成插件给Unity(v5.6.6f2_64-bit)测试，失败，推测不可修复，因为Unity只支持安全的MSIL的托管模式，而这种模式打包FBXSDK是会报错的（Error C4956 此类型不可验证）。
2.关于托管模式的说明，此次顺便研究了一下关于托管模式，以及FBXSDK的普通C#封装（/clr 模式），是可行的，需要注意以下几个点。
3.如何打包出.net 3.5以下的托管DLL，相信使用过托管都会发现，无论是修改.vcproj还是怎样，既视看到引用那里写着版本2.0，打包出来后，使用Reflector能看到，还是关联着两个mscorlib和System，而且多半是4.0的，这可能对部分开发者来说很棘手，因为他们的目标的平台可能是.net 3.5（比如一开始我的想法是Unity Editor），那么需要注意以下几点：
3.1VS版本的选择，VS2008以后的版本，只要是托管的打包，就默认会包含.net 4.0的引用，怎么挣扎也没有用，所以，必须安装VS2008。
3.2FBXSDK版本的选择，如上所述，由于必须借助VS2008来打包，则必须有对应vs版本的libfbxsdk-md.lib或者libfbxsdk-mt.lib（因为你没有源码），所以，FBXSDK2015.1是最后一个支持VS2008的版本，如果你需要.net 3.5以下的托管，请选择这个版本。
3.3为什么一定要VS2008，可以不要吗，毕竟VS2008是个远古版本，先说说这次踩的坑，因为libfbxsdk-md.lib或libfbxsdk-mt.lib是一定要对应版本的ToolSet才能编译的，所以如果你需要.net 3.5以下版本的托管，必须要，要不然你能弄到v90版本的ToolSet估计也行，这个没有测试。
3.4而为了获得VS2008的平台工具集（ToolSet），必选先安装VS2008，然后会发现，没有。这个原因不明，不过解决办法很简单，再安装一下VS2010，这个工具集就出现了，百度一下可以找到这个答案。
4.其他要记录的没什么了，顺带一提，如果真的要给Unity中植入FBXSDK的支持，使用传统C++插件DLL的导出方法就行了（DLLImport 方法），如果托管目标在.net 4.0以上，那就没什么难点了，有很多现成工程可以借用，例如：
https://github.com/tramper2/ArcManagedFBX
https://github.com/garudaxc/FbxWrapper
5.附，关于用函数导出法制作FBXSDK插件DLL，需要注意，是要关联libfbxsdk.dll这个文件的，由于我没有测试，不清楚两个文件共同构成的插件Unity能不能用，所以，推测应当把libfbxsdk.dll打包进插件本身中，使用/MT打包模式，可以参考：
https://blog.csdn.net/u010983763/article/details/51559156
其中以小写“d”结尾的选项表示的DEBUG版本的，没有“d”的为RELEASE版本。大型项目中必须要求所有组件和第三方库的运行时库是统一的，否则将会出现LNK2005井喷。
/MT和/MTd表示采用多线程CRT库的静态lib版本。该选项会在编译时将运行时库以静态lib的形式完全嵌入。该选项生成的可执行文件运行时不需要运行时库dll的参加，会获得轻微的性能提升，但最终生成的二进制代码因链入庞大的运行时库实现而变得非常臃肿。当某项目以静态链接库的形式嵌入到多个项目，则可能造成运行时库的内存管理有多份，最终将导致致命的“Invalid Address specified to RtlValidateHeap”问题。另外托管C++和CLI中不再支持/MT和/MTd选项。
/MD和/MDd表示采用多线程CRT库的动态dll版本，会使应用程序使用运行时库特定版本的多线程DLL。链接时将按照传统VC链接dll的方式将运行时库MSVCRxx.DLL的导入库MSVCRT.lib链接，在运行时要求安装了相应版本的VC运行时库可再发行组件包（当然把这些运行时库dll放在应用程序目录下也是可以的）。 因/MD和/MDd方式不会将运行时库链接到可执行文件内部，可有效减少可执行文件尺寸。当多项目以MD方式运作时，其内部会采用同一个堆，内存管理将被简化，跨模块内存管理问题也能得到缓解。