2 Comments

显示一辆带有出租车条纹的黄色大众巴士的Wall-E前方

我很喜欢 极好 -Xamarin.Forms的包装,使您可以使用F#编写功能性UI。初次查看项目时,我注意到它是建立在 AppVeyor特拉维斯。我问自己:为什么要使用两个CI系统来编译一个项目?经过进一步的挖掘,我发现AppVeyor上没有托管的macOS代理。另一方面,Travis确实提供了适用于Windows和macOS的代理,但没有在代理上安装Xamarin工具链。每次运行都安装Xamarin工具链会导致30分钟以上的构建时间。以来 Azure开发运营 支持在Windows和macOS上进行构建我想我会尝试一下并设置管道来构建Fabulous-我的意思是这有多难?很难写一篇博客文章来总结克服陷阱的步骤

TLDR:如何在Azure DevOps上运行FAKE脚本

神话般的用途 执行构建,测试和创建NuGet包。 FAKE是用于编写构建脚本的功能强大的完整工具。假也是 .Net Core CLI工具 该工具专为从命令行安装和执行而设计,因此非常适合在任何构建服务器上运行。

安装假

Azure开发运营构建代理不预装有FAKE。由于FAKE是.Net Core CLI工具,因此这没有问题。以下命令应解决此问题:

dotnet tool install fake-cli -g

不幸的是,安装后执行FAKE失败。这是因为Azure DevOps构建代理上的安装目录不同于.Net Core的标准安装位置-为什么?您问,那么给出的答案就是安全性。在Windows上,我们可以通过将FAKE安装到Workspace目录中来避免这一情况:

dotnet tool install fake-cli --tool-path .

在macOS(和Linux)下,这种方法仍然会失败。的 建议的解决方案 is to set DOTNET_ROOT. I ended up with the following lines to be executed on the macOS agent:

export DOTNET_ROOT=$HOME/.dotnet/
export PATH=$PATH:$HOME/.dotnet/tools:/Library/Frameworks/Mono.framework/Versions/Current/Commands
dotnet tool install fake-cli -g

在Linux上,该方法不得不再次采用-实在是很重要。我结束了这些行:

export PATH=$PATH:$HOME/.dotnet/tools:/Library/Frameworks/Mono.framework/Versions/Current/Commands
dotnet tool install fake-cli -g

现在您应该可以在Azure DevOps上运行FAKE脚本

使用NuGetFallbackDirectory

This part is not directly related to FAKE but is something I stumbled over while running on Azure DevOps. One test script was referencing the NuGet packages via the global NuGetFallbackDirectory 和 was looking for them under the default location. Under macOS the location is in the users home directory, so adopting the path as follows did the trick:

let tfsEnvironment = Environment.GetEnvironmentVariable("TF_BUILD")
if (String.IsNullOrEmpty(tfsEnvironment)) then
    "/usr/local/share/dotnet/sdk/NuGetFallbackFolder"
else
    let homepath = Environment.GetEnvironmentVariable("HOME")
    Path.Combine(homepath, ".dotnet/sdk/NuGetFallbackFolder")

Note that the variable TF_BUILD is expected to only be set on TFS/VSTS/Azure DevOps. This will allow the script to fall back to the default location should it be executed on a developers machine.

但是,为什么还要打扰呢?

从工作中的CI迁移到另一个CI的动机是什么?您是否在做,因为您是Microsoft MVP?

这些是与同事谈论我在Azure DevOps上构建Fabulous的工作时遇到的问题。我认为AppVeyor和Travis是很棒的工具,它们表明他们有能力完成任务和测试Fabulous。除了因为我好奇它的难易程度外,我还想从两个方面尝试将生成版本迁移到Azure DevOps:

  1. 合并构建,让两个地方做一件事情总是伴随着开销。
  2. 另一个人正在看到无需安装Xamarin可以减少多少构建时间。

因此,这是之前和之后的构建时间之间的比较:

CI平台代理操作系统建立测试时间(分钟)
特拉维斯苹果系统~30-32
Azure开发运营苹果系统~13-14
AppVeyor视窗~4
Azure开发运营视窗~6

现在要记住,在macOS和Windows上的构建是并行运行的。因此,对于AppVeyor和Travis而言,生成时间为30-32分钟。借助Azure DevOps,这可以减少到13-14分钟。

