<Win10开发>UWP使用.Net Native编译时遇到的一些问题。

  最近开始尝试把WP8.1 Runtime的项目升级成Win10 UWP,我用的方法没什么技巧性,就是直接复制文件和代码到新建的UWP项目。结果是后台代码未经修改,全部正常运行。但是UI控件的布局有些偏移,需要微调。这和“Win10 UWP架构是8.1 Runtime的超集”的说法吻合,所以大家也不用太担心升级UWP很困难。我相信迁移应用的主要工作量在由于新的设计风格,而需要修改UI设计,同时也要考虑多平台的响应式布局等等。。。

  .NET Native

  回到文章的主题,Win10 UWP使用了新的编译技术 .Net Native。据介绍:

  ".NET Native可以将C#代码编译为本地机器码。据博客介绍,.NET Native可以优化所有的Windows Store应用。使用.NET Native编译Windows Store应用程序,应用启动速度将加快60%,并且内存占用更小,这主要得益于开发团队优化.NET Native运行时(CLR的一个重构和优化)和使用先进的Microsoft VC++优化器后端。此外,最令开发者兴奋地是,使用.NET Native不仅会让应用拥有C++般的性能表现,还可以实现C#般的生产力。"

  总而言之,这是个提高性能的好东西。。。但是目前我还是遇到了一些现象和小问题。

  1.编译时间长

  这个其实不是错,牺牲编译时间,换运行时间挺值的。因为编译成机器码,工作量更大了,所以时间长了。在我的i5-3230m的笔记本上,编译官方给的小Sample都需要3分钟左右。我们这种菜鸟也终于可以像大神一样,点击编译就出去喝茶了。。。由于这个原因,微软设定了Debug模式下默认采用原来的.Net Core Runtime的方式编译,速度较快。Release模式的时候才采用.Net Native。

   

  由于Debug默认不使用.Net Native编译,这样在调试断点的时候,有些数据会看不到。。。这时候你可以去掉Release的“优化代码”选项,或者新增一个等效的模式再调试。

  2.项目路径含中文会导致编译错误

  我在Debug的时候,一切正常的,Release的时候,却报错了,还是吓人的一长串。。。

  

  经过搜索、网友的提醒,最终发现是项目路径带中文引起的。

  C:\Users\双华\Documents\Visual Studio 2015\Projects\。。。由于微软账号填的是中文名,这些路径都自带中文了。_(:з」∠)_

  3.同时引用Desktop 和 Mobile Extension SDK,则编译失败

  Destop 和 Mobile Extension SDK是两个拓展SDK,包含一些各自平台的专有API。

  

  但是目前在VS2015中,如果同时引用两个SDK,通过.Net Native编译(如Release时)会失败。错误类似上一个问题,里面写了大量 \Microsoft.NetNative\x86\ilc\ilc.exe, Windows Kits

  经过一番搜索,发现已经有人解决了。方法如下:

      

  点此访问原文

  点此下载文中提到的Microsoft.NetNative.targets文件(放到百度云上了)

  吐槽:微软的测试水平下降了。。。

  以上。

  

  

时间: 2024-12-28 20:50:58

<Win10开发>UWP使用.Net Native编译时遇到的一些问题。的相关文章

win10 + VS2010 + OpenCV2.4.10重编译OpenCV开发环境搭建

win10 + VS2010 + OpenCV2.4.10重编译OpenCV开发环境搭建 重编译的优点:能够调试的时候看OpenCV的源码. 重编译要得到的东西:Debug版本号和Release版本号的dll,lib,头文件.(dll加入到环境变量里,执行时用,自己编译的dll调试时能够跟踪到Opencv的源代码内:lib和头文件配置到编译器里) PS:假设仅仅是使用Opencv而不须要跟踪源代码,则使用Opencv自带的库文件就可以. 跳到5配置Opencv开发环境.相应的文件都在..\ope

