.NET Core 程序的打包与分发 （Linux 篇 Part. I）

发表评论

.NET Core 从 runtime 发布 1.0 RTM 版本至今已经过去一年多了，由于其主要针对跨平台 Console App 设计（ASP.NET Core 的实际部署方式也是 Console App），在 Windows 和 macOS 上的应用都比较有限：对于 Windows 平台，由于有兼容性较好的完整 .NET Framework，几乎不需要使用 .NET Core；而 macOS 程序主要以桌面 GUI 为主，.NET Core 除了用在服务器程序开发中，也很难有什么别的用途，而 macOS 上 mono 程序开发/调试的体验也还说得过去。

但 Linux 的情况就不同。首先 Linux 的应用主要以 Console/Web Server 为主，而 .NET Core 主要就是针对这些；其次在很多发行版上，mono runtime 的版本非常旧，API 实现不全，并且调试不方便。这种情况下，合理使用 .NET Core 能显著简化 .NET 应用程序的部署。

本文主要针对将 Console App 使用 Self-contained 方式（自带完整 runtime）部署到 .NET Core 支持的发行版的应用场景。这些发行版的特征是存在版本号（非滚动更新），且同一版本内二进制 ABI 稳定，如 Ubuntu, Debian, CentOS/RHEL, Fedora 等；而对于滚动更新的发行版如 Arch Linux 等，我将会在下一篇文章中讲述如何分发 .NET Core 程序。 继续阅读 →

三种方式轻松绕过Windows App Certification Kit (WACK)的API检测(UWP, C++)

发表评论

微软在UWP中提供了一组丰富的API能够满足99%的应用的需求，然而在那剩下1%的情况下找不到桌面API的替代品是很棘手的，正如我上一篇文章里提到的CreateFile，就不属于微软在UWP中允许使用的API。
实际上WACK的API检测是个没什么用的东西，因为它是通过读取PE导入表，以及 .NET程序的P/Invoke签名的方法来判断一个App是否使用了不允许使用的API。因此只要调用LoadLibrary就能轻松绕过。
问题在于LoadLibrary(Ex)本身不被允许调用，微软表示替代品是LoadPackagedLibrary，而这个API在调用时会检测路径是否在appx内，如果不在就直接报错。（太愚蠢了）因此首先我们要设法获得LoadLibraryEx的地址，在此之前先获取kernel32.dll或kernelbase.dll的地址。

继续阅读 →

UWP使用命名管道与桌面程序通信 (C#)

1条回复

关于UWP的历史，其起源是Microsoft在Windows 8中引入的Metro apps。（后来又被称作Modern apps, Windows apps, Universal Windows Apps等）无论是从目的还是从效果上看，这一类应用模型都与iOS/Android比较相似，是为了更有利于移动平台生态的发展设计的。
然而UWP目前面向的最大的用户群体是Windows桌面用户，只用UWP实现一个程序就会出现很多feature无法实现的问题，因此这种情况下，让用户安装并运行一个普通权限的后台进程，使用UWP做UI与之通信就成为了一种选择，毕竟UWP的C#/XAML性能比WPF好得多，分发/支付上也比桌面程序方便不少，虽说原则上微软并不允许商店应用与桌面应用互相通信。

继续阅读 →

Chakra实战：UWP与js交互(C#)

发表评论

几个月前在翻MSDN时发现Microsoft已经允许在Windows Store Apps（即UWP）里使用Chakra的API了。这意味着大家终于可以光明正大地在app中调用Javascript。//另外UWP允许JIT了所以你自己移植个V8上去其实也行
在8.x时代，Chakra是被标记为Desktop only的API，想要在Store apps里使用js，要么整个App使用HTML/js编写，要么使用WebView调用。前者显然不符合主要使用C#/XAML编写UI的前提，后者麻烦的要死，不好用。

UWP写起来真舒服（棒读）

使用Chakra之前需要较为深入地了解Chakra API，COM和JavaScript。其实不了解直接照抄代码拿着用也没什么不好，就是出了错之后不好排除。

继续阅读 →