我认为将两个构建脚本合并为一个并将构建时间减少大约一半是一个很好的理由,说明为什么Azure DevOps似乎更适合Fabulous。再说一次,运行.Net CLI工具时会遇到一些麻烦,我希望Azure DevOps团队将来会解决-是来自同一公司和所有公司的产品 咳嗽

另一个方面是将来在Linux上进行构建,因为Fabulous自0.30开始支持GTK,因此也可以在Linux上编译它。在撰写本文时,Fabulous的构建过程中仍然存在一些问题,但是将来没有什么不能解决的。

谢谢

谢谢 蒂莫西·拉里维耶(TimothéLarivière)斯图尔特·朗 对于沿途的所有提示和提示

0 Comments

testcloud_devices

开发应用程式时最初引起人们关注的iOS,Android和Windows 10移动应用程序或网络应用程序是一个核心理念,可为用户带来核心价值。一旦范围广为人知,理想情况下,一个人就可以开始开发最小可行产品,该产品展示了核心思想,让创作者从潜在用户那里得到第一笔反馈。通过最初的想法和反馈,团队开始为应用程序添加越来越多的功能,一切都很好。直到用户开始报告某些奇怪的行为,并且精心设计的更改开始对其他功能产生副作用。因此,每个版本都必须经过全面测试,然后才能发送出去。检查所有功能所花费的时间开始增加,但是如果不进行所有测试,可能会导致新错误潜入应用程序。那么该怎么办?

带上仙尘-自动化UI测试

这通常是一个人例如一个非技术经理会听到有关UI测试框架的信息,该框架恰好解决了手动测试自动化的问题。另外,关于UI测试框架的一件大事通常是应用程序不需要任何更改。由于一个测试针对整个堆栈,因此测试的覆盖率非常高。

自动化的UI测试可以在应用程序的UI层上模拟用户交互。根据哪种应用程序,可以选择不同的框架。对于iOS和Android上的移动应用程序,我们将研究的解决方案是Xamarin Test Cloud(XTC),它基于Calabash测试框架。 XTC允许创建可在各种平台上使用的UI测试。它们可以在本地运行,即阅读“连接到测试仪计算机的电话”。不过,更有趣的是,有机会在Xamarins Test Cloud中运行相同的测试,它提供了数百种可以在其上运行应用程序和测试的设备(具有不同的OS版本)。

但是生活中有这么多东西-UI测试是有代价的。与单元测试或集成测试相比,它们相当慢,并且像集成测试一样,它们在易碎性方面往往更多。即,由于应用程序的更改而导致测试失败。如果UI仍需进行大量更改,则尤其如此。话虽这么说,它们可以成为减少手动测试时间的好工具。但是仅依靠UI测试进行移动测试很可能不会获得您期望的结果。那么,自动化的UI测试将为您带来最大收益的优点是什么?

好吧,让我们开始考虑在考虑移动应用程序时可以实际实施的测试:

TestDistribution

如图所示,金字塔越宽,您可能希望在项目中进行的测试越多。因此,让我们深入探讨不同领域的主要好处,并研究如何实现这些好处。

单元测试

测试单元的基本逻辑是单元测试的作用。单元测试不应依赖于类可能具有的任何依赖关系,因此需要存根和模拟来评估业务逻辑的正确工作。单元测试应始终通过且不会出错,因为它们会检查应用程序的基本逻辑实现。

UI测试应始终通过,即为绿色,因为它们仅测试逻辑而没有任何依赖性。

进一步的单元测试很快。实际上,如果单元测试的运行时间超过100毫秒,则认为它很慢。对于大型项目,进行大量此类测试以检查所有小型构件是否均按照规范/用户情况工作并不罕见。解决依赖关系所需的额外工作可能会导致应用程序某些部分(主要是协调工作流)的工作繁琐。此外,由于它们仅隔离测试逻辑,因此单元测试不会给出组件如何协同工作的任何反馈。但是,当所有单元测试都是绿色的时,对a逻辑的信心就很高,可以将重点放在寻找问题上,而将注意力转移到构建测试相互作用的构建块之间。

单元测试的特征

测试什么逻辑块,单个类,部分类
执行时间/测试< 100 ms
可靠性很高
对建筑的影响

整合测试