VS2015+OpenGL4.0开发编译时弹出错误:glaux.lib(tk.obj) : error LNK2019: 无法解析的外部符号 _sscanf,该符号在函数 [email&#160;protected] 中被引用

一.问题描述: VS2015+OpenGL4.0开发编译时弹出如下所示的错误: 1>glaux.lib(tk.obj) : error LNK2019: 无法解析的外部符号 _sscanf,该符号在函数 [email protected] 中被引用 1>glaux.lib(tk.obj) : error LNK2019: 无法解析的外部符号 _vsprintf,该符号在函数 _PrintMessage 中被引用 二.问题原因: VS2015默认编译时将许多标准库采用内联方式处理,因而没有可以链

VS2013下开发VC++程序,编译时提示错误error MSB8020: The build tools for v140 (Platform Toolset = &#39;v140&#39;) 的解决方案

1. 问题描述: 提示如下错误:error MSB8020: The builds tools for v140 (Platform Toolset = 'v140') cannot be found. To build using the v140 build tools, either click the Project menu or right-click the solution, and then select "Update VC++ Projects...". Inst

VELT-0.1.5开发: gdb串口调试内核时信息丢失的问题

快乐虾 http://blog.csdn.net/lights_joy/(QQ群:Visual EmbedLinux Tools 375515651) 欢迎转载,但请保留作者信息 本文仅适用于vs2013 + velt-0.1.5 VELT的全称是Visual EmbedLinuxTools,它是一个与visual gdb类似的visual studio插件,用以辅助完成Linux开发.利用这个插件,将可以在visual studio的IDE中进行Linux应用程序的开发(包括编译和调试),也可

关于java编译时注解你需要知道的二三事。解除你的顾虑!

转载请注明出处: http://blog.csdn.net/liu470368500/article/details/51316066 做Android开发.大家肯定会关心你的app的性能问题.不知道从何时开始.网上有流传一句.不要使用注解.用注解会影响性能.这不能说错.但是也不能说对.这里普及一下关于注解的一些你需要知道的知识 网上常说的注解.基本是运行时注解.而所说的注解会影响性能.则是指的此类型的注解.因为运行时注解的解析.完全依赖于反射.而反射的效率.是比原生的慢的.特别是对于原先的老机

VELT-0.1.5开发:在vs2013下编译gdb

VELT的全称是Visual EmbedLinuxTools,它是一个visual studio插件,用以辅助完成Linux开发.利用这个插件,将可以在visual studio的IDE中进行Linux应用程序的开发(包括编译和调试),也可以进行uboot和linux内核的编译,并根据编译时的错误信息正确定位到源码.目前的版本是0.1.4,仅支持vs2013.此插件可以在CSDN下载频道下载(http://download.csdn.net/detail/lights_joy/8429771),

编译时、运行时、构建时(一)

在开发和设计的时候,我们需要考虑编译时,运行时以及构建时这三个概念.理解这几个概念可以更好地帮助你去了解一些基本的原理.下面是初学者晋级中级水平需要知道的一些问题. Q.下面的代码片段中,行A和行B所标识的代码有什么区别呢? public class ConstantFolding { static final int number1 = 5; static final int number2 = 6; static int number3 = 5; static int number4= 6;

linux下开发,解决cocos2d-x中编译出现的一个小问题, undefined reference to symbol &amp;#39;[email&#160;protected]@GLIBC_2.2.5&amp;#39;

解决cocos2d-x中编译出现的一个小问题 对于cocos2d-x 2.×中编译中,若头文件里引入了#include "cocos-ext.h",在进行C++编译的时候会遇到例如以下错误: undefined reference to symbol '[email protected]@GLIBC_2.2.5'/lib/x86_64-linux-gnu/libpthread.so.0: error adding symbols: DSO missing from command li

Android 如何编写基于编译时注解的项目

本文已在CSDN<程序员>杂志刊登. 本文已授权微信公众号:鸿洋(hongyangAndroid)在微信公众号平台原创首发. 转载请标明出处: http://blog.csdn.net/lmj623565791/article/details/51931859: 本文出自:[张鸿洋的博客] 一.概述 在Android应用开发中,我们常常为了提升开发效率会选择使用一些基于注解的框架,但是由于反射造成一定运行效率的损耗,所以我们会更青睐于编译时注解的框架,例如: butterknife免去我们编写