未发布 图表解决方案Nevron Chart for .NET发布v2017.1，支持Visual Studio 2017 Nevron Chart for .NET是一款业界领先的ASP.NET和Windows应用程序开发图表解决方案。该组件的设计从根本上满足您的绘图需求并将他们包装到一个良好的思想和一致的编程模型。不管您是否需要创建商业，科学，财经或演示图表应用程序，甚至是功能齐全，综合的商业智能解决方案， Nevron Chart将为您的Winforms和ASP.NET项目提供最终的数据可视化。
2017.1新版本在Nevron Chart for .NET中引入了很多新功能，以扩展最先进的.NET图表组件的数据可视化功能。
以下是2017.1版本引入的新功能的总结：
三元点系列
三元点系列显示三角坐标系中的点。 每个点由其总和为常数的A、B和C值指定。
三元气泡系列
三元气泡系列在三元坐标系中显示气泡。 每个气泡由其A、B和C值指定，其总和为常数，并且还具有确定其大小的第四个参数。
点系列
Point系列现在支持下拉线。 下降线是从点X，Y，Z值延伸到图表壁的线。 可选择的下拉线可以延伸到轴Min，Max值或用户指定的值（drop lines origin）。
浮子条连接器线和甘特连接器线
Float Bar系列现在支持相邻条之间的连接线开始/结束值。 此外，它还支持甘特连接器之间的条形结束值和一个或多个条形开始值。 此功能允许您轻松显示甘特图。
热图轮廓标签
热图系列支持注释轮廓。 用户可以指定轮廓值（高程）的格式。 沿着轮廓的标签之间的距离，标签方向是否必须遵循轮廓斜率，标签是否应剪切其注释的轮廓线等。
热图横断面
热图系列可以生成形成轮廓横截面的点列表，该列是通过将热图与由位于地图上的两个点定义的平面交叉定义的。
网格水平和垂直横截面
网格表面支持通过将表面与水平面或任意垂直横截面相交产生的网格表面轮廓（横截面）的提取。
注释拖动工具
注释拖动工具允许用户交互式拖动附加到不同图表锚点（数据点、比例坐标、图例项等）的注释。
范围选择拖动工具
范围选择拖动工具允许用户交互地拖动并调整范围选择对象的大小。
音量选择工具
此工具允许您交互地选择由四个平面（左、上、右和下）定义的3D体积，稍后可用于快速检查3D点是否包含在选择平面所包围的体积中。
面板缩放工具
该工具允许您以交互方式放大或缩小面板区域。
更好的WPF集成
Nevron Chart for WFP现在有更好的WFP集成。 控件也为WFP提供了许多新例子。
各种稳定性和性能改进
新版本功能修复了所有报告的问题，以及控件中的许多小型性能改进。
支持Visual Studio 2017
Nevron Vision for .NET现在提供对Visual Studio 2017的全面支持！【慧都十四周年庆预热开启！全场满额送七级豪礼，AppleMac笔记本电脑、iwatch、iPad等您来拿！】
活动时间：10月1日-10月31日
未发布 手机office办公——微软推出安卓手机端Office Mobile应用 微软于4月19日在中国北京首次发布全新的安卓手机端Office Mobile应用。微软此次将 Word、Excel、PowerPoint三者完美合一，为中国的消费者带来完整的移动办公体验。
微软大中华区副总裁兼市场营销及运营总经理康容表示：“微软一直倾听用户的声音，最大化满足 Office 用户的需求。我们十分欣喜地宣布，此次微软中国将携手行业领先的合作伙伴——华为，小米，腾讯和百度在中国联合首发全新安卓手机端 Office Mobile 应用，为移动办公带来更便捷的创新体验。”
全新安卓手机端 Office Mobile 应用以更小的存储空间，为用户带来包括 Word、Excel、PowerPoint 的一站式完整办公体验。同时，它还具有 Office 熟悉的外观和品质，以及专为中国用户设计的本地化创新功能，进一步为用户带来更多便利。
更小的存储空间，完整的办公体验
全新安卓手机端 Office Mobile 应用将以“三合一”模式全面集成 Word、 Excel、PowerPoint 三个独立应用中所有功能，用户可随时随时地访问、查看和编辑 Word、Excel 和 PowerPoint 文档。这款全新安卓手机端 Office Mobile 应用体积更轻盈，不仅减少了应用程序对手机内存的占用，而且简化了用户在不同办公软件之间的切换操作。以更小的存储空间，为用户带来完整的办公体验。
（全新安卓手机端 Office Mobile 应用将 Word、Excel、PowerPoint 三者完美合一）
熟悉的跨设备办公体验，多种格式完美兼容
全新安卓手机端 Office Mobile 应用为用户带来熟悉的跨设备办公体验。当用户使用不同设备对文档进行浏览、快速编辑或添加注释时，所有文档的格式和内容都会与原始文档保持一致。Word 界面整洁美观，文字、图片、页眉、页脚和图表都保持原有格式；无论是幻灯片中的动画、SmartArt 图形和形状，还是 Excel 中的图表和数据，都能够高保真呈现，完美兼容。此外，用户还可以在全新安卓手机端 Office Mobile 应用中浏览 PDF 格式文件，将文档转存为 PDF 格式并进行分享。
（支持图表、动画、SmartArt 图形和形状等功能）
本地化创新功能，文件轻松共享
微软Office一直重视中国用户的声音，通过本地化功能创新，为中国用户带来更好的移动办公体验。全新安卓手机端 Office Mobile 应用支持多种分享形式。除了以链接形式邀请他人编辑或查看文档，还可作为附件一键共享到邮件以及微信、QQ 等社交软件，更好地迎合中国用户的使用习惯。
（融合本地化创新功能，支持文件分享到微信、QQ 等社交软件）
从今天开始，中国安卓手机用户就可以通过华为应用市场、小米应用商店、腾讯应用宝和百度手机助手下载并体验全新安卓手机端Office Mobile应用了。同时，也可以通过微软官网下载安装全新安卓端 Office Mobile 应用。
转自（Microsoft）
未发布 MailBee.NET ObjectsL显示HTML/纯文本邮件教程（三）：显示带嵌入图片的邮件 MailBee.NET Objects是一款为创建、发送、接收以及处理电子邮件而设计的健壮、功能丰富的.NET控件。几行代码便可为应用程序添加E-Mail支持，简单高效。具备“必需”以及独特的功能，这些控件帮助开发人员简单快速地将复杂的电子邮件功能添加到他们的应用程序中。
本文主要介绍了显示带嵌入图片的邮件的代码示例。目前MailBee.NET Objects在线订购享75折优惠正在进行中，欢迎您下载试用版进行运用！
包含嵌入图片（以及嵌入式脚本、CSS表和其他对象）的HTML邮件无法在不修改邮件正文的情况下呈现。这是因为嵌入对象的URL被表示为CID（Content-ID值）而不是真实的URL。HTML邮件正文中的CID参考如下所示：（IMG SRC =“cid：picture1”）。这是图像源是Content-ID值等于“picture1”的邮件附件的示例。在呈现HTML正文时，必须显示该图像代替（IMG SRC =“cid：picture1”）标签。因此，在呈现邮件的HTML主体之前，开发人员必须用相应图像的真实URL替换所有这些伪URL。例如，你可以将所有嵌入对象的附件保存到磁盘，并将相应的CID引用替换为保存的附件URL。但是，手动执行此操作非常复杂。
幸运的是，MailBee具有显示带有嵌入对象的HTML体的特殊功能。GetHtmlAndSaveRelatedFiles方法将所有嵌入的对象保存到临时位置，用其虚拟路
径替换所有CID，并返回准备好的HTML主体字符串。Web应用程序开发人员可以使用此方法在浏览器中显示带有嵌入图片的HTML格式的邮件。
使用此方法时，还应将WorkFolder物理位置设置为保存嵌入对象的附件。此物理位置必须与传递给GetHtmlAndSaveRelatedFiles方法的virtualPath值
相匹配。
C＃
// We assume "C:\Inetpub\wwwroot" is a physical path to the location
// visible from Internet as "http://www.domain.com" (virtual path).
msg.Parser.WorkingFolder = @"C:\Inetpub\wwwroot";
Response.Write(oMsg.GetHtmlAndSaveRelatedFiles("http://www.domain.com", VirtualMappingType.Static,
MessageFolderBehavior.DoNotCreate));
VB.NET
' We assume "C:\Inetpub\wwwroot" is a physical path to the location
' visible from Internet as "http://www.domain.com" (virtual path).
msg.Parser.WorkingFolder = "C:\Inetpub\wwwroot"
Response.Write(oMsg.GetHtmlAndSaveRelatedFiles("http://www.domain.com", VirtualMappingType.Static,
MessageFolderBehavior.DoNotCreate))
因此，如果HTML格式的邮件体包含（IMG SRC =“cid：pic1”），并且该消息还具有ContentID（CID）“pic1”的嵌入式附件“picture.gif”，则调
用GetHtmlAndSaveRelatedFiles方法将替换“cid： pic1“与http://www.domain.com/picture.gif值。
如果你正在开发不使用虚拟路径的桌面应用程序，则可以将virtualPath设置为NonWeb值。在这种情况下，保存文件的物理路径将被用作URL。
C＃
msg.Parser.WorkingFolder = @"C:\Temp";
Response.Write(msg.GetHtmlAndSaveRelatedFiles(null, VirtualMappingType.NonWeb, MessageFolderBehavior.CreateOnly));
VB.NET
msg.Parser.WorkingFolder = "C:\Temp"
Response.Write(msg.GetHtmlAndSaveRelatedFiles(Nothing, VirtualMappingType.NonWeb, MessageFolderBehavior.CreateOnly))
换句话说，嵌入式图片将由文件系统上的物理路径表示，这些路径将被放置在相应HTML标签的SRC元素中。例如（IMG SRC =“cid：pic1”）将被替换为（IMG SRC =“file：/// C：\ Temp \ picture.gif”>）。
未发布 【更新】Windows网络守门人UserLock更新至v9.6，可通过Webhooks获取实时登录通知 UserLock是您的Windows网络守门人，它可以轻松实现有效的Windows和Active Directory网络用户访问控制策略，并严格执行。
UserLock v9.6更新内容：
通过Webhooks获取实时登录通知
UserLock客户现在可以配置自己的webhook URL（支持HTTPS和HTTP）并订阅所有会话访问事件。
Webhooks可以将更新直接推送到其他应用程序，创造了新的自动化可能性。它允许将实时登录通知集成到其他应用程序或平台中，并且可以基于特定访问事件创建自定义工作流程。
每个用户连接事件和登录尝试都将被发送到webhook URL，以及与该事件相关的所有用户和机器详细信息（IP地址、会话类型、时间等）。
webhooks和UserLock API有很多方法将UserLock的数据带入到其他应用程序中。
将粒度化登录数据输入到您的SIEM解决方案中，进行更精确的分析。
将粒度化的登录数据输入到考勤系统中，准确记录员工的工作时间和加班时间。
触发实时进程，例如在可疑登录事件之后阻止Active Directory中的用户。
将粒度登录数据与物理访问控制系统集成，以更好地控制员工进入。
支持Windows Server 2016
改进的代理分发数据
“代理分发”数据现在通过多线程机制进行更新。在许多受保护计算机的环境中，数据更新得更快。
具体更新内容：
新增
改进
试用、下载、了解更多产品信息请点击"咨询在线客服"
未发布 百度正式开源其RPC框架brpc 9月14日，百度正式在GitHub上基于Apache 2.0协议开源了其RPC框架brpc。brpc是一个基于protobuf接口的RPC框架，在百度内部称为“baidu-rpc”，它囊括了百度内部所有RPC协议，并支持多种第三方协议，从目前的性能测试数据来看，brpc的性能领跑于其他同类RPC产品。
brpc开发于2014年，主要使用的语言是C++和Java，是百度内部使用最为广泛的RPC框架，它经受了高并发高负载的生产环境验证，并支撑了百度内部大约75万个同时在线的实例。据了解，百度内部曾有多款RPC框架，甚至在2014年时还开源过另外一款RPC框架sofa-pbrpc。那brpc是在什么样的背景下诞生的？它有什么样的优势？又为何要开源？就这些问题，InfoQ记者采访了brpc负责人戈君。
Q：谈谈brpc的一些基本情况？什么时候开始研发的？经过了怎么样的迭代和升级？目前在内部应用情况如何？
戈君：brpc于2014年创建，在百度内部称为“baidu-rpc”。到目前为止，brpc一共进行了3000次左右的改动，现在仍在持续优化中，百度内的wiki上可以查询到每次改动的描述。brpc的主要语言是C++和Java，对其他语言的支持主要是通过包装C++版本，比如brpc的Python版包含C++版的大部分功能。
brpc目前支撑百度内部大约75万个同时在线的实例（不含client），超过500种服务（去年的统计，现在已不统计这类数据）。Hadoop、Table、Mola（另一种广泛使用的存储）、高性能计算、模型训练、大量的在线检索服务都使用了brpc。brpc第一次统一了百度内分布式系统和业务线的通信框架。
Q：为什么百度当时要研发brpc？
戈君：我们在实践中意识到，RPC作为最基础的通信组件，当时的百度已经不领先了。我当时的经理刘炀曾是Google的工程师，非常重视基础架构的建设，也愿意在这个方向投入资源。
我们在内部会更加深入地讨论这些问题。“好用”有时看起来很主观，但其实还是有据可循的，它的关键点是能不能真正地提高用户的效率：开发、调试、维护都要考虑到，如果用户效率真的被提高了，用户会想着你的，靠吹嘘或政令推广的东西得不了人心。我们创建brpc的初衷是解决百度业务所面临的实际挑战，同时也希望成为百度同学最喜爱的工具，哪怕离开百度也会怀念brpc。我们希望在提供了一个好用框架的同时，也展现了一种工作方法：注释怎么写，日志怎么打，ChangeLog怎么写，版本怎么发布，文档怎么组织，甚至对未来不在百度的同学的工作也有帮助，所以从这点来说brpc从一开始就是拥抱开源的。事实上，我们在口碑上做得还不错，brpc的wiki可能是百度内被点赞最多的内容之一。
Q：与其他的一些开源的RPC框架相比，brpc的优势是什么？
戈君：brpc主打的是深度和易用性。一方面我们没有精力像gRPC那样摊大饼，什么都做。另一方面我们也注意到gRPC（包括更早的Thrift）的深度和易用性并不够。技术方面的东西就是这样，看示例程序，文档非常牛逼，但实战中可能就是另一回事了，为什么各个公司都要造自己的轮子，一个隐藏原因就是表面高大上的东西在一些细节上让你无法忍受。
RPC真正的痛点是什么？是可靠性、易用性和定位问题的便利性。服务中不要出现不可解释的长尾，程序的可变项要尽量少，各种诡异问题要有工具支持快速排查。而这些在目前开源的RPC框架中做的并不好，它们大多看着很牛，但就是无法在自己组织中推广开来。回到前面那三点，brpc是如何做的呢？
- 可靠性。这一方面是代码质量问题，通过为brpc团队设立很高的招聘门槛，以及在团队中深入的技术讨论，我们确保了稳固的代码基础。另一个问题是长尾问题，这是设计问题，brpc其实包含了很多模块，其中的bthread是一个M:N线程库，就是为了更好地提高并发避免阻塞。brpc中的读和写都是wait-free的，这是最高程度的并发。技术细节请点击链接查看。
- 易用性。有种设计是什么选择都做成选项丢给用户，号称功能都有，但一旦出问题，则是用户“配置错了”。而且这样用户还非常依赖开发团队，没有开发团队的支持基本用不了，开发团队有足够的理由扩充团队。这么做其实非常不负责任，用户面对海量的选项也很难受。brpc对于增加选项非常谨慎，框架能自己做判断的绝不扔给用户，所有用户选项都有最合理的默认值，不设也能用。我们认为这对用户体验来说非常重要。
- 定位问题的便利性。这点其它开源框架目前做的都不好，正常使用是可以的，但出问题就麻烦了。这个问题在百度内部其实也很严重，brpc之前用户排查问题都要拉RPC同学一起排查，RPC框架对用户是个黑盒，用户根本不知道里面发生了什么。按我们的经验，基本每天都有几个用户在群里问server卡顿，client超时之类的问题，排查问题是常态，人手必然不够。时间长了用户就觉得你这个框架各种问题，人还拽的不行很少回他们消息。brpc的解决办法是给server内加入各种HTTP接口的内置服务，通过这些服务，用户可以很快看到server的延时、错误、连接、跟踪某个RPC、CPU热点、内存分配、锁竞争等信息，用户还可以使用bvar来自定义各类统计信息，并在百度的运维平台NOAH上汇总。这样大部分问题用户可以自助解决。其实我们去看也是看这些，只是会更加专业。内置服务的具体说明可以看这里。
Q：作为公司内部的RPC框架，在服务治理方面有什么考虑？
戈君：百度内部RPC使用非常广泛，基本都是RPC调用，一些产品线还会通过local RPC隔离工程框架和策略代码。这么多年下来，服务周边的系统也比较全面了：编译是BCLOUD，发布是Agile，服务注册和发现是BNS，认证是Giano，监控和运维是NOAH。在百度内部，brpc和这些系统做了比较紧密的绑定，用户体验是一站式的。虽然在开源版本中，这些结合大都删掉了，但用户可以根据自己组织中的基础设施来进行定制：交互协议，名字服务，负载均衡算法都可以定制。对于其中一些特别通用的，我们希望用户反馈到开源版本中来以方便所有人。
Q：之前百度还开源过sofa-pbrpc，brpc与它的区别是什么？
戈君：sofa-pbrpc也是百度开发的一个比较早期的RPC框架，属于sofa编程框架的一部分，在搜索有应用。brpc相比sofa-pbrpc有如下优点:
- 对协议的抽象更一般化，并统一了全百度的通信架构。bprc能容纳非常多的协议，基于Protobuf的，基于HTTP的，百度内的nshead/mcpack，开源的Redis/Memcached，甚至RTMP/FLV/HLS直播协议，brpc能逐渐地嵌入现有系统，而不需要彻底重构，但sofa-pbrpc则不具备扩展协议的能力。类似的，sofa-pbrpc也无法定制负载均衡算法，brpc默认提供round-robin、随机、一致性哈希，Locality-aware（局部性感知）四种算法，用户还能定制。
- 多线程质量更好。多线程编程是非常困难的，看起来简单的RPC遍布多线程陷阱，比如处理超时的代码可能在RPC还没发出去时就运行了；发送函数还没结束，处理回复的回调就被运行了；一个回复还在被处理另一个回复回来了，诸如此类。另外，一个异步RPC的回调里发起一个同步RPC会发生什么，带着锁做同步RPC会发生什么。这些问题我们都不能在sofa-pbrpc中找到满意的答案。
- 完备的调试和运维支持。解决这个问题的本质还在可扩展性，你如何让用户参与进来定制他们感兴趣的指标，为此我们设计了bvar，让用户能用比原子变量代价还小的方式自由地定制各种指标，用户能在浏览器上看到指标的变化曲线，或在运维平台NOAH看到汇总的监控数据。brpc还加入了大量内置服务方便用户调试程序，查看连接，在线修改gflags，追踪RPC，分析CPU热点，内存分配，锁竞争等一应俱全。
无需讳言，brpc在诞生之初和sofa-pbrpc在百度内部是有竞争关系的，但就像其他地方一样，这种竞争带来了活力。类似的，brpc和其他已经开源的RPC框架也是良性的竞争关系，在比拼谁能真正提高用户效率的过程中共同进步。每个用户都可以去对比代码、文档质量，接口设计，易用程度，扩展能力等，投出自己的一票。
Q：谈谈brpc的整体架构？
戈君：技术栈无外乎是从传输层垒到应用层，就略过不讲了，具体可以去看下开源出来的文档。brpc在架构上强调“在不牺牲易用性的前提下增强可扩展性”，比如brpc支持非常多的协议，在百度内部一个brpc server同端口可以支持二十几种协议，这对于服务的平滑迁移就非常好用。
Client端的协议也非常多，用户用brpc和bthread用得很爽，所以希望我们最好能统一所有的客户端，像对Redis和Memcached的客户端支持也是在这个背景下做的，这两个客户端比官方Client好用多了，感兴趣的读者可以去尝试一下。但这么多协议的配置非常简单，填个字符串就行了，比如HTTP就是把ChannelOptions.protocol设为“http”，Redis就是“redis”。Server端甚至不用设，它会自动判断每个client的协议，怎么做到的开源文档里也有。
名字服务、负载均衡也都可以定制。但为了对用户负责，我们也不鼓励“太自由”的定制，比如一点点需求的变化就要搞个新的，这时更需要想清楚本质区别是什么。这个事情我们在百度内的支持群里每天都在做，我们是开放的”乙方”，但我们也是严厉的”乙方”。
Q：brpc的性能如何？这么高的性能是怎么做到的？
戈君：性能是我们非常看中的一点，它和用户体验也是紧密联系的。好用但性能不行，或不好用但性能很牛，用户会很难受，我们不希望用户纠结。从另一个角度来看，在推广初期，我们要说服产品线用brpc靠什么？最直观的就是性能提升。而且这儿的性能不能停留在benchmark的图片上，而是能在真实应用中体现出来。开放出来的案例文档中或多或少都包含了性能提升，具体如下：
- 百度地图API入口
- 联盟DSP
- ELF学习框架
- 云平台代理服务
Q：为什么要将brpc开源？接下来在开源项目的迭代方面有什么计划吗？
戈君：因为马上还有不少依赖RPC的百度系统要开源啊。RPC作为最基础的组件，开源不仅仅是为了自身，也是为其它开源项目铺路，比如说我们马上还会开源基于brpc的RAFT库，搭建高可用分布式系统非常方便；以及使用brpc的bigflow，让流式计算变得很顺手。这些年百度对开源的认识也在不断加深，开源看似曝光了百度的核心技术，但带来的生态影响力更重要。从Apollo、PaddlePaddle开始，百度真的开始拥抱开源了。brpc的开源版和内部版很接近，只是去掉了对百度内部独有的一些基础设施的支持，我们在内网写的深入分析RPC技术细节的文档也都一并开源了，后续也会及时推送改动，请大家放心。这是一个活项目，不会拉个开源分支就不管了。
查看更多资讯>>>
未发布 多平台移动项目开发工具Elements发布v9.1，支持Visual Studio 2017 Elements是一款多平台移动项目开发工具软件，它包含Oxygene、C#、Swift三种编程语言和相关工具，并且提供这三种语言丰富的开发经验以及最新的Fire开发环境，极大的方便开发人员开发软件项目。
Fire
此版本是Fire最重要的更新。
性能改进
Fire在许多方面都进行了精简和性能改进。代码编辑器的响应速度更快，例如，在构建过程中CPU占用低。100％的响应一直是Fire的首要目标。Fire的大部分工作都是在极低功耗的12“MacBook”Adorable“上完成的，而我们的基准是，即使是最低端的硬件，Fire也可以使用，9.1版本更是如此。
互动调试控制台
Fire的调试功能在许多方面得到了加强，最出色是引入了新的交互式调试控制台。当你的应用程序进入调试器时，底部控制台视图现在允许你使用调试器命令提示符与调试器进行交互。
在使用LLDB的平台（如Cocoa和一些Island targets）上，你可以使用所有功能访问LLDB的完整命令界面；在其他平台上你会收到我们的edb提示，它提供必要的命令并将随着时间的推移而扩展。
Gradle References和EBuild
Fire（和Elements构建链）支持Java和Android项目中的显式Gradle References管理。Gradle References现在是项目的第一类成员，就像常规引用一样，它们可以通过“管理引用”表进行添加和更新。Fire还使用我们即将推出的EBuild工具链的技术预览。
Visual Studio中的Elements
Visual Studio是Windows上开发人员的主要IDE，Elements 9.1为Visual Studio带来了一些新功能和增强功能。
支持Visual Studio 2017
支持所有新的Visual Studio 2017 IDE。虽然没有Shell，Elements 9.1提供了与已安装的Visual Studio 2017集成，包括专业版、企业版和免费社区版。当然，VS2017中支持所有四种平台和三种语言。
Island
我们最初在9版中引入的新版本的Island平台也是这个版本的主要重点，有许多改进和增强和修复：
在Windows 10上运行和调试Linux应用程序
针对Linux的Island开发人员现在可以在Visual Studio、Windows 10 Creators Update或更高版本的本地机器上无缝地运行和调试他们的应用程序，只需点击“ 开始 ”或按F5。
新的子平台：ARM上的Android NDK和Linux
Elements 9.1中Island平台支持两个新的子平台。除了支持英特尔x64之外，Linux应用程序现在可以定位armv6和更高版本的CPU。你可以开发在嵌入式设备上运行的Island应用程序，从Raspberry Pi一直运行到Bare ARM系统等。
此外，我们还添加了Android NDK作为一个brad新的子平台，允许你使用NDK、Oxygene、C＃、Swift和Java语言创建Android应用程序扩展（或整个应用程序）。
支持Library
EUnit、Elements RTL和Delphi RTL都已经移植到了这个版本的Island，现在在使用这些（可选）库时，可以在所有三个平台上同步。
Libraries
Elements RTL
Elements 9.1正式引入了新的跨平台兼容性库Elements RTL。代替“Sugar”，Elements RTL是一个可选的库。无论你是在编写一个iOS应用程序并计划移植到Android，还是要创建Mac和Windows版本的桌面应用程序，Elements RTL可以轻松共享代码。
当然，Elements RTL也支持我们新的Island平台。
Delphi RTL改进
用于将Delphi代码移植到Oxygene的Delphi RTL兼容性库得到了改进。它现在基于Elements RTL，并且也适用于Island，使其成为跨所有Elements targets的真正跨平台。
未发布 VintaSoftTwain.NET SDK更新至v10.2发布，增加Visual Studio .NET 2017演示丨附下载
VintaSoft Twain .NET SDK v10.2更新内容：
新的Vintasoft.Twain.Web.Services.dll程序集，其中包含一个独立的Web服务，用于与TWAIN设备配合使用。该Web服务能够为任何.NET兼容的Web平台（例如ASP.NET WebForms、ASP.NET MVC、ServiceStack）快速创建其他Web服务。
新的Vintasoft.Twain.Web.Api2Controllers.dll程序集，其中包括用于在ASP.NET MVC 5中与TWAIN设备配合使用的Web API 2控制器。
已验证Vintasoft.Twain.js的JavaScript代码与jQuery 2和3的兼容性。
现在，VintaSoft Web TWAIN解决方案可用于安全的HTTPS服务器：
· VintaSoft Web TWAIN服务（VintasoftWebTwainService项目）可以同时提供HTTP和HTTPS请求。
· VintaSoft ASP.NET MVC TWAIN演示（AspNetMvcTwainDemos项目）可以在HTTP和HTTPS服务器上使用。
新增Visual Studio .NET 2017演示项目。
沪公网安备31011202009668号 | 沪ICP备13020027号-2