当多个零件时想要测试的应用程序类通常是集成测试。集成测试的范围从测试紧密协作的几个类到需要系统的多个部分正常运行的系统测试。对于不属于已开发应用程序的外部服务,可以使用存根和模拟来确保测试不会因团队范围之外的服务失败而失败。集成测试通常需要花费更多时间才能运行,因为它们可以运行实际场景。由于部件和子系统的数量不同,集成测试可能要比单元测试更脆弱。此外,将错误定位到项目的特定区域会变得更加困难,因此单元测试是集成测试的完美完成,因为它们允许单独测试复杂的逻辑部分。如果我们查看根据MVVM模式构建的标准应用程序,则集成测试通常从视图模型或堆栈中的较低模型运​​行。集成测试不仅可以测试应用程序的功能正确性,还可以让您了解应用程序的性能。如果您有兴趣在实际设备上运行测试,则可以阅读有关此主题的更多信息。 这里.

集成测试的一个问题是未对View进行测试。即使可能会争辩到正确应用MVVM模式时,视图中只剩下最小的逻辑,但用户仍将通过视图使用该应用程序。这样就可以避免在通过视图操作应用程序时仍然存在问题。此处(自动)UI测试起作用。

一般来说,如果一个项目根本没有自动化测试,那么集成测试往往会带来更大的收益。由于体系结构要求不完全相同。

集成测试的特征

测试什么组件之间的交互,与其他系统部件的集成,网络通信,长时间运行的测试,内存消耗
执行时间/测试秒到几小时
可靠性中等偏上
对建筑的影响

UI测试– Xamarin测试云

现在,当拥有复杂的单元测试和集成测试套件时,最好避免完全测试您的应用程序,但是最终用户将通过UI与应用程序进行交互。通常来说,当应用程序由于与应用程序中使用的UI元素不兼容而在其设备上崩溃时,他们并不关心下面的逻辑是否合理。因此,每个应用程序项目应执行的最低UI测试是手动测试。一个人点击该应用程序,并确保UI能够按预期响应并遵循预期的工作流程。现在,如前所述,手动测试需要大量时间和资源来执行测试,即一个人可能会感到有点不知所措。因此,一般而言,我们在哪里可以利用自动UI测试来提高测试覆盖率:

  • 烟雾测试
  • 工作流程
  • 测试互动
  • 元素的存在
  • 本土化
  • 多设备测试

可能会很想考虑一个人可以完全消除手动测试,但是UI测试在某些方面只是无法自动覆盖而始终需要人工:

  • 布局(元素无法正确呈现)
  • 系统交互
    • 相机
    • 相片集
    • 分享中
  • 用户界面“ Snappiness”
  • 探索性测试
  • 离线测试
  • 蓝牙

即使该布局可以通过自动测试进行覆盖,但它所拍摄的图片都可以由用户/ MD5哈希进行比较。计算机(至少在撰写本文时)没有能力分析应用布局的正确性。因此,进行某些测试仍然需要人的眼睛和大脑,这是所有事物自动化时要记住的事情。其他限制来自设置,例如必须有与手机的WiFi连接才能运行自动UI测试。在测试与其他设备(即专有硬件或显然必须配对的其他电话)的互连性时,UI测试通常变得非常麻烦,并且XTC通常不支持此类情况。因此,是的,UI测试存在局限性,但是正确使用它们不仅会极大地提高自动化测试的覆盖范围,而且还可以节省宝贵的测试时间,然后将其用于将人的大脑用于更高级的测试任务,然后麻木地通过一个应用程序进行点击。

UI测试的特征

测试什么测试整个应用程序软件堆栈,冒烟测试,工作流测试
执行时间/测试分钟
可靠性中–低
对建筑的影响

结论

有多种方法可以实现对移动应用程序的自动化测试。一方面,有一些测试可以验证构建应用程序的单个构建块的逻辑。集成测试可以验证应用程序各部分之间的正确互通,这可以扩展到应用程序的边界,并且还包括对后端的调用以验证正确的集成。可用于移动应用程序的最高级别的测试是自动UI测试。 Xamarin测试云允许创建可以在数百个设备上执行的UI测试。在应用发布之前在如此多的设备上测试应用可以带来有价值的见解,并且这些测试的自动化使您不仅可以轻松地在逻辑和集成层上而且还可以在UI上执行回归测试。考虑一下即将发布的OS版本,并且您想检查您的应用程序是否存在任何问题,考虑到自动UI测试,您可以轻松地运行测试套件,该套件会迅速通知您是否对即将发布的更新有任何疑问。

0 Comments

超人 Apps平台概述

借助UWP应用,编写一个可以在所有Windows 10设备上本机运行的应用程序变得更加容易,无论它是手机,平板电脑,PC,Xbox等。等现在,我们不仅希望我们的应用程序能够在我们希望它们在运行时发光的设备上运行。在此博客文章中,我们将介绍有关如何在UWP应用程序中采用不同屏幕尺寸的基础知识。

 

设备和屏幕尺寸

超人在许多不同的平台上运行,默认情况下甚至可能没有屏幕。物联网(IoT)设备或其他需要唯一UI的设备,例如 全息镜头 将于今年晚些时候提供给一些幸运的开发人员。现在,尽管这些平台在某些情况下非常有趣,但很可能将为手机,平板电脑和平板手机(又名BAPH)(大型a **手机)等移动设备开发各种各样的应用程序。与Android和iOS应用程序相比,UWP的独特之处在于,您的应用程序不仅可以在移动设备上运行,而且还可以在台式机,笔记本电脑甚至更大的屏幕(例如新设备)上运行 表面集线器.

视窗 10设备
现在编写一次就可以在任何地方运行,看起来很容易废话。但是创建UWP应用的最大好处是您可以采用不同的屏幕尺寸,甚至可以采用不同的用户输入,例如触摸与鼠标和键盘。但是在深入探讨如何使用XAML编写响应式UI的细节之前,让我们先看一些基本的布局规则。

设备和屏幕尺寸

可以按如下方式对设备进行大致拆分。

类别屏幕尺寸有效像素宽度输入项
电话4”至6”340+触摸& Voice
平板6+”至7”720+触摸& Voice
片剂7英寸至13.3英寸1024+音调,触控笔,外接键盘*,鼠标*,语音*
个人电脑和笔记本电脑13英寸及以上1024+鼠标,键盘,触摸*,游戏手柄
表面集线器设备55”和84”1024+触摸,笔,语音,键盘,远程触摸板

*: 偶尔

基本布局指南

由于UWP应用是从头开始构建的,可以在各种不同的设备(即外形尺寸)上运行,因此该平台附带了许多帮助程序,可以简化多个平台的设计工作。一个基本概念是有效像素。有效像素与实际物理像素有所不同,因此手机上的24个有效像素将在更大的屏幕上放大为更大的物理外观。有效像素到物理像素的缩放全部由框架完成,并且开发人员(即设计人员)不需要任何特殊的出席。

该图显示了设备上附加的不同比例因子。

注意:通常小屏幕的每英寸点数非常大(DPI),这也由平台处理,因此即使您在显示价格便宜(即DPI较低)的小型设备上运行,文本仍将像在具有更多像素(例如DPI较高)的高端显示器上一样清晰可读。

缩放比例基于四(4)的倍数,因此在定义布局时,请确保它们是四的倍数,例如16.这将确保缩放不会导致奇怪的影响。当使用图标而不是图像时,请尝试使用字体(例如,新的 Segoe MDL2资产),提供您要查找的图标(或足够接近)。尽管Windows 10确实提供了一种根据屏幕大小在图像的不同分辨率之间进行选择的机制,但是字体将始终能够按比例缩放,而无需任何进一步的努力。

实施自适应布局以适应可用的屏幕空间

当使用不同的分辨率时,可以执行多种布局调整,以改善常规的用户体验(UX)和–交互。 UWP提供了多种根据可用屏幕空间调整应用程序布局的方法。

  1. 根据尺寸和可用屏幕空间更改页面上元素的布局
  2. 回流焊屏幕尺寸增加时添加文本列
  3. 显示信息/功能,具体取决于设备及其分辨率
  4. 用弹出菜单替换导航栏之类的元素,以容纳较小的屏幕空间
  5. 更改屏幕流,例如主要详细信息站点

因此,让我们深入研究如何根据屏幕空间更改UI元素的布局。

响应式布局

ResponsiveDesign

超人应用程序的一项新功能是可以根据可用的屏幕尺寸(即应用程序窗口的有效像素宽度)调整控件的布局。这使UI可以适应不同的屏幕尺寸,例如手机和平板电脑,还可以让UI适应Window在桌面上的大小。

假设您的应用程序具有以下屏幕流程和布局:

显示运行的有效像素少于720个的应用。

该应用程序的基本布局如下所示:

<RelativePanel>
    <Rectangle x:Name="Image" Width="80" Height="80" Fill="Gray" Margin="8"></Rectangle>
    <Rectangle x:Name="TextLine1" Height="16" Width="200" Fill="Gray" RelativePanel.RightOf="Image" RelativePanel.Below="" Margin="8,8,8,4"/>
    <Rectangle x:Name="TextLine2" Height="16" Width="200" Fill="Gray" RelativePanel.RightOf="Image" RelativePanel.Below="TextLine1" RelativePanel.AlignLeftWith="TextLine1" Margin="8,8,8,4"/>
    <Rectangle x:Name="TextLine3" Height="16" Width="168" Fill="Gray" RelativePanel.RightOf="Image" RelativePanel.Below="TextLine2" RelativePanel.AlignLeftWith="TextLine1" Margin="8,8,32,4"></Rectangle>
</RelativePanel>

注意: 将项目呈现在 相对面板 允许矩形内的元素彼此相对对齐。这是Windows 10 UWP应用程序中提供的一项新的布局功能,以前必须使用 要么 StackPanel。使用相对布局的好处是,当我们专注于如何针对不同的屏幕(大小)重新调整内容时。

例如,当在平板电脑上显示时,您可能不仅希望在文本旁边显示小图像,而且还会带有横幅。用一个 VisualStateManager可以轻松定义最小窗口宽度和 如果触发触发器,则采用预定义布局的布局:

<VisualStateManager.VisualStateGroups>
    <VisualStateGroup>
        <VisualState x:Name="wideView">
            <VisualState.StateTriggers>
                <AdaptiveTrigger MinWindowWidth="720" />
            </VisualState.StateTriggers>
            <VisualState.Setters>
                <Setter Target="Image.(Width)" Value="720"/>
                <Setter Target="TextLine1.(Width)" Value="720"/>
                <Setter Target="TextLine2.(Width)" Value="720"/>
                <Setter Target="TextLine3.(Width)" Value="600"/>
                <Setter Target="TextLine1.(RelativePanel.Below)" Value="Image"/>
                <Setter Target="TextLine1.(RelativePanel.AlignLeftWith)" Value="Image"/>
            </VisualState.Setters>
        </VisualState>
        <VisualState x:Name="narrowView">
            <VisualState.Setters>
                <!-- Adjust view for narrow view -->
            </VisualState.Setters>
            <VisualState.StateTriggers>
                <AdaptiveTrigger MinWindowWidth="0" />
            </VisualState.StateTriggers>
        </VisualState>
    </VisualStateGroup>
</VisualStateManager.VisualStateGroups>

目标名称与 x:名称 给控件。现在,如果应用的有效像素超过720个,页面将重新呈现:

显示运行的有效像素超过720的应用。

在Windows 10台式机上调整窗口大小时,页面也会进行调整,这使用户可以一次打开多个应用程序,使它们无缝适应新的窗口大小。

结论

在这篇文章中,我们看到通用Windows平台应用程序不仅可以在多个设备上运行,而且该平台为开发人员和设计人员提供了创建出色的用户体验的必要工具,无论屏幕大小和分辨率如何,都无需创建多个页面布局。地面,必须以某种方式弄清楚屏幕本身的大小。

您可以在以下位置找到整个项目 的GitHub.

0 Comments

了解如何提供基于C#的跨平台API,您可以在通用Windows平台应用程序(UWP),Xamarin.iOS,Xamarin.Android,Xamarin.Forms,ASP.Net甚至经典的.Net WPF应用程序中使用。在我的最后 发布 我展示了如何通过依赖项注入在可移植类库中使用平台特定的库和代码。当您开发自己的应用程序时,这种方法非常有用,但是当您想向同事/开发人员提供库时,这种方法会变得有些古怪,因为您迫使他们通过依赖注入来设置自己的库。但是,当然还有另一种方法可以让您整齐地封装实现细节,同时仍然为PCL代码提供平台特定的功能。

此博客文章中的库将提供UWP,Xamarin.iOS和Xamarin.Android应用程序的操作系统版本。

设置图书馆

该库包含四个项目:

  • 操作系统版本.Core
  • 操作系统版本.UWP
  • 操作系统版本.Droid
  • 操作系统版本.iOS

对于所有项目,有一点特别之处在于,它们的所有默认命名空间和程序集名称都具有相同的名称。

NamespaceBinaryName

在每个项目中,我们实施 SystemInformationHandler.cs 类,在PCL上,我们只需实现一个存根:

public class SystemInformationHandler
{
    #region Implementation of ISystemInformationHandler

    public static string OSVersion => "Gnabber";

    #endregion
}

对于其他平台,例如UWP,我们实现对UWP特定API的调用:

public class SystemInformationHandler
{
    public static string OSVersion
    {
        get { return OsVersionString(); }
    }

    private static string OsVersionString()
    {
        string sv = AnalyticsInfo.VersionInfo.DeviceFamilyVersion;
        ulong v = ulong.Parse(sv);
        ulong v1 = (v & 0xFFFF000000000000L) >> 48;
        ulong v2 = (v & 0x0000FFFF00000000L) >> 32;
        ulong v3 = (v & 0x00000000FFFF0000L) >> 16;
        ulong v4 = (v & 0x000000000000FFFFL);

        return $"视窗 {v1}.{v2}.{v3}.{v4}";
    }
}

因此,最后,我们在PCL中实现了通用类,并为我们要支持的每个平台实现了特定类。现在让我们看看如何在应用程序中使用该库。

消耗图书馆

该应用程序将包含通常的跨平台移动应用程序安装程序,这意味着我们将使用可移植类库(又名Core)来覆盖Windows,Android和iOS,从而共享可重复使用的代码。

NativePclProjectOverview

核心是我们的业务逻辑代码和视图模型(我是MVVM Light库的忠实拥护者,要了解更多信息,请仅查看我的 mvvm灯柱)。在NativePcl.Core项目中,我们有一项服务 OsVersionService.cs 返回版本号:

public class OsVersionService : IOsVersionService
{
    public string GetVersion()
    {
        return SystemInformationHandler.OSVersion;
    }
}

以二进制形式引用OSVersion.Core库–请勿将其作为项目引用,否则在下一步之一中您将面临编译错误。不要问我我怎么知道 眨眼的微笑

因为我们所有的OSVersion库程序集都将被编译为具有相同名称的程序集,所以我们不仅可以简单地引用项目文件,还必须添加二进制文件,即库的编译版本。如果您正在查看来自GitHub的示例,请确保在发布版本下编译该解决方案,因为OSVersion是通过项目的发布输出文件夹中的二进制文件引用的。

该方法调用 操作系统版本 OSVersion库中的属性-省略特定项目,例如UWP的意图完全在这里。在客户端(例如Android应用)上,我们有一个屏幕,显示在 MainView.xaml:

<Page
    x:Class="NativePcl.UWP.MainPage"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:local="using:NativePcl.UWP"
    xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    DataContext="{Binding Source={StaticResource Locator}, Path=Main}"
    mc:Ignorable="d">

    <Grid Background="{ThemeResource ApplicationPageBackgroundThemeBrush}">
        <TextBlock Text="{Binding OSVersion}" VerticalAlignment="Center" HorizontalAlignment="Center" Style="{StaticResource TitleTextBlockStyle}"></TextBlock>
    </Grid>
</Page>

以及我们正在使用的视图模型背后或之后的相应代码 MainViewModel.cs:

public class MainViewModel : ViewModelBase
{
    private readonly IOsVersionService _osVersionService;

    public MainViewModel(IOsVersionService osVersionService)
    {
        if (osVersionService == null) throw new ArgumentNullException(nameof(osVersionService));
        _osVersionService = osVersionService;
    }

    public string OSVersion => _osVersionService.GetVersion();
}

如果现在运行该应用程序,我们将获得以下输出:

coreVersion

现在这是我们在 操作系统版本.Core,如果我们现在引用 操作系统版本.UWP 在里面 NativePcl.UWP 项目的事情变得非常有趣。不会因为我们要添加两个具有相同名称的程序集而收到错误,因此编译器将首选平台特定的库,而不是PCL实现。即使我们从不直接从我们的库中调用该库 NativePcl.UWP 从平台特定的版本(即 操作系统版本.UWP 实施 GetVersion() 方法导致以下输出:

uwpVersion

现在,尽管这种方法允许在PCL中编写平台独立的逻辑并在运行时调用特定于平台的实现,但由于需要开发人员引用正确的库版本,因此有些繁琐。它们都具有相同的名称,这只是由于引用了错误的库版本而导致令人沮丧的几分钟。幸运的是,有一种技术可以使用上述方法而不会给开发人员增加使用正确引用二进制文件库的负担。 通过将库包装在NuGet包中 使用该库就像将程序包添加到所有项目中一样简单,NuGet程序包管理器就像构建引擎喜欢将PCL库中特定于平台的二进制文件链接到项目一样。因此,开发人员不必选择要添加的二进制文件,现在只需将相同的NuGet包添加到所有项目中即可使用。

结论

在本文中,您了解了如何创建可在PCL中使用并仍提供平台特定功能的API。为了使所有这些正常工作,我们必须将项目的名称空间和程序集设置为相同的名称。在消费者上,您可以简单地添加一个包含所有实现的NuGet包,即PCL,UWP,Android和iOS,或者将相应API编译的二进制文件添加到应用实现中,例如 操作系统版本.Core本机核心.

通过这种方法,您可以创建可在多个平台之间重用的API,从而在各个平台之间提供相同的方法定义。

您可以在以下位置找到示例 的GitHub。 (确保首先将其编译为发行版)

0 Comments

在最近的几天里,这一直困扰着我,所以我只想记下启动模拟器并在Windows 10下运行的步骤。就我而言,是从Win 8.1升级之后。因此,如果您收到以下错误之一:

  • [重要]要运行仿真设备,需要使用内部虚拟网络交换机。
  • [重要] XDE退出代码:CouldntCreateInternalSwitch(16)
  • [重要] XDE退出代码:CouldntStartVm(10)
  • [重要] XDE退出代码:InvalidArguments(3)
  • 有关UDP连接错误,请参阅最后的2016年7月更新。

这些步骤应该可以帮助您恢复并运行仿真器:

免责声明: 请注意,执行这些步骤需要您自担风险。通常来说,所有程序都可以正常运行,但是某些步骤将删除一些Hyper-V设置,这可能会影响您的网络连接或虚拟机设置。因此,请按照我的机器建议进行操作。

  1. 确保没有XDE.exe任务正在运行(任务管理器)
  2. 修复Android SDK –打开 程序和特点 >适用于Android的Microsoft Visual Studio模拟器> select 更改 在菜单栏中,然后选择 修理 在Visual Studio对话框中
  3. 删除所有Hyper-V虚拟交换机–打开  Hyper-V管理器 >选择虚拟交换机管理器…(位于右侧菜单中)>选择每个虚拟交换机,然后选择删除> click onto Apply
    1. 如果删除虚拟交换机时发生错误,请尝试重新启动计算机
  4. XdeCleanup.exe –取决于您的安装,但在Surface Pro 3上,您应该在以下位置找到它:“ C:\ Program Files(x86)\ Microsoft XDE \ 10.0.10240.0”

现在尝试启动并运行模拟器。如果仍然收到错误消息,请尝试以下步骤:

  • (Surface Pro 3)重新安装网络驱动程序> Open the 装置经理> under 视图选择 显示隐藏的设备 > Uninstall Marvell AVASTAR无线交流网络控制器表面以太网适配器 >重新启动,它将自动从恢复分区重新安装驱动程序
  • 清理网桥>打开网络连接>添加网桥(此选项仅在第一次出现)>再次删除添加的网桥

现在,您的模拟器应该启动了。

备注

我不得不重复执行步骤3两次-即使在模拟器第一次启动后,但也许这只是我机器上的配置问题……

希望这对您有所帮助,并祝您编程愉快! Smile

资源资源

http://stackoverflow.com/questions/31613607/visual-studio-2015-emulator-for-android-not-working-xde-exe-exit-code-3


更新-2016年7月20日

昨天设法再次破坏了我的Android模拟器。这次,以上尝试都没有为我解决。由于这是较常见的博客文章之一,我想我将进行更新以分享另一种可能的解决方案。

错误消息是无法与仿真器建立UDP连接。执行以下步骤解决了该问题:

  • 打开设备管理器(在Win10上,只需在开始菜单中搜索设备管理器)
  • 视图选择 显示隐藏的设备
  • 删除除网卡外的所有虚拟网络设备(您没有删除蓝牙设备)
  • 如第3点所述,打开Hyper-V并删除所有Hyper-V虚拟网络终结点
  • 重启
这些步骤基于以下疑难解答而解决了上面提到的问题 文章由Microsoft。