WEBVTT

00:00:00.930 --> 00:00:03.890
好了，我们在.NET 展示上。

00:00:03.890 --> 00:00:07.400
而且我们有今天
Immo Landworth

00:00:08.800 --> 00:00:11.470
项目经理是谁
在.NET 团队。

00:00:11.470 --> 00:00:13.160
我们的实际工作
我认为在一起。

00:00:13.160 --> 00:00:14.180
>> 是。
>> [发笑]

00:00:14.180 --> 00:00:14.764
>> [发笑]

00:00:14.764 --> 00:00:16.234
>> 和我们将要做的今天

00:00:16.234 --> 00:00:18.362
在.NET 标准 20 深究。

00:00:18.362 --> 00:00:20.970
>> 和
[听不到] 中心一般。

00:00:20.970 --> 00:00:21.520
>> 的权限。
>> 和

00:00:21.520 --> 00:00:24.480
我认为，我们已经听到很
有关的几个问题。

00:00:24.480 --> 00:00:25.750
>> 是。
>> 思考的人感到兴奋。

00:00:25.750 --> 00:00:27.250
他们认为这是一件好事。

00:00:27.250 --> 00:00:30.840
但不一定完全
在所有情况下都支持它。

00:00:30.840 --> 00:00:31.660
>> 的权限。

00:00:31.660 --> 00:00:32.860
>> 因此，让我们进行深入的探究。

00:00:32.860 --> 00:00:36.090
我认为您是肯定一种
有关该主题的专家。

00:00:36.090 --> 00:00:37.302
>> 我更好地进行。
>> [发笑] 是。

00:00:37.302 --> 00:00:39.243
>> 是因为我花了两个
年处理这。

00:00:39.243 --> 00:00:40.050
[笑声]
>> 是。

00:00:40.050 --> 00:00:41.740
我的意思是如何可以花这么长时间？

00:00:41.740 --> 00:00:43.325
>> 我知道右。
似乎这样一个简单的概念。

00:00:43.325 --> 00:00:45.849
因此，让我们开始。

00:00:45.849 --> 00:00:49.030
>> 我有几张幻灯片，然后
我也有大量的演示，

00:00:49.030 --> 00:00:51.230
然后您可以随意中断
我和提出的问题。

00:00:51.230 --> 00:00:51.780
>> 我会。

00:00:51.780 --> 00:00:54.310
也正如我所说，我将
提供笑声轨道。

00:00:54.310 --> 00:00:54.810
>> 很好。

00:00:56.500 --> 00:00:58.289
>> 它可能只是我但
我不知道答案，但嘿。

00:00:59.360 --> 00:01:02.300
没事，这样重大的问题
究竟是我们为什么会关注

00:01:02.300 --> 00:01:03.170
有关.NET 标准。

00:01:03.170 --> 00:01:06.160
这通常是第一件事
人们想知道原因

00:01:06.160 --> 00:01:08.740
他们知道.NET 和
通常当他们认为.NET

00:01:08.740 --> 00:01:09.970
他们想到的
.NET 框架中。

00:01:09.970 --> 00:01:11.730
他们可能不这样说
.NET 框架，但

00:01:11.730 --> 00:01:14.430
实际上是什么
我们应该 15 年前。

00:01:14.430 --> 00:01:17.550
世界上是非常简单
因为我们只有回到那时

00:01:17.550 --> 00:01:19.720
担心的一个框架，

00:01:19.720 --> 00:01:22.970
基本上，您可以构建您
然后知道后的这两种类型。

00:01:22.970 --> 00:01:28.283
喜欢的基本上是桌面应用程序和
它是用于.NET 的应用程序。

00:01:28.283 --> 00:01:30.753
当然可以
生成控制台应用程序和

00:01:30.753 --> 00:01:32.710
窗口服务和
您有什么。

00:01:32.710 --> 00:01:34.610
但总是在
这一框架。

00:01:34.610 --> 00:01:37.900
因此，将业务逻辑时
只是在这一框架上使用它

00:01:37.900 --> 00:01:39.090
基于此库 BCL。

00:01:39.090 --> 00:01:41.160
>> 请记住，我。

00:01:41.160 --> 00:01:43.660
>> 很好的旧天，对，
近年来然后

00:01:43.660 --> 00:01:44.380
我们添加了更多的东西。

00:01:44.380 --> 00:01:45.720
因此没有 Xamarin，例如，

00:01:45.720 --> 00:01:48.870
其作用与相同
方面的事情

00:01:48.870 --> 00:01:51.300
为您提供.NET 平台
这就是真正的工作效率。

00:01:51.300 --> 00:01:54.630
但他们将更多关注
移动设备，特别是

00:01:54.630 --> 00:01:57.890
非 Windows 的 iOS 中，
OS X，然后 Android。

00:01:57.890 --> 00:02:00.300
显然，OS X 不是一种移动式
但同样存在。

00:02:00.300 --> 00:02:03.810
它是基本上的思想是你
构建不同类型的应用程序

00:02:03.810 --> 00:02:06.270
实质上是与他们
.NET 的版本。

00:02:06.270 --> 00:02:08.090
和它们的生成从单声道。

00:02:08.090 --> 00:02:10.449
因此单声道是非常相似
到.NET 框架，但是

00:02:10.449 --> 00:02:12.180
它不是 100%相同。

00:02:12.180 --> 00:02:13.570
因此，说话时
关于业务逻辑

00:02:13.570 --> 00:02:15.330
现在，您有以下两种情况
不必担心，右侧。

00:02:15.330 --> 00:02:18.350
然后使用.NET 核心
还有一个更多。

00:02:18.350 --> 00:02:20.460
因此，我们有另一个
移动此处有角 UWP。

00:02:20.460 --> 00:02:23.700
但然后还有新
ASP.NET 核心的东西，和

00:02:23.700 --> 00:02:26.560
还没有
对于.NET 核心的另一个 BCL。

00:02:26.560 --> 00:02:28.140
和它们是不同的
因为它们是

00:02:28.140 --> 00:02:29.350
不同的代码库，合适吗？

00:02:29.350 --> 00:02:32.390
因此，当我们接受 PRs，我们使用
接受在.NET 上 PRs

00:02:32.390 --> 00:02:35.050
由于核心侧的房子，
这是其中一方。

00:02:35.050 --> 00:02:37.740
然后从那里，报告它
net 框架或单声道，或

00:02:37.740 --> 00:02:40.740
其他任何实现
我们将来可能会有。

00:02:40.740 --> 00:02:41.295
并且，像这样

00:02:41.295 --> 00:02:45.360
重新使用代码现在变成这样
多维度问题，对吗？

00:02:45.360 --> 00:02:48.370
并且，像我们谈一谈这些
作为应用程序顶部的事情

00:02:48.370 --> 00:02:50.780
模型中，这件事
生成与您的应用程序和

00:02:50.780 --> 00:02:53.860
在底部的事情是我们
只需调用它们基库，

00:02:53.860 --> 00:02:54.920
一般用途的资料。

00:02:54.920 --> 00:02:55.420
>> 的权限。

00:02:58.100 --> 00:03:00.610
>> 我们要说
其三，再加上一个

00:03:00.610 --> 00:03:02.780
因为它基本上是
三种不同的事物，

00:03:02.780 --> 00:03:06.910
加上一个就是实际的
在所有这些常见。

00:03:06.910 --> 00:03:10.490
必须使在介意的
API 是实际上可以共享。

00:03:10.490 --> 00:03:12.826
您希望现在写到
基本上有到的库

00:03:12.826 --> 00:03:15.263
从编译多次
多个 [INAUDIBLE] 平台

00:03:15.263 --> 00:03:17.300
它基本上
变得很难。

00:03:17.300 --> 00:03:21.578
>> 好了，我知道当时我正
使用.NET 的组合

00:03:21.578 --> 00:03:24.190
框架和.NET 核心 1.x。

00:03:24.190 --> 00:03:25.920
>> 的权限。
>> 种之前所有这些

00:03:25.920 --> 00:03:27.350
完全着陆。

00:03:27.350 --> 00:03:29.460
我做一些文件 IO。

00:03:29.460 --> 00:03:30.750
我认为它是一个文件流，

00:03:30.750 --> 00:03:33.820
实际上我是在文件中
具有流读取器的流和

00:03:33.820 --> 00:03:38.810
没有一种重要方法
我真正需要的

00:03:38.810 --> 00:03:42.290
和我正在使用它
在.Net framework 中，

00:03:42.290 --> 00:03:46.010
然后我通过复制代码
对核心 x 和它不起作用。

00:03:46.010 --> 00:03:47.730
然后，我省略了不高兴。

00:03:49.220 --> 00:03:55.470
幸运的是，过一些时间，
然后我又试着恢复，

00:03:55.470 --> 00:03:59.500
与.NET 核心的同一个练习
2.0 版，且该 API 没有。

00:03:59.500 --> 00:04:02.630
而且我快乐，和
我只是没有带我的工作。

00:04:02.630 --> 00:04:04.390
因此，肯定有
这一经验。

00:04:04.390 --> 00:04:06.510
>> 是，因此这正是
问题，对吗？

00:04:06.510 --> 00:04:09.540
如果您将拉上一个类
库，它是同样的事情。

00:04:09.540 --> 00:04:11.990
不同之处在于它为偶数
越复杂。

00:04:11.990 --> 00:04:14.780
>> 我太想其他的事情
是的像这样的代码，

00:04:14.780 --> 00:04:18.650
我已经，我已
已使用最佳的 API。

00:04:18.650 --> 00:04:21.510
它不像我想象中，

00:04:21.510 --> 00:04:23.760
也许一些好的方法
这我不知道。

00:04:23.760 --> 00:04:25.920
我知道我使用的
最佳的模式。

00:04:25.920 --> 00:04:30.020
我是同样苦恼
因为我不得不做

00:04:30.020 --> 00:04:32.900
是该我从根本上
相信已更糟。

00:04:32.900 --> 00:04:34.250
>> 是。

00:04:34.250 --> 00:04:36.610
>> 所幸的是与此新
不再是这种情况的模型。

00:04:36.610 --> 00:04:37.570
>> 的权利。

00:04:37.570 --> 00:04:40.586
所以当我们现在
有关.NET 标准思考什么

00:04:40.586 --> 00:04:43.486
实际上它基本上
在本质上是统一的尝试

00:04:43.486 --> 00:04:46.270
不该基图层
不再拥有丰富的经验

00:04:46.270 --> 00:04:49.228
其中执行平台的决定
小段的内容过期

00:04:49.228 --> 00:04:51.729
而且再没有一种方法
执行此操作的正确方法。

00:04:51.729 --> 00:04:54.764
因此，您可以将新的
net 实际上是作为标准

00:04:54.764 --> 00:04:56.220
一个 bcl 仅把它们全部，

00:04:56.220 --> 00:04:58.118
我认为，我们说过
这许多的时间。

00:04:58.118 --> 00:05:02.120
但基本上是以逻辑方式
Api 的一套，实际上每个

00:05:02.120 --> 00:05:05.519
.NET 平台应具有，
因为它们是真的

00:05:05.519 --> 00:05:08.466
基础部分
如 I/O 集合

00:05:08.466 --> 00:05:09.976
在控制台中访问

00:05:09.976 --> 00:05:13.250
基本上在做的东西
较低级别的库。

00:05:13.250 --> 00:05:15.026
并由较低级别
如非应用程序的真正含义是

00:05:15.026 --> 00:05:16.150
特定的东西，正确吗？

00:05:16.150 --> 00:05:17.480
业务逻辑进入脑海，

00:05:17.480 --> 00:05:18.920
数据访问层
进入脑海。

00:05:18.920 --> 00:05:22.190
>> 但
此外，还有一个用户承诺。

00:05:22.190 --> 00:05:24.130
开发人员对它的承诺方面。

00:05:24.130 --> 00:05:25.090
>> 的权限。

00:05:25.090 --> 00:05:27.439
这主要是他们做的
在.NET 中放置的一切

00:05:27.439 --> 00:05:31.450
标准将转
今后的任何地方。

00:05:31.450 --> 00:05:32.949
然后我们将讨论一下
有关版本控制的详细信息，

00:05:32.949 --> 00:05:33.660
它的工作原理一般。

00:05:33.660 --> 00:05:35.494
但这一想法是，
有自己的标准

00:05:35.494 --> 00:05:37.890
版本号，因为我们
没有一台时间机器。

00:05:37.890 --> 00:05:40.620
我们不能对抗
添加五年前的 API

00:05:40.620 --> 00:05:41.730
不起作用。

00:05:41.730 --> 00:05:44.230
因此当我们添加新的 API 的作为
新版本的标准，但

00:05:44.230 --> 00:05:46.520
预期结果是，所有
最终将移动平台

00:05:46.520 --> 00:05:48.580
到新的版本，它们
永远不会停滞的版本。

00:05:48.580 --> 00:05:49.240
>> 的权限。

00:05:49.240 --> 00:05:50.530
>> 因此
您无法分叉过程使实质上，

00:05:50.530 --> 00:05:53.070
总是，
您总是向前移动，

00:05:53.070 --> 00:05:54.630
一致性挂钩
随着时间的推移向上。

00:05:54.630 --> 00:05:57.970
>> 您所知，我知道
人都有一台时间机器。

00:05:57.970 --> 00:05:59.220
是吗？

00:05:59.220 --> 00:06:03.190
>> 是，因此，它是极好的
>> 我们应该雇用的家伙。

00:06:03.190 --> 00:06:05.780
>> 是，实际上，
现在是一位女士。

00:06:05.780 --> 00:06:07.180
>> 我猜也是如此。

00:06:07.180 --> 00:06:08.570
再次是他的名字什么？

00:06:08.570 --> 00:06:09.670
或她的姓名吗？
[笑声]

00:06:09.670 --> 00:06:11.130
>> 很好，它仍然是时

00:06:11.130 --> 00:06:12.440
我认为相同的名称。

00:06:13.560 --> 00:06:16.190
她说在 12 月。

00:06:16.190 --> 00:06:17.110
>> 很好。
>> 是，冷却。

00:06:18.920 --> 00:06:21.440
那么的区别是什么
我们完成发送到

00:06:21.440 --> 00:06:24.270
作为上一张图片
像是只有一个 BCL。

00:06:24.270 --> 00:06:26.790
我要说它不是维恩图
因为它只真正的关系图

00:06:26.790 --> 00:06:29.310
一件事情恢复
数字隐藏，

00:06:29.310 --> 00:06:31.790
这就是比更容易
重叠

00:06:31.790 --> 00:06:34.630
图中的多个圆
>> 肯定。

00:06:34.630 --> 00:06:37.290
>>，然后其它的事情
曾指出，与

00:06:37.290 --> 00:06:39.600
我们已经添加了许多详细的 Api，并
我有了上的一张幻灯片，

00:06:39.600 --> 00:06:42.192
但基本上我们真的尝试
使通用 dominator 大。

00:06:42.192 --> 00:06:45.481
与笔记本电脑喜欢我们
只是我们必须建模

00:06:45.481 --> 00:06:47.900
这是很大程度上达不到最佳。

00:06:47.900 --> 00:06:51.444
但现在我们实际上去的
我们的方法，以确保我们将放

00:06:51.444 --> 00:06:56.400
我们认为是合理的
这就是很大。

00:06:56.400 --> 00:06:57.830
我们只需填写的间隙

00:06:57.830 --> 00:06:59.610
不要的平台
有这些 Api。

00:06:59.610 --> 00:07:01.660
而不是另
解决的方法。

00:07:01.660 --> 00:07:02.830
因此客户承诺，

00:07:02.830 --> 00:07:04.760
实际上您也可以
以标准为目标。

00:07:04.760 --> 00:07:07.374
和它承诺可以运行
任何地方在该版本的

00:07:07.374 --> 00:07:08.690
支持标准。

00:07:10.220 --> 00:07:11.750
>> 的权限。
因此，您可能还记得在

00:07:11.750 --> 00:07:14.631
小学学习
小公分。

00:07:14.631 --> 00:07:15.850
>> 是。

00:07:15.850 --> 00:07:19.620
>> 我有点觉得 PCL
我们所做的项目是有点

00:07:19.620 --> 00:07:23.110
最小公
分母项目。

00:07:23.110 --> 00:07:26.859
这一个，我认为坦率
实际上就像一个大的公共

00:07:26.859 --> 00:07:28.276
分母项目

00:07:28.276 --> 00:07:30.920
尤其是与
.NET 标准 2.0。

00:07:30.920 --> 00:07:31.990
您认为这是公平吗？

00:07:31.990 --> 00:07:33.130
>> 是的我认为对我来说，

00:07:33.130 --> 00:07:36.080
区别是
更多的 intentionality。

00:07:36.080 --> 00:07:37.890
PCL 模型是我们的了。

00:07:37.890 --> 00:07:39.060
因此事后比较。

00:07:39.060 --> 00:07:40.532
每一种平台吗
他们希望的任何内容。

00:07:40.532 --> 00:07:43.062
然后，我们提供了工具和
它不得不模型什么

00:07:43.062 --> 00:07:43.671
已存在。

00:07:43.671 --> 00:07:46.015
与我们所说标准
这是我们的希望，

00:07:46.015 --> 00:07:48.605
现在，让我们确保所有
东西有，因此

00:07:48.605 --> 00:07:51.083
我们透支我们的思考
设置适当的 API。

00:07:51.083 --> 00:07:53.903
>> 是一回事我有时
告诉人们，我通常会获得

00:07:53.903 --> 00:07:56.913
空白 stares 上，如此重要的主题
谈及这段视频。

00:07:56.913 --> 00:07:57.621
>>，听起来很好。

00:07:57.621 --> 00:08:02.422
>> 是，使用 PCL，所有
与超配置文件

00:08:02.422 --> 00:08:05.634
名称是所有
由计算机生成。

00:08:05.634 --> 00:08:10.531
因此有了没有人认为
在中创建的那些涉及

00:08:10.531 --> 00:08:11.580
配置文件。

00:08:11.580 --> 00:08:13.189
>> 的权利。

00:08:13.189 --> 00:08:15.240
>> 的超级特殊的声音。

00:08:15.240 --> 00:08:18.420
这就是区别
使用与此在的

00:08:18.420 --> 00:08:20.560
单词 intentionality 中。

00:08:20.560 --> 00:08:23.580
因此，没有人的思维
基本上在涉及到

00:08:23.580 --> 00:08:26.910
每一个成员的我们
被拉到.NET 标准。

00:08:28.060 --> 00:08:30.710
因此，是意味着现在您
具有人类怪。

00:08:30.710 --> 00:08:33.310
>> [发笑]
>>，但我认为这是巨大的

00:08:33.310 --> 00:08:34.830
巨大的差异。

00:08:34.830 --> 00:08:35.870
>> 我也认为如此。

00:08:38.860 --> 00:08:39.700
因此，然后是什么标准？

00:08:39.700 --> 00:08:40.690
我的意思是这就是通常的事情。

00:08:40.690 --> 00:08:42.910
这一切听起来很好当您
有喜欢这样抽象关系图

00:08:42.910 --> 00:08:45.020
真的什么总结
Visual Studio 中是

00:08:45.020 --> 00:08:47.340
当您做有趣的新项目则
这里有此新类别

00:08:47.340 --> 00:08:48.830
调用.NET 标准和

00:08:48.830 --> 00:08:51.140
它有一个模板到
跨库.NET 标准。

00:08:51.140 --> 00:08:54.390
因此，一个项目
您可以创建的类型。

00:08:54.390 --> 00:08:56.420
这就是机械
拼凑到它。

00:08:56.420 --> 00:08:58.150
和一块可操作
您日期的今天。

00:08:58.150 --> 00:09:00.863
第二部分，
它是一种规范因此

00:09:00.863 --> 00:09:02.682
它是本质上是一组 Api。

00:09:02.682 --> 00:09:06.426
我们说所有平台都应
实现这些 Api，这样一种方法

00:09:06.426 --> 00:09:09.295
思考是你可以的
>> 只是可以是错的了

00:09:09.295 --> 00:09:09.831
一段时间吗？

00:09:09.831 --> 00:09:11.421
>> 是的很自然地说。

00:09:11.421 --> 00:09:12.263
>> 是的很自然地说。

00:09:12.263 --> 00:09:13.790
返回到其他幻灯片。

00:09:13.790 --> 00:09:14.300
>> 是。

00:09:14.300 --> 00:09:16.990
>> 所以这是小
一些笑话，但

00:09:16.990 --> 00:09:21.780
我认为人们会问，
我是在.NET 标准的节点中，

00:09:21.780 --> 00:09:23.770
我看到交叉库
.NET 标准。

00:09:23.770 --> 00:09:27.260
为什么看.NET
框架 4.5.2 存在吗？

00:09:27.260 --> 00:09:28.220
>> 您的意思是下拉列表
在顶部？

00:09:28.220 --> 00:09:30.900
>> 是的我只是感觉这样的
若要引人注意的事物。

00:09:30.900 --> 00:09:33.960
>> 是，因此，这基本上是
我第一次的最终结果

00:09:33.960 --> 00:09:35.850
滑动时我说过，我们习惯
.NET 框架和

00:09:35.850 --> 00:09:37.210
世界上是很好。

00:09:37.210 --> 00:09:38.820
因此我们说，
如果您无法，就好

00:09:38.820 --> 00:09:41.370
选择的版本编号
之前创建的模板。

00:09:41.370 --> 00:09:44.930
并在以后也许更添加
在像 [INAUDIBLE] 的.NET 口味

00:09:44.930 --> 00:09:46.710
也有些点。

00:09:46.710 --> 00:09:49.350
类似的下降下丢失了很多
它是值，可能应

00:09:49.350 --> 00:09:52.180
在最底部和
将选择的名称。

00:09:52.180 --> 00:09:54.889
并且应该对敏感
它是方向性模板，但

00:09:54.889 --> 00:09:56.694
该对话框只是
不表示，

00:09:56.694 --> 00:09:57.768
遗憾的是今天。

00:09:57.768 --> 00:10:01.207
>>，您认为这是
未来对我有意义。

00:10:01.207 --> 00:10:03.095
>> 是。
>> 您认为，在以往任何时候都将吗

00:10:03.095 --> 00:10:03.637
发生这种情况？

00:10:03.637 --> 00:10:04.985
我当然希望如此。

00:10:04.985 --> 00:10:05.986
>> 是。
>> 之前所说过

00:10:05.986 --> 00:10:08.303
我认为这整个 twitter，
对话需要检修。

00:10:08.303 --> 00:10:10.154
>> 是。
>> 有就得有点太多了

00:10:10.154 --> 00:10:12.706
选择和不是的名称
一定是反射

00:10:12.706 --> 00:10:14.600
您的想法关于
目前世界。

00:10:14.600 --> 00:10:15.470
>> 是，确定。

00:10:16.530 --> 00:10:17.700
>> 是，这就是的。

00:10:17.700 --> 00:10:19.380
那么我们思考
规范部分。

00:10:19.380 --> 00:10:21.420
因此，如果您认为标准的
作为一种规范，

00:10:22.660 --> 00:10:23.920
很好的类比是 HTML。

00:10:23.920 --> 00:10:26.162
HTML 是一个规范，并
然后是浏览器。

00:10:26.162 --> 00:10:27.673
因此，我们实施这些规范。

00:10:27.673 --> 00:10:30.788
没有边缘、 镶边和每个
这些浏览器的一个基本上

00:10:30.788 --> 00:10:32.756
为另一种对齐
规范的版本。

00:10:32.756 --> 00:10:34.603
以相同的方式，但它
发生.NET 标准。

00:10:34.603 --> 00:10:36.603
这样的标准是
实质上的 HTML 规范，并

00:10:36.603 --> 00:10:39.303
然后浏览器的等效项
基本上是具体.NET

00:10:39.303 --> 00:10:41.703
如实现平台
.NET 系列，.NET 核心

00:10:41.703 --> 00:10:42.516
Xamarin，完全一致。

00:10:42.516 --> 00:10:46.310
以及无论我们可能
在以后创建。

00:10:46.310 --> 00:10:50.380
因此，这是非常好
有的心理图片。

00:10:50.380 --> 00:10:51.858
因此，正如我前面所说，

00:10:51.858 --> 00:10:55.500
我们打算在真正被试与 2.0
添加许多备份多个 Api。

00:10:55.500 --> 00:10:59.143
事实上，我们添加了约 20000
与.NET 标准的 Api，

00:10:59.143 --> 00:11:03.130
1.x 或 1.6，是
为 1 x 系列的最高版本。

00:11:03.130 --> 00:11:05.693
我们到达它的方式
号是我们基本上是说，

00:11:05.693 --> 00:11:07.598
那么，什么是最大值
我们可以想像吗？

00:11:07.598 --> 00:11:10.628
我们可以最大
构想是采用.NET 框架

00:11:10.628 --> 00:11:13.058
并采取 Xamarin，和
模具的交集。

00:11:13.058 --> 00:11:15.148
因为这本质上是
良好的代理

00:11:15.148 --> 00:11:17.073
可能是的 Api
跨平台的但

00:11:17.073 --> 00:11:19.937
它们仍然非常类似于
.NET 框架的准备。

00:11:19.937 --> 00:11:21.587
然后我们还添加了几
仅中的 Api

00:11:21.587 --> 00:11:23.280
.NET 框架，
没有 Xamarin，和

00:11:23.280 --> 00:11:24.367
问他们来实现它们。

00:11:24.367 --> 00:11:27.825
因此我们不需要
Franken 集实质上。

00:11:27.825 --> 00:11:31.508
>> 基本上如果我们转
与简单的情况下，

00:11:31.508 --> 00:11:36.189
你提到交集
.NET 框架，即 4.7 和

00:11:36.189 --> 00:11:39.413
最新版本，单声道，
尚没有的交集

00:11:39.413 --> 00:11:42.350
在.NET 核心
大约 20000 Api。

00:11:42.350 --> 00:11:43.683
>> 解决，因此，大多数我们的工作-
>> 的巨大。

00:11:43.683 --> 00:11:45.610
>> 不 revving 规范。

00:11:45.610 --> 00:11:48.990
大部分然后是工作的
在核上实现此回。

00:11:48.990 --> 00:11:51.229
框架是由构造
已经支持。

00:11:51.229 --> 00:11:53.333
Xamarin 必须添加
很少的 Api。

00:11:53.333 --> 00:11:55.859
我认为它可能是小于
100 问到 Xamarin 我们的 Api

00:11:55.859 --> 00:11:56.390
实现。

00:11:57.660 --> 00:12:00.240
没错，我们有 20000 Api
我们必须添加到核心，

00:12:00.240 --> 00:12:02.479
因此，批量
我们工作。

00:12:04.810 --> 00:12:06.592
>> 我撰写这些
对 UWP 也。

00:12:06.592 --> 00:12:07.677
>> 更正，

00:12:07.677 --> 00:12:10.390
UWP，第一张幻灯片，
它有什么样的通常向上与.NET

00:12:10.390 --> 00:12:12.305
核心，因为它们比较
同时从相同的基本代码。

00:12:12.305 --> 00:12:14.064
>> 毫米 hm。
>> 使他们得不到它的

00:12:14.064 --> 00:12:17.523
因为不幸的是，自由
UWP 具有不同的运行时

00:12:17.523 --> 00:12:19.931
比环境
正常的 Windows 执行。

00:12:19.931 --> 00:12:22.888
因此没有发生的工作
若要添加支持的应用程序的操作系统

00:12:22.888 --> 00:12:24.380
容器及其所有。

00:12:24.380 --> 00:12:27.298
但他们当然也会
获得相同的 API，面。

00:12:27.298 --> 00:12:28.311
我们将寄送今年晚些时候。

00:12:28.311 --> 00:12:30.420
我并不认为他们宣布
然而，对日期？

00:12:30.420 --> 00:12:32.003
它会。

00:12:32.003 --> 00:12:35.307
第二件事是，我猜，
另一个有趣的 tidbit，

00:12:35.307 --> 00:12:38.119
当您尝试创建一组
与一个轴，库的

00:12:38.119 --> 00:12:41.299
您通常会遇到此问题
复制时将首先要弄

00:12:41.299 --> 00:12:44.550
您自己的代码，还有吨
api，漏出。

00:12:44.550 --> 00:12:45.570
但这是在控件中。

00:12:45.570 --> 00:12:47.260
您可以重构您的代码。

00:12:47.260 --> 00:12:49.099
可能有大量的工作，
但是，您可以做到。

00:12:49.099 --> 00:12:51.233
通常在故事结尾，
不过，

00:12:51.233 --> 00:12:54.245
您具有的依赖关系
第三方库

00:12:54.245 --> 00:12:55.952
则其他人将提供给您。

00:12:55.952 --> 00:12:59.142
认为 X 单位
例如或 JSON.net，或

00:12:59.142 --> 00:13:01.222
无论您实际使用。

00:13:01.222 --> 00:13:03.574
和多数
Nuget 在库今天不是

00:13:03.574 --> 00:13:04.707
设定标准。

00:13:04.707 --> 00:13:06.417
他们仍然目标
.NET framework 中，

00:13:06.417 --> 00:13:08.487
因为这就是事情
这就是围绕为这么长时间。

00:13:08.487 --> 00:13:09.715
因此，我们的问题是，

00:13:09.715 --> 00:13:11.190
好了，我们是如何
这使平滑？

00:13:11.190 --> 00:13:13.592
我们如何使它更容易
到端口到端口的其他人？

00:13:13.592 --> 00:13:16.262
因此 [INAUDIBLE] 我们所说的
兼容性填充程序或

00:13:16.262 --> 00:13:19.585
兼容模式，其主要
允许您引用 Nuget

00:13:19.585 --> 00:13:22.980
程序包的实际仅
今天在.NET 框架上运行。

00:13:22.980 --> 00:13:25.727
和我们想要转出的我们
方法在.NET 上使其奏效

00:13:25.727 --> 00:13:26.355
标准。

00:13:26.355 --> 00:13:27.323
广义上，

00:13:27.323 --> 00:13:30.113
实现任何平台
.NET 标准 2.0。

00:13:30.113 --> 00:13:32.585
演示与 l 了
可能稍作解释

00:13:32.585 --> 00:13:34.766
好，但我们的想法
它是最好的投入。

00:13:34.766 --> 00:13:37.037
因此，我们不知道什么
库执行。

00:13:37.037 --> 00:13:39.123
如果它使用 Win 的窗体
示例中，

00:13:39.123 --> 00:13:41.896
它将无法运行命令
在 Linux 上很明显。

00:13:41.896 --> 00:13:46.328
但大多数库的我们
Nuget 上发现约 70%是 API

00:13:46.328 --> 00:13:49.111
可比我们
在.NET 2.0。

00:13:49.111 --> 00:13:51.985
因此，在实践中，大部分
时间，当您升级和

00:13:51.985 --> 00:13:54.736
您只需引用现有的
framework 程序包

00:13:54.736 --> 00:13:57.200
它可能只是将正常工作。

00:13:57.200 --> 00:13:59.970
>> 右侧，所以我发出警告
这 emptor 性质。

00:13:59.970 --> 00:14:01.166
>> 是。
>> 作为用户，

00:14:01.166 --> 00:14:06.352
将超如果我
可以说，我目前

00:14:06.352 --> 00:14:11.888
被废弃使用 Nuget 打包
确实不应该出现这种情况

00:14:11.888 --> 00:14:16.983
我有去探索
完全由我自己来。

00:14:16.983 --> 00:14:19.107
如果此 70%桶，

00:14:19.107 --> 00:14:22.578
有任何列表任何地方
我无法转看一看吗？

00:14:22.578 --> 00:14:24.361
>> 您的意思是像的列表
新 Nuget 程序包的我们

00:14:24.361 --> 00:14:25.550
知道会起作用吗？

00:14:25.550 --> 00:14:26.485
>> 是。

00:14:26.485 --> 00:14:28.006
>> 没有，我并不认为
我们今天有一个列表。

00:14:28.006 --> 00:14:29.814
这实际上是
一个很好的建议。

00:14:29.814 --> 00:14:30.821
我们也许应该列表。

00:14:30.821 --> 00:14:31.801
>> 是。

00:14:31.801 --> 00:14:34.441
>> 其他要做的事情
想要到达 Nuget

00:14:34.441 --> 00:14:34.991
作者和

00:14:34.991 --> 00:14:37.930
积极鼓励他们到
以本机方式支持.NET 标准。

00:14:37.930 --> 00:14:39.070
尤其是当他们是

00:14:39.070 --> 00:14:41.000
已经事实上
它的兼容吗。

00:14:41.000 --> 00:14:43.670
只是需要一个明确的步骤
可以说，是的包上

00:14:43.670 --> 00:14:45.490
我支持它在.NET 2.0。

00:14:45.490 --> 00:14:48.132
因此，这是还意图性更强
包作者侧。

00:14:48.132 --> 00:14:50.669
>> 啊，
如果我们进一步战略，

00:14:50.669 --> 00:14:54.222
这表明，我们所说的
这些都是 100

00:14:54.222 --> 00:14:58.301
最受欢迎的库，
只有.NET 框架。

00:14:58.301 --> 00:14:59.800
依赖项，并
动身去找他们。

00:14:59.800 --> 00:15:01.187
>> 是。
>> 有想过您的团队

00:15:01.187 --> 00:15:01.879
呢？

00:15:01.879 --> 00:15:04.745
>> 是的我的意思是，您应该知道
他是我的老板，因此他是什么

00:15:04.745 --> 00:15:07.450
基本上告诉我右边
现在是我应该这样做。

00:15:07.450 --> 00:15:08.580
>> 将其在磁带上。

00:15:08.580 --> 00:15:09.940
>> 将其在磁带上，
它现在是公共。

00:15:11.840 --> 00:15:15.410
我们实际上做了这，我们一起

00:15:15.410 --> 00:15:17.730
与该数字通过基本上
做您刚才所说。

00:15:17.730 --> 00:15:21.060
我们所做的整个分析
在 NuGet 程序包。

00:15:21.060 --> 00:15:23.050
没有实际的视频，
我指导您完成的牌

00:15:23.050 --> 00:15:24.570
我们拥有的所有结果。

00:15:24.570 --> 00:15:25.210
我们还没有做，

00:15:25.210 --> 00:15:27.090
因为它是更多的
定量的工作量。

00:15:27.090 --> 00:15:28.670
我们还没有真正
深化这问题。

00:15:28.670 --> 00:15:31.870
实际上我们只被讨论，
但也有少数高配置文件

00:15:31.870 --> 00:15:34.025
我们实际上最终的包
直接向提交 PRs 向上的

00:15:34.025 --> 00:15:34.640
>> [串扰}

00:15:34.640 --> 00:15:35.660
这实际上是更好。

00:15:35.660 --> 00:15:38.400
>> 为实际解决办法和
internatively 中添加奖金。

00:15:38.400 --> 00:15:40.550
>> 和那些 PRs 是否接受？

00:15:40.550 --> 00:15:41.540
>> 大部分时间，是的。

00:15:41.540 --> 00:15:44.720
某些情况下它是
不同于增量 1x

00:15:44.720 --> 00:15:47.930
Cobra 是很大，
和人们没有感觉

00:15:47.930 --> 00:15:51.790
这种方法似乎很多像
在我共同付款的中断。

00:15:51.790 --> 00:15:54.490
大多数情况下是 2.0，您将添加
您 NuGet 到另一个文件夹

00:15:54.490 --> 00:15:56.800
包，和
这就是这么多了。

00:15:58.230 --> 00:15:59.570
具体方法取决于您
生成项目时，

00:15:59.570 --> 00:16:02.400
您可能会添加 T-克
向项目太，因此

00:16:02.400 --> 00:16:04.840
您将收到编译
以及时检查。

00:16:04.840 --> 00:16:08.680
但它是一个非常小的筛选器
在多数情况下为 2.0。

00:16:08.680 --> 00:16:10.810
因此，2.0 更改主要是
接受，我认为 [INAUDIBLE]。

00:16:10.810 --> 00:16:13.970
>> 右侧，使它更
更轻松的对话

00:16:13.970 --> 00:16:14.497
与维护员。

00:16:16.670 --> 00:16:18.950
>> 好了，
足够多的幻灯片，

00:16:18.950 --> 00:16:21.260
我们实际上看演示一下。

00:16:21.260 --> 00:16:22.470
所以，我这里有很

00:16:22.470 --> 00:16:25.380
遗憾的是字体
并不令人惊奇，但

00:16:25.380 --> 00:16:27.660
您可以在希望看到
视频屏幕很有效。

00:16:28.790 --> 00:16:30.647
因此，基本上，我们拥有什么
这是罗斯，和

00:16:30.647 --> 00:16:32.096
开发机构的任何人的

00:16:32.096 --> 00:16:33.920
很长时间了
罗斯文的意识。

00:16:33.920 --> 00:16:35.180
同样，
我在这里，有一个非常简单的应用程序

00:16:35.180 --> 00:16:41.460
它是 Windforms 应用程序，并且您
可以清楚地告诉我一个设计器，

00:16:41.460 --> 00:16:44.720
因为当我更改大小
此处的按钮粘滞

00:16:44.720 --> 00:16:47.120
底部右角因此
我未那里一个确实好作业。

00:16:47.120 --> 00:16:50.470
但基本上所有我做的
是加载部分中的数据

00:16:50.470 --> 00:16:54.170
罗斯和寻找
到目前为止，已退休的人

00:16:54.170 --> 00:16:56.580
因此，可以判断
[发笑] 此数据。

00:16:56.580 --> 00:16:57.866
关键的一点是，

00:16:57.866 --> 00:17:00.550
我实际的数据库
现在右不是 SQL。

00:17:00.550 --> 00:17:03.820
它实际上使用数据集，
这是我们的地图

00:17:03.820 --> 00:17:06.140
数据库表示形式
在一个 x 天。

00:17:06.140 --> 00:17:07.770
>> 可以或许放大吗
它在只是稍有吗？

00:17:07.770 --> 00:17:10.167
>> 我可以我想。

00:17:14.228 --> 00:17:15.944
150 也许可能是
甚至更好。

00:17:15.944 --> 00:17:17.160
来吧。

00:17:17.160 --> 00:17:18.770
因此，您可以看到的内容和
这是从根本上说，所有我做的

00:17:18.770 --> 00:17:23.210
是我刚才创建的数据集，
从文件加载它坚定

00:17:23.210 --> 00:17:24.660
与像硬编码路径。

00:17:24.660 --> 00:17:26.810
像，真的很棒
filament 在我身边的故事。

00:17:26.810 --> 00:17:27.980
我只是寻找
已退休的人员。

00:17:27.980 --> 00:17:29.640
对吧？

00:17:29.640 --> 00:17:32.950
生日快乐，再加上 65 年来，这
是一般的退休年龄。

00:17:32.950 --> 00:17:35.084
我认为时代，
很可能像，40。

00:17:35.084 --> 00:17:36.374
>> [发笑] 是。

00:17:36.374 --> 00:17:37.750
>> 我听说美国是更像，
120。

00:17:37.750 --> 00:17:38.810
>> 是 [笑声]。

00:17:38.810 --> 00:17:40.010
>> 因此，参数化的。

00:17:40.010 --> 00:17:42.890
但基本上这里只搜索
有关的这只显示的。

00:17:44.150 --> 00:17:45.730
那么，为什么它
与.NET 标准？

00:17:45.730 --> 00:17:48.260
因此，他们只是有其中一种
我们认为原有的 API

00:17:48.260 --> 00:17:50.370
基本上我们
移动从一个 x。

00:17:50.370 --> 00:17:53.850
但出人结果可能不会
在爱与数据集，

00:17:53.850 --> 00:17:56.658
但事实是你甚至
对有较少在爱

00:17:56.658 --> 00:17:58.800
重构来摆脱它。

00:17:58.800 --> 00:18:00.610
>> 肯定，和我们所做的。

00:18:00.610 --> 00:18:01.530
相当多的反馈。

00:18:01.530 --> 00:18:04.230
>> 是，并且还没有大量的
实际上是非常有用的东西。

00:18:04.230 --> 00:18:06.115
因此，现在，我将做
是我将创建一个新项目。

00:18:06.115 --> 00:18:09.926
我会转到.NET 中心
我们已经讨论过，类别

00:18:09.926 --> 00:18:13.191
选择在中心和
然后，我们将把它，

00:18:13.191 --> 00:18:15.230
让我们假设，罗斯文数据库的数据。

00:18:17.925 --> 00:18:19.770
Deta 已经创建了两个他们
显然之前的项目。

00:18:20.800 --> 00:18:22.370
>> 过这样的事情，不堪回首。

00:18:22.370 --> 00:18:24.050
>> 完全相同，因此。

00:18:24.050 --> 00:18:25.270
然后
类，只需删除

00:18:25.270 --> 00:18:29.050
然后我只是将我
数据访问逻辑，现在，和

00:18:29.050 --> 00:18:32.590
只需将它移到
到我的新项目。

00:18:32.590 --> 00:18:33.910
>> 很好。

00:18:33.910 --> 00:18:35.580
>> 因此，现在，
在这里，我可以和

00:18:35.580 --> 00:18:37.690
可以判断有
没有波形曲线。

00:18:37.690 --> 00:18:39.080
一切都只是正常工作。

00:18:40.200 --> 00:18:42.384
如果实际转到
项目属性

00:18:42.384 --> 00:18:44.624
您发现我们的目标
.NET 标准 2.0 中，

00:18:44.624 --> 00:18:46.550
是因为它是我们的默认为。

00:18:46.550 --> 00:18:47.450
>> 是。

00:18:47.450 --> 00:18:50.130
>> 如果我将它切换至一个 x，
您将得到吨的波形曲线。

00:18:51.780 --> 00:18:53.210
因此，现在，
我们拥有现代的代码基，

00:18:53.210 --> 00:18:55.050
不完全对，
它使之现代化一点，

00:18:55.050 --> 00:19:00.700
没有所有这些显式
类型，所以，我这样做呢。

00:19:00.700 --> 00:19:02.200
现在，我看到了 var 无处不在。

00:19:02.200 --> 00:19:05.030
它真的非常棒，我知道，
它显然是一个现代的代码库。

00:19:05.030 --> 00:19:06.030
>> 肯定。
>> [发笑]。

00:19:06.030 --> 00:19:08.180
>> 这是一个，
向右，凯西不喜欢吗？

00:19:08.180 --> 00:19:10.570
>> 完全正确，nevar 人吗？

00:19:10.570 --> 00:19:11.870
>> 是。

00:19:11.870 --> 00:19:14.830
>> 因此，现在，我们有，但是
现在，让我们来实际扩展这

00:19:14.830 --> 00:19:19.540
并说，我并不感兴趣
此硬编码查找此处。

00:19:19.540 --> 00:19:22.500
因此，我做的什么
大约十年前，

00:19:22.500 --> 00:19:25.200
我认为，我编写了一个 SQL 引擎
实际上可以使您

00:19:25.200 --> 00:19:28.150
-\-

00:19:29.570 --> 00:19:31.870
因此，我们实际上
这里，我的媒体库中添加。

00:19:31.870 --> 00:19:34.140
因此，我只是转到
我 NuGet 程序包。

00:19:34.140 --> 00:19:37.870
搜索
NuGet 在我的媒体库。

00:19:37.870 --> 00:19:39.180
找到我的媒体库。

00:19:39.180 --> 00:19:42.469
您可以在此处告诉上载的 2012年。

00:19:42.469 --> 00:19:44.220
>> 是静止时
有空闲时间吗？

00:19:44.220 --> 00:19:45.410
>> 这是当我
仍然有闲暇时间，

00:19:45.410 --> 00:19:48.180
因为我之前工作的您，
现在我没有业余时间。

00:19:48.180 --> 00:19:50.630
>> 啊，
在某一时刻也出差。

00:19:50.630 --> 00:19:51.180
>> 的太真。

00:19:52.640 --> 00:19:53.560
因此，安装此事。

00:19:56.200 --> 00:20:00.008
它成功，但是，
我们现在在生成时。

00:20:00.008 --> 00:20:03.987
我们查看错误列表
我们可以看到一条警告此处。

00:20:03.987 --> 00:20:05.399
并警告说，

00:20:05.399 --> 00:20:08.902
[听不到] 已还原
使用.NET framework 461。

00:20:08.902 --> 00:20:11.750
而不是目标框架
.NET 标准版 2.0。

00:20:11.750 --> 00:20:13.170
那么，为什么是。

00:20:13.170 --> 00:20:16.784
好吧，如果我们只是转到
[听不到].org，我们只是

00:20:16.784 --> 00:20:21.466
搜索我的包在这里，和
我们只需下载程序包。

00:20:24.572 --> 00:20:26.803
当我们打开这包中
很非常明显的资源管理器

00:20:26.803 --> 00:20:28.260
问题是什么。

00:20:28.260 --> 00:20:30.800
如果我看起来在唇
从 2012年的文件夹，我认为，

00:20:30.800 --> 00:20:34.241
最初获得的奖励
2005-2006 年时间范围内的事情。

00:20:34.241 --> 00:20:36.694
因此，这是当.NET
2.0 是所有天花乱坠的广告宣传因此

00:20:36.694 --> 00:20:38.300
这就是我所确定的目标。

00:20:38.300 --> 00:20:41.628
因此，它没有任何 PCL，
不只是.NET 标准

00:20:41.628 --> 00:20:43.747
一个很好的旧.NET 框架和
二进制文件。

00:20:43.747 --> 00:20:45.460
>> 您可能想要给予
为快速出惊呼

00:20:45.460 --> 00:20:46.582
此应用程序是什么。

00:20:46.582 --> 00:20:48.478
>> 是，这是，
获取包资源管理器

00:20:48.478 --> 00:20:50.380
它是真正的
Windows 应用商店。

00:20:50.380 --> 00:20:52.730
如果您只需转到存储
您可以那里搜索它。

00:20:52.730 --> 00:20:54.421
它允许您打开
新获得的包，

00:20:54.421 --> 00:20:57.008
浏览这些可以看到，我的意思是，
他们只是 zip 文件，但

00:20:57.008 --> 00:20:59.740
这是有点好多了因为
您将看到下面的元数据。

00:20:59.740 --> 00:21:01.860
>> 我肯定使用此
应用程序的多个时间一周，

00:21:01.860 --> 00:21:02.910
您可能使用它每一天。

00:21:02.910 --> 00:21:04.543
>> 是。
每次我做演示时

00:21:04.543 --> 00:21:05.276
至少 [笑声]。

00:21:05.276 --> 00:21:08.580
>> [发笑]
>> 因此，我们有，和

00:21:08.580 --> 00:21:11.480
现在我们的可以是，
我现在可以重新使用我的媒体库。

00:21:11.480 --> 00:21:15.680
因此，让我去掉所有的
我的硬件逻辑此处。

00:21:15.680 --> 00:21:21.987
如果无法找到一种方法
使用鼠标 [笑声]。

00:21:21.987 --> 00:21:26.770
也许不是，
也许它会这样做。

00:21:28.200 --> 00:21:32.490
然后，我们只是删除
在这里，所有这些东西，

00:21:32.490 --> 00:21:34.850
然后，而是放下
在一些知识。

00:21:34.850 --> 00:21:39.060
因此，它使用库
足够用来添加使用此

00:21:39.060 --> 00:21:41.960
点，从根本上说它只能是
刚创建的数据上下文

00:21:41.960 --> 00:21:45.110
保存到数据集
各自的连接，

00:21:45.110 --> 00:21:46.210
执行 SQL 查询。

00:21:47.450 --> 00:21:50.225
使用某些链接魔术呈现
结果，一些有关

00:21:50.225 --> 00:21:51.495
再次运行该应用程序。

00:21:54.263 --> 00:21:55.585
它不生成任何更多。

00:21:58.718 --> 00:22:00.398
因为我需要添加
引用库

00:22:00.398 --> 00:22:01.085
同样课程。

00:22:01.085 --> 00:22:03.030
>> [发笑]
>> 只创建新库

00:22:03.030 --> 00:22:04.380
不完全的帮助。

00:22:04.380 --> 00:22:05.730
>> 也有引用
我听说它。

00:22:08.680 --> 00:22:09.540
我们重新写了这。

00:22:09.540 --> 00:22:14.580
这是相同的
像以前一样的事情。

00:22:14.580 --> 00:22:15.080
因此，现在，

00:22:15.080 --> 00:22:18.760
基本上，您已经移动您
为下标准对所有的员工。

00:22:18.760 --> 00:22:19.990
因此，这可能是
没有引用

00:22:19.990 --> 00:22:21.230
很多库，
我们可以引用它的

00:22:21.230 --> 00:22:24.700
我已经过我们无法核心
引用它的检查应用程序中，

00:22:24.700 --> 00:22:26.595
但这里看到
是的这警告。

00:22:26.595 --> 00:22:28.384
您还可以 [INAUDIBLE]
此警告的解决方案

00:22:28.384 --> 00:22:30.420
资源管理器中显示
它是同样的事情。

00:22:30.420 --> 00:22:31.500
因此，这里的目的是，

00:22:31.500 --> 00:22:33.780
我们让您知道如果这是
经过压缩。

00:22:33.780 --> 00:22:35.380
我们不知道这是什么
库，右？

00:22:35.380 --> 00:22:38.330
它可能使用 WinForms，
它可以使用的 Api，我们没有。

00:22:38.330 --> 00:22:40.170
因此，此处的目的
是您测试您的应用程序，

00:22:40.170 --> 00:22:41.910
说服自己
它工作正常。

00:22:41.910 --> 00:22:45.030
然后，您和有效
只是禁止显示该警告。

00:22:45.030 --> 00:22:48.840
如您在此处看到，像这种，
在这里，一个数字

00:22:48.840 --> 00:22:50.990
这是 NU 一个、 七，或
一个是的警告编号

00:22:50.990 --> 00:22:51.630
在压缩。

00:22:51.630 --> 00:22:54.540
因此，所有您需要做
选择就是在此处，输入

00:22:54.540 --> 00:22:58.670
然后您只需输入
在这里，警告编号按 enter 键，

00:22:58.670 --> 00:23:01.940
保存和现在，您可以看到
一个从解决方案中消失

00:23:01.940 --> 00:23:07.120
资源管理器中，而且它也会消失
从这里重建。

00:23:07.120 --> 00:23:10.090
>> 因此，
我玩的一件事

00:23:10.090 --> 00:23:12.750
最近的这
周末或最后一周。

00:23:12.750 --> 00:23:17.090
我玩的
警告错误。

00:23:17.090 --> 00:23:18.660
>> 是。
>> 对话框。

00:23:18.660 --> 00:23:22.260
能跟您谈谈一些有关吗
哪些生成，因此我们知道的

00:23:22.260 --> 00:23:27.630
大量的人运行
与警告视为错误。

00:23:27.630 --> 00:23:29.300
>> 的权限。
>> 因此，在这种模型

00:23:30.460 --> 00:23:33.050
为与该 incapatable
这样的系统，或

00:23:33.050 --> 00:23:34.710
可以说的？

00:23:34.710 --> 00:23:36.200
>> 是的我们的想法是，
我认为如此

00:23:36.200 --> 00:23:41.040
他们做了什么现在与
与最新版本是他们

00:23:41.040 --> 00:23:44.453
什么样的之间的桥梁
生成的警告和警告

00:23:44.453 --> 00:23:49.330
从因此他们是在同一个
用户界面和相同的体验。

00:23:49.330 --> 00:23:52.170
例如，在这里，看到
已经特定警告

00:23:52.170 --> 00:23:54.670
取消之后特定
已处理的警告。

00:23:54.670 --> 00:23:59.200
例如，因此，您可以
了解更改这些设置，

00:23:59.200 --> 00:24:01.940
可以说，我的示例为
NU1701 是一个错误，想要

00:24:01.940 --> 00:24:04.920
因此，我不想万一
通过压缩。

00:24:04.920 --> 00:24:08.240
另外一点是要
禁止显示警告。

00:24:08.240 --> 00:24:10.120
>> 和位置吗
如果您希望，指定的

00:24:10.120 --> 00:24:11.169
有-
>> 您可以指定

00:24:11.169 --> 00:24:11.876
右这里 [INAUDIBLE]。

00:24:11.876 --> 00:24:12.422
>> 好。

00:24:12.422 --> 00:24:14.518
>> 因此，我想基本上是说，
对待这些箭头，

00:24:14.518 --> 00:24:15.198
我想说，NU。

00:24:15.198 --> 00:24:15.770
>> 好。

00:24:15.770 --> 00:24:17.070
>> 现在变得错误，
权限。

00:24:17.070 --> 00:24:18.100
>> 好了，我看到您。

00:24:18.100 --> 00:24:20.709
>> 是的是的如果您
它查看项目文件的

00:24:20.709 --> 00:24:22.582
平均每个系统
具有相同的 NU1，

00:24:22.582 --> 00:24:25.230
和属性的
在一个用于编译。

00:24:25.230 --> 00:24:27.110
因此，它有非常
现在简单工作流程。

00:24:27.110 --> 00:24:29.560
只是，编辑和
然后它将只是旅行。

00:24:29.560 --> 00:24:30.216
>> 好了，这样的

00:24:30.216 --> 00:24:32.352
有这些的人
生成系统的类型

00:24:32.352 --> 00:24:34.450
它们应该只播放
像其他的内容。

00:24:34.450 --> 00:24:35.650
>> 是。

00:24:35.650 --> 00:24:37.940
其思想通常是他们
为您提供抑制器警告。

00:24:37.940 --> 00:24:40.709
得到了解决，那么即使您
已经打开，警告 [INAUDIBLE]

00:24:40.709 --> 00:24:43.372
正如禁止显示警告是不
再导致失败的关系出现裂缝

00:24:43.372 --> 00:24:44.453
从根本上讲，对吧？

00:24:44.453 --> 00:24:46.944
>> 答对了。

00:24:46.944 --> 00:24:50.350
>> 好了，
这是该演示。

00:24:51.510 --> 00:24:56.461
让我们回到牌。

00:24:56.461 --> 00:24:59.420
这样，其他问题
通常是版本号。

00:24:59.420 --> 00:25:00.971
>> 的权限。
>> 还有多个版本

00:25:00.971 --> 00:25:03.800
标准，然后再
但问题是，什么应该您。

00:25:03.800 --> 00:25:06.487
您如何应该考虑一下
版本号，您是如何

00:25:06.487 --> 00:25:08.611
能够做出选择
您希望目标。

00:25:08.611 --> 00:25:15.930
因此我写一些 HTML，
这我可能应该公用。

00:25:15.930 --> 00:25:18.130
它实际上是在 GitHub 上，您可以
实际上从那里得到它，但

00:25:18.130 --> 00:25:19.830
我没有的链接
然而。

00:25:19.830 --> 00:25:22.710
但基本上所示
似乎与此表

00:25:22.710 --> 00:25:25.260
每个人都混淆所有的时间。

00:25:25.260 --> 00:25:27.160
表实际上并不是
一旦您知道困难如何

00:25:27.160 --> 00:25:29.590
为了进行阅读，但
不是很明显的。

00:25:29.590 --> 00:25:31.048
因此这里您看到
最顶部是

00:25:31.048 --> 00:25:32.790
查看版本
标准的数字。

00:25:33.890 --> 00:25:37.168
这样，您可以看到类似
从 1.0 到 2.0，

00:25:37.168 --> 00:25:40.363
哪种类型的版本
数字我们有吗？

00:25:40.363 --> 00:25:42.620
然后再看
在垂直轴上，

00:25:42.620 --> 00:25:45.396
最终所有.NET
我们有实现。

00:25:45.396 --> 00:25:47.744
因此，例如此处，
您可以看到，现在，

00:25:47.744 --> 00:25:49.819
我们选择了
.NET 标准 1.0。

00:25:49.819 --> 00:25:52.475
您在此处看到的绿色
基本上所有.NET 都是

00:25:52.475 --> 00:25:54.191
您可以运行，实现
和

00:25:54.191 --> 00:25:56.920
最低版本
您需要的号码。

00:25:56.920 --> 00:26:00.448
例如，如果我想
若要运行.NET 标准 1.0

00:26:00.448 --> 00:26:02.325
我想要的目标.NET 1.0

00:26:02.325 --> 00:26:05.567
这意味着运行.NET
由于 1.0 版的核心。

00:26:05.567 --> 00:26:08.941
我可以在框架上运行
由于版本号 4.5。

00:26:08.941 --> 00:26:11.634
>> 这意味着您只是不能
支持前的事情。

00:26:11.634 --> 00:26:12.277
>> 更正。

00:26:12.277 --> 00:26:13.139
>> Like 4.0。

00:26:13.139 --> 00:26:15.943
>> 是，那么 4.0，
我们不要为实例运行。

00:26:15.943 --> 00:26:19.498
这里您看到的其他事情是
该图形在这里，请参阅

00:26:19.498 --> 00:26:23.510
.NET 核心不
实际上直接实现 1.0。

00:26:23.510 --> 00:26:25.715
它实际上实现 1.6。

00:26:25.715 --> 00:26:28.776
这意味着我现在可以瞄准
更高的版本号，

00:26:28.776 --> 00:26:30.507
在.NET 核心 1.0 中仍然运行。

00:26:30.507 --> 00:26:32.677
举例来说，
现在我们针对 1.1 版中，

00:26:32.677 --> 00:26:35.620
您看到了，所有的
此类东西变得不可用。

00:26:35.620 --> 00:26:38.967
例如，不再需要
Windows Silverlight 的

00:26:38.967 --> 00:26:41.724
但愿没有人关注
有关使用 UWP，但

00:26:41.724 --> 00:26:43.771
该方式具有表
主要的工作。

00:26:43.771 --> 00:26:46.725
甚至再转
此外，如果只是切换

00:26:46.725 --> 00:26:49.599
请参阅基本此红色追踪
东西不想在上运行。

00:26:49.599 --> 00:26:51.608
现在您可以看到，

00:26:51.608 --> 00:26:56.014
现在如果需要.NET Framework 4.6
我需要运行.NET 中心 1.3。

00:26:57.770 --> 00:27:00.603
这基本上就是如何读取
表，然后在最顶部，

00:27:00.603 --> 00:27:03.168
我们这里有此蓝色条形图
这是比较类似的代理

00:27:03.168 --> 00:27:04.412
我们的 Api 的数量。

00:27:04.412 --> 00:27:08.646
所以我要回请参见
1.0 和 1.1 版之间的 SUMJUM 和

00:27:08.646 --> 00:27:12.509
然后之间 1.1 和 1.2，
没有只是一个次要的跳转。

00:27:12.509 --> 00:27:16.037
然后，一旦我们达到 2.0，我们
请参阅此巨大的峰值位置我们

00:27:16.037 --> 00:27:18.692
有超过 20000 个警报 Api，
这整件事。

00:27:18.692 --> 00:27:22.532
这里的数字不是一体
为日期，但是.NET Framework

00:27:22.532 --> 00:27:25.604
其中一个是，操作时所需
针对.NET Centere 2.0，

00:27:25.604 --> 00:27:28.676
基本上，您需要运行
.NET Framework 461 及更高版本，

00:27:28.676 --> 00:27:31.122
不是通过运行在 45 或
46，例如。

00:27:31.122 --> 00:27:33.260
这实质上是如何
要阅读此表。

00:27:33.260 --> 00:27:34.415
明白了您？

00:27:34.415 --> 00:27:35.106
>> 毫米 hm。

00:27:38.442 --> 00:27:41.682
我所看到的因此不应本专栏中，

00:27:41.682 --> 00:27:46.220
该单元格，说 2.0 中，
.NET 核心 2.0？

00:27:46.220 --> 00:27:47.964
>> 是，它应该显示在这里，2.0

00:27:47.964 --> 00:27:50.201
我忘记了是哪一版本
这里的数字都是。

00:27:50.201 --> 00:27:51.692
>> 是，但
我们可以填写的权利？

00:27:51.692 --> 00:27:52.970
>> 我们可以填充一下，

00:27:52.970 --> 00:27:56.250
没有最新
如果您转到我们的常见问题解答的版本。

00:27:56.250 --> 00:27:58.725
没有实际的版本
我们在这里，有的表

00:27:58.725 --> 00:28:00.650
这是相同的
我们必须在文档中。

00:28:00.650 --> 00:28:01.384
>> 对，这就是最新的。

00:28:01.384 --> 00:28:03.310
>>，以便您看到的实际
此版本编号。

00:28:03.310 --> 00:28:06.952
我只是还没有完成它
HTMLified 版本。

00:28:06.952 --> 00:28:08.805
>> 好。

00:28:08.805 --> 00:28:09.820
>>，但是
这是同样的事情。

00:28:11.300 --> 00:28:13.405
那么下一步
通常的问题是，好了，

00:28:13.405 --> 00:28:14.752
如何决定，对？

00:28:14.752 --> 00:28:16.501
而且基本上，权衡。

00:28:16.501 --> 00:28:19.009
您必须决定之间
更高版本

00:28:19.009 --> 00:28:21.720
标准是，
您有多个 Api。

00:28:21.720 --> 00:28:23.625
低版本
该标准是，

00:28:23.625 --> 00:28:26.347
您有多个范围，是因为
多平台支持

00:28:26.347 --> 00:28:27.883
[INAUDIBLE] 的特定版本。

00:28:27.883 --> 00:28:30.583
这是比较直观，但
仍然值得指出的是

00:28:30.583 --> 00:28:32.473
因为人们会
弄不清的。

00:28:32.473 --> 00:28:34.591
[听不到] 这是
因为这是一个规范，

00:28:34.591 --> 00:28:37.730
像一个版本号
不超出支持。

00:28:37.730 --> 00:28:38.305
>> 的权限。

00:28:38.305 --> 00:28:40.625
>> 因为它基本上是刚
许多 Api，您可以

00:28:40.625 --> 00:28:41.710
访问，实质上是。

00:28:41.710 --> 00:28:43.304
同样，一般来讲，

00:28:43.304 --> 00:28:45.572
即使他们
对发布 2.0 中，

00:28:45.572 --> 00:28:49.970
不要觉得感到内疚的
即使目标 1.6 1.4、 1.0。

00:28:49.970 --> 00:28:52.132
因为如果可以将目标 1.0，
所有的手段，

00:28:52.132 --> 00:28:53.356
应将目标 1.0。

00:28:53.356 --> 00:28:56.459
您应该只凹凸版
当您需要更多的 Api 的数量。

00:28:58.270 --> 00:28:59.582
实现，请在
另一侧，

00:28:59.582 --> 00:29:00.902
他们有的支持策略，
对吧？

00:29:00.902 --> 00:29:04.359
例如，我们可能会和
决定说.NET 核心 1.0

00:29:04.359 --> 00:29:08.100
最终，支持从和
您无需在 1.1 或 2.0。

00:29:08.100 --> 00:29:10.316
这只是意味着您不能
指定的目标更高版本

00:29:10.316 --> 00:29:11.918
同样，标准
但是，您总是可以

00:29:11.918 --> 00:29:14.350
目标的更低版本
为了获取更多的覆盖面。

00:29:14.350 --> 00:29:18.593
>>，基本上要说
.NET 实现版本

00:29:18.593 --> 00:29:21.737
和他们的支持策略
与没有关系

00:29:21.737 --> 00:29:23.650
标准.NET 的版本。

00:29:23.650 --> 00:29:25.060
>> 更正。
>> 我们打算支持这些

00:29:25.060 --> 00:29:26.630
永远的标准.NET 版本。

00:29:26.630 --> 00:29:29.658
>> 是。
>> 没有任何理由

00:29:29.658 --> 00:29:32.420
我们可以否决他们。

00:29:32.420 --> 00:29:34.443
是的我们有没有计划
以往任何时候都做的。

00:29:34.443 --> 00:29:36.481
>> 并没有也不
重大更改，右，

00:29:36.481 --> 00:29:39.167
与版本一样，数字是所有
monolithically 增加和

00:29:39.167 --> 00:29:41.830
您只会收到更多的 Api 时
我们将从这里移 Api。

00:29:41.830 --> 00:29:42.660
>> 的权限。

00:29:42.660 --> 00:29:43.790
>> 因此，使成为可能。

00:29:43.790 --> 00:29:46.478
>> 啊，
不仅我们不删除的 Api，

00:29:46.478 --> 00:29:49.254
好了，我猜的
您说的是什么。

00:29:49.254 --> 00:29:52.611
是的我们永远不会返回，并和
添加或删除从 Api

00:29:52.611 --> 00:29:53.811
给定版本的
>> 更正。

00:29:53.811 --> 00:29:54.333
>> 我们已交付。

00:29:54.333 --> 00:29:55.410
然后它是不可变的。

00:29:55.410 --> 00:29:59.865
>> 是，因此
它是一个非常简单的模型。

00:29:59.865 --> 00:30:03.416
有目标的最低版本
您可以得到。

00:30:03.416 --> 00:30:07.404
然后，其他的事情我们
应该点出的是

00:30:07.404 --> 00:30:12.588
习惯到可移植的人
类库，如果您转到

00:30:12.588 --> 00:30:18.190
-\-

00:30:19.310 --> 00:30:20.766
如果您阅读
文本相似，

00:30:20.766 --> 00:30:22.840
您将看到它现在
指出传统笔记本电脑。

00:30:22.840 --> 00:30:25.900
因此，我们基本上是尝试对
告诉人们停止使用

00:30:25.900 --> 00:30:27.490
可移植类库。

00:30:27.490 --> 00:30:29.560
然后在文本中，我们还说
这已被否决。

00:30:29.560 --> 00:30:31.863
您应该使用类库
.NET 标准相反。

00:30:31.863 --> 00:30:34.870
因此.NET 标准是
从后续的

00:30:34.870 --> 00:30:36.380
可移植类库。

00:30:36.380 --> 00:30:37.940
但它是更
更好的刀具故事，

00:30:37.940 --> 00:30:40.490
部分是因为我们有
更多的 API 面。

00:30:40.490 --> 00:30:41.029
其次

00:30:41.029 --> 00:30:43.145
因为仍然可以引用
.NET 框架的二进制文件

00:30:43.145 --> 00:30:43.691
这是巨大的。

00:30:43.691 --> 00:30:45.692
因为通常最大
使用笔记本电脑，事情

00:30:45.692 --> 00:30:47.606
您可以只
引用其他笔记本。

00:30:47.606 --> 00:30:48.881
您可能永远不会
引用任何其他操作。

00:30:48.881 --> 00:30:50.106
>> 的权限。

00:30:50.106 --> 00:30:53.104
>> 因此
真正获取您取消阻止。

00:30:53.104 --> 00:30:53.737
>> 是，因此

00:30:53.737 --> 00:30:58.027
我认为应该有很少
PCL 的更好的方案。

00:30:58.027 --> 00:31:00.073
>> 的权限。

00:31:00.073 --> 00:31:03.790
>> 是 95%
更好地 kinda 事物。

00:31:03.790 --> 00:31:05.150
>> 是的我喜欢思考
它始终是更好的。

00:31:05.150 --> 00:31:07.670
它就是指某些平台
不想支持它。

00:31:07.670 --> 00:31:08.690
他们不再支持它。

00:31:08.690 --> 00:31:10.777
但.NET 标准最终
让我们支持它 [INAUDIBLE]

00:31:10.777 --> 00:31:12.290
真的不会失去任何东西的
>> 的权限。

00:31:12.290 --> 00:31:12.900
>> 实际上。

00:31:14.010 --> 00:31:16.010
因此，只应移动
对标准和

00:31:16.010 --> 00:31:18.225
这通常是升级。

00:31:18.225 --> 00:31:22.567
这就是我认为我们拥有什么
便携式计算机的看法。

00:31:22.567 --> 00:31:25.220
另一方面，它通常
来自最多是多目标。

00:31:25.220 --> 00:31:28.100
因此，通常什么结束
发生了是人

00:31:28.100 --> 00:31:31.170
有时遇到 Api，
在标准中不存在。

00:31:32.310 --> 00:31:35.890
所以我这里有我
包含四个项目的解决方案。

00:31:35.890 --> 00:31:37.713
因此，我只需运行
它非常快速。

00:31:40.992 --> 00:31:43.864
是的之前我们收到一个错误
从 UWP 应用程序，消息

00:31:43.864 --> 00:31:45.680
让我只部署
这专家第一次。

00:31:45.680 --> 00:31:48.980
>> 是，另一个我
最受欢迎的错误消息。

00:31:51.390 --> 00:31:53.220
>>，现在当我运行它，
我有两个应用程序。

00:31:55.390 --> 00:31:57.300
我可以看到我已经
之前在此打开

00:31:57.300 --> 00:31:58.380
更大的屏幕分辨率。

00:31:58.380 --> 00:31:59.718
因此
他们两个做的一样。

00:31:59.718 --> 00:32:01.150
我有 WinForms 应用程序，
UWP 应用程序和

00:32:01.150 --> 00:32:02.345
它们都执行相同的操作。

00:32:02.345 --> 00:32:05.432
他们只是向您展示
到你的位置的经度/纬度

00:32:05.432 --> 00:32:08.330
通过使用位于地球
地理位置 Api 从

00:32:08.330 --> 00:32:09.800
操作系统。

00:32:09.800 --> 00:32:12.900
>> 因此，如果您必须运行该应用程序
昨天，我们无法说过

00:32:12.900 --> 00:32:16.207
无论您是当前
遇到了 eclipse [笑声]。

00:32:16.207 --> 00:32:18.575
>> 是的我们可以聊。

00:32:18.575 --> 00:32:20.267
>> 为什么是吗
想一想？

00:32:20.267 --> 00:32:23.750
>> 我不知道，
我没有发生此错误。

00:32:23.750 --> 00:32:25.450
因此，我现在拥有的是
我有两个库。

00:32:26.680 --> 00:32:32.050
是因为我想要共享，公用
可以访问 GPS 子系统。

00:32:33.430 --> 00:32:35.355
让我们首先看
在.NET Framework

00:32:35.355 --> 00:32:36.537
它的实现。

00:32:36.537 --> 00:32:40.503
实际上，必须
以下是主要使用

00:32:40.503 --> 00:32:42.660
System.Device.Location。

00:32:42.660 --> 00:32:44.520
和您所要做
此小舞，

00:32:44.520 --> 00:32:47.700
因为第一次调用
它，它可能无法初始化，

00:32:47.700 --> 00:32:49.442
因此，就这样
thingy 这里很少。

00:32:49.442 --> 00:32:52.356
并由于需要一段时间，
我有，异步的版本

00:32:52.356 --> 00:32:53.766
因此，在辅助线程上运行它。

00:32:53.766 --> 00:32:56.274
但我实际上是返回
对您来说是刚才的元组

00:32:56.274 --> 00:32:58.050
经度/纬度，合适吗？

00:32:58.050 --> 00:32:58.813
GetCoordinates。

00:32:58.813 --> 00:33:01.128
相当简单。

00:33:01.128 --> 00:33:02.826
>> 元组的任务。

00:33:02.826 --> 00:33:03.453
>> 是。

00:33:03.453 --> 00:33:04.710
是因为它是一个异步 API。

00:33:04.710 --> 00:33:06.582
然后执行相同
UWP 侧的事情

00:33:06.582 --> 00:33:08.043
但现在，我使用不同的 Api。

00:33:08.043 --> 00:33:09.500
现在，我使用 Windows TAPIs。

00:33:09.500 --> 00:33:11.848
因此，您可以看到使用
Windows.Device.Geolocations 和

00:33:11.848 --> 00:33:13.713
此 API 已经
asynchronified 这样

00:33:13.713 --> 00:33:16.071
我不需要做如下所示
辅助线程或任何东西。

00:33:16.071 --> 00:33:18.807
我可以只返回该专家，
我只是等待，

00:33:18.807 --> 00:33:20.040
返回此事。

00:33:20.040 --> 00:33:22.930
然后我已经完成与此。

00:33:22.930 --> 00:33:24.080
我放这原因
在库中也是如此

00:33:24.080 --> 00:33:26.230
我可以重复使用该跨
所有我 WinForms 网络，

00:33:26.230 --> 00:33:27.560
跨所有我 UWP 的应用程序，正确吗？

00:33:27.560 --> 00:33:29.280
但问题是再
我有两个库。

00:33:29.280 --> 00:33:32.570
我有一个用于.NET Framework
而且我有 UWP 个。

00:33:32.570 --> 00:33:34.990
所以，现在我们看一下
这里引用。

00:33:34.990 --> 00:33:36.017
我需要知道的
一个引用。

00:33:36.017 --> 00:33:38.786
UWP 一个引用 UWP
版本，然后.NET 核心

00:33:38.786 --> 00:33:41.444
版本引用.NET
我很抱歉，核心版本，

00:33:41.444 --> 00:33:42.870
.NET Framework 版本。

00:33:42.870 --> 00:33:45.790
>> 是，猜测之一
这里要做的事情，和

00:33:45.790 --> 00:33:47.231
这可能是太深究。

00:33:47.231 --> 00:33:48.670
>> [发笑]
>>，但是-

00:33:48.670 --> 00:33:50.339
>> 它是一种深究天。

00:33:50.339 --> 00:33:55.230
>> 在此特定情况下
如果您正在使用的类型

00:33:55.230 --> 00:33:57.300
你从操作
系统是.NET 类型，

00:33:57.300 --> 00:34:00.590
您可以实际上只是让
返回该位置和

00:34:00.590 --> 00:34:02.540
不拉纬度/经度
从它。

00:34:02.540 --> 00:34:05.196
>> 更正。
>> 我想要做什么了

00:34:05.196 --> 00:34:10.689
基本上，您要转换
赢取 RT 表示，

00:34:10.689 --> 00:34:14.038
键入内容
更多不可知。

00:34:14.038 --> 00:34:14.639
>> 更正。

00:34:14.639 --> 00:34:16.054
>>，这就是为什么您
必须等待它，

00:34:16.054 --> 00:34:17.659
将其仅转换
这两个可能的

00:34:17.659 --> 00:34:18.796
>> 的权限。

00:34:18.796 --> 00:34:19.991
>> 两个双精度型值。

00:34:19.991 --> 00:34:20.891
>> 的权利。

00:34:20.891 --> 00:34:21.602
>> 是。

00:34:21.602 --> 00:34:22.432
>> 这样的
>> 和

00:34:22.432 --> 00:34:24.938
这是两个
兼容的边。

00:34:24.938 --> 00:34:25.863
>> 是。

00:34:25.863 --> 00:34:26.551
当然，这是目标。

00:34:26.551 --> 00:34:27.125
>> 是。

00:34:27.125 --> 00:34:28.434
>> 看看这里这一部分。

00:34:28.434 --> 00:34:33.903
Gps 的名称空间，GpsLocation，
GetCoordinates 元。

00:34:33.903 --> 00:34:36.784
这实际上看起来完全相同
赢取 RT 版本之间

00:34:36.784 --> 00:34:38.368
与.NET Framework 版本。

00:34:38.368 --> 00:34:40.300
和您说过，
它不是意外。

00:34:40.300 --> 00:34:41.400
我有意做了这。

00:34:41.400 --> 00:34:42.140
>> 的权限。

00:34:42.140 --> 00:34:44.959
>> 是因为现在我可以做到
使用我的魔术棒，

00:34:44.959 --> 00:34:48.731
只要切换到另一个分支
在我做这工作。

00:34:48.731 --> 00:34:51.610
是因为不想看到我
打击与我不存在

00:34:51.610 --> 00:34:53.420
鼠标，我应该说。

00:34:53.420 --> 00:34:56.712
现在我有一个
项目称为 Gps。

00:34:56.712 --> 00:34:59.909
我有一个文件
调用现在 GpsLocation。

00:34:59.909 --> 00:35:01.987
现在您看到的只是和
有两个库，

00:35:01.987 --> 00:35:03.161
只有一个库。

00:35:03.161 --> 00:35:04.747
您只需在一定程度上，
ifdef 基本代码中。

00:35:04.747 --> 00:35:08.113
和什么 [INAUDIBLE] 现在看到的这样
这是本很少放在向下

00:35:08.113 --> 00:35:10.480
这里，
将看到三个条目。

00:35:10.480 --> 00:35:13.000
有了.NET 框架
.NET 标准和 WWP。

00:35:14.490 --> 00:35:19.652
如果已将
项目通常

00:35:19.652 --> 00:35:22.266
它说目标框架
用作单数，然后它

00:35:22.266 --> 00:35:25.860
说任何在目标
.NET 核心，.NET 居中。

00:35:25.860 --> 00:35:27.020
和我刚才
此批准并

00:35:27.020 --> 00:35:30.280
它是现在目标
框架和 WWP 标准。

00:35:30.280 --> 00:35:33.460
>> 好了，可以这么做的
所有的 [INAUDIBLE] 属性？

00:35:33.460 --> 00:35:34.470
>> 没有，对不起，不能。

00:35:34.470 --> 00:35:35.270
>> 好了，只检查。

00:35:35.270 --> 00:35:37.320
>> 不过，现在您可以
是的因为该项目不是

00:35:37.320 --> 00:35:39.700
有效地编译的次数。

00:35:39.700 --> 00:35:41.880
因此，现在我可以做什么，
我可以说我想要拥有这

00:35:41.880 --> 00:35:45.410
引用，此 NuGet 程序包，
对所有我三个编译。

00:35:45.410 --> 00:35:46.520
>> 的权限。
>> 和我可以说，

00:35:46.520 --> 00:35:49.040
目标框架时
我想要做此附加的参考

00:35:49.040 --> 00:35:51.930
在添加引用
到 System.Device。

00:35:51.930 --> 00:35:53.430
您可以进行任何
要在 MSBuild，

00:35:53.430 --> 00:35:54.370
使用这些表达式。

00:35:54.370 --> 00:35:57.880
您可以基本上现在说，
如果目标框架为 461，

00:35:57.880 --> 00:35:58.740
然后我执行此操作。

00:35:58.740 --> 00:36:00.030
否则，我这样做的。

00:36:00.030 --> 00:36:02.760
>> 在哪里结束
项目标记？

00:36:02.760 --> 00:36:03.520
>> 是在非常

00:36:03.520 --> 00:36:05.530
最终由于仍有
我需要做一些丑陋的东西。

00:36:05.530 --> 00:36:07.870
>> 天哪，我提出错误的问题。

00:36:07.870 --> 00:36:09.600
>> 没有，
提出正确的问题。

00:36:09.600 --> 00:36:12.163
但在逻辑上，
这是您所要做的。

00:36:12.163 --> 00:36:12.920
>> 我看到。

00:36:12.920 --> 00:36:15.180
和现在什么我这里现在有
我有一种方法基本上是

00:36:15.180 --> 00:36:17.200
和我可以只是如果这件事。

00:36:17.200 --> 00:36:20.090
有趣的是现在就是我
此外面向.Net 标准

00:36:20.090 --> 00:36:21.950
我还没有执行此操作之前。

00:36:21.950 --> 00:36:24.550
所以什么，该怎么办现在发生的情况
我有一个实现

00:36:24.550 --> 00:36:28.520
这个标准，，这是
不是很有用的支持。

00:36:28.520 --> 00:36:31.730
但是现在我可以做什么是我可以的
>> 因此，是该有点类似的内容，

00:36:31.730 --> 00:36:36.000
这基本上如下所示的诱饵，
切换模式？

00:36:36.000 --> 00:36:37.190
是的它正好就是。

00:36:37.190 --> 00:36:38.110
因此，让我们。
>> 好。

00:36:38.110 --> 00:36:40.230
>> 让我们第一次启动
通过说出您知道，

00:36:40.230 --> 00:36:42.080
让我们产生新
包这一切，因此

00:36:42.080 --> 00:36:46.940
您只需转此处说的包，
然后我们得到包和物料清单。

00:36:46.940 --> 00:36:49.240
这也是我们具有的新功能。

00:36:49.240 --> 00:36:51.330
>> 是 20
这就是近 2017年。

00:36:51.330 --> 00:36:54.290
>> 是，
我相信，已经是 51。

00:36:54.290 --> 00:36:55.680
>> 是。

00:36:55.680 --> 00:36:59.290
现在我构建的这个人
我刚转到输出文件夹。

00:36:59.290 --> 00:37:01.710
首先，您将看到
还有三个文件夹

00:37:01.710 --> 00:37:03.820
所有的不同我们的目标。

00:37:03.820 --> 00:37:06.370
>> 我感觉，我们将使用
再次 NuGetPackageExplorer。

00:37:06.370 --> 00:37:08.710
>> 完全正确，但
它也是一个软件包，并且

00:37:08.710 --> 00:37:11.380
一包，不是三。

00:37:11.380 --> 00:37:12.780
>> 这样三个文件夹吗？

00:37:12.780 --> 00:37:14.860
>> 还有三个文件夹和
然后在您获得 NuGet，

00:37:14.860 --> 00:37:16.630
您有三个文件夹也。

00:37:16.630 --> 00:37:18.350
三个二进制文件
我们刚刚产生这样

00:37:18.350 --> 00:37:21.926
我们主要做一的次
请在创建该版本，

00:37:21.926 --> 00:37:24.450
WP 的版本，和
其中一个版本。

00:37:24.450 --> 00:37:26.150
因此，有三个
不同的二进制文件，

00:37:26.150 --> 00:37:27.750
都打包。

00:37:27.750 --> 00:37:30.270
此软件包的使用者
现在，不需要知道的

00:37:30.270 --> 00:37:32.140
他们不得不做某事
不同的平台和

00:37:32.140 --> 00:37:33.890
B 平台
我基本上是抽象这出。

00:37:35.940 --> 00:37:36.510
>> 很好。

00:37:36.510 --> 00:37:37.860
>> 现在，您可能会说，嗯，但是

00:37:37.860 --> 00:37:39.860
稍等一下，如果我引用
这从别处，

00:37:39.860 --> 00:37:43.360
我只被分解运行时，
它似乎并不是非常有用。

00:37:43.360 --> 00:37:46.370
但它仍然是因为我
仍可以执行此操作，请向右？

00:37:46.370 --> 00:37:49.670
我可以做公共的布尔值
isSupported，合适吗？

00:37:51.580 --> 00:37:53.340
现在可以执行相同
我现在要做的事情。

00:37:53.340 --> 00:37:58.793
我不能，而不是爆炸式的增长，
我基本上执行了此操作，

00:37:58.793 --> 00:38:03.652
其中我只是说，
如果.Net framework 中或 UWP。

00:38:03.652 --> 00:38:04.876
>> 毫米。

00:38:04.876 --> 00:38:07.120
>> 我只可以说返回 True。

00:38:10.820 --> 00:38:15.290
否则，我可以说出返回 false。

00:38:15.290 --> 00:38:17.100
>> 很好。
>> 因此，现在我的调用方没有

00:38:17.100 --> 00:38:18.730
必须知道其
我所支持的平台。

00:38:18.730 --> 00:38:20.420
只是我的调用方可以
说我可以访问，以及

00:38:20.420 --> 00:38:23.200
它可能应
是静态的原因

00:38:23.200 --> 00:38:25.800
这就是这种
来自，城市类。

00:38:25.800 --> 00:38:28.350
另一个的调用方可以检查一下
正面，因此我假设您做

00:38:28.350 --> 00:38:31.200
Twitter 客户端，右，和
使用 twitter 客户端想要标记您

00:38:31.200 --> 00:38:32.690
其地理位置的 tweets。

00:38:32.690 --> 00:38:33.650
>> 课程的右侧。

00:38:33.650 --> 00:38:36.400
>> 和显然，
如果您无法访问该设备，，

00:38:36.400 --> 00:38:37.140
没有任何不良反应。

00:38:37.140 --> 00:38:40.442
您只是失去了细微的功能，
和你们的产品，但

00:38:40.442 --> 00:38:41.711
您的应用程序可以继续工作。

00:38:41.711 --> 00:38:43.880
这样的目的是，
调用方将注意到该 GPS

00:38:43.880 --> 00:38:47.520
如果是这样，支持位置
忘记了坐标和

00:38:47.520 --> 00:38:49.650
然后可以调用方的责任
正确拨号代码，但

00:38:49.650 --> 00:38:50.290
可喜的是，

00:38:50.290 --> 00:38:52.880
调用方不具有
若要了解哪些平台。

00:38:52.880 --> 00:38:53.480
>> 的权限。
>> 因此

00:38:53.480 --> 00:38:55.630
您可以提取它基本上为
每个人。

00:38:55.630 --> 00:38:58.555
>> 向右，因此
您有共享项目之前。

00:38:58.555 --> 00:38:59.105
>> 是。

00:38:59.105 --> 00:39:02.045
>> 这看起来像
同样的事情，

00:39:02.045 --> 00:39:04.925
什么是不同与您
与.net 标准方法

00:39:04.925 --> 00:39:06.685
共享的项目
我使用的其中一个。

00:39:06.685 --> 00:39:09.085
>> 是这样的共享的项目
方法在逻辑上是相同的

00:39:09.085 --> 00:39:11.385
基本上有个项目
它包含所有源代码文件

00:39:11.385 --> 00:39:12.145
您想要共享。

00:39:12.145 --> 00:39:14.185
>>，看起来非常相似，
代码看起来相同。

00:39:14.185 --> 00:39:17.445
>> 完全相同，并且您具有
基本上为每个目标尚

00:39:17.445 --> 00:39:18.815
另一个项目。

00:39:18.815 --> 00:39:20.795
因此我们在示例中您将
有四个项目。

00:39:20.795 --> 00:39:21.635
>> 我看到。
>> 就会有一个用于

00:39:21.635 --> 00:39:22.610
标准。

00:39:22.610 --> 00:39:27.050
一个用于 ewp，另一个用于.Net
框架，一个共享的项目。

00:39:27.050 --> 00:39:29.950
>> 我看到是因为共享项目
几乎就像一个虚拟

00:39:29.950 --> 00:39:33.120
项目中，它实际上
不会生成任何资产

00:39:33.120 --> 00:39:34.200
就这么差。

00:39:34.200 --> 00:39:36.260
>> 只需将其链接到右
其他项目、 右？

00:39:36.260 --> 00:39:40.100
>> 因此右，这种方便
如果您将图层，确定。

00:39:40.100 --> 00:39:41.430
>> 是将对
如您维护

00:39:41.430 --> 00:39:43.520
手动链接 200
不同的源文件。

00:39:43.520 --> 00:39:44.450
将它们放在一部分，

00:39:44.450 --> 00:39:46.680
他们都将会在
从那里的设施链接。

00:39:46.680 --> 00:39:48.549
但现在，您有四个项目，
但

00:39:48.549 --> 00:39:51.289
您还没有 NuGet
从它不过，这样的包

00:39:51.289 --> 00:39:54.531
您还必须提供 NuGet
包和新规范 [INAUDIBLE]

00:39:54.531 --> 00:39:55.674
由手 [串扰]
>> 和

00:39:55.674 --> 00:39:58.977
然后您无法创建一个
NuGet 程序包，嗯，是的

00:39:58.977 --> 00:40:00.393
我猜这手工片。

00:40:00.393 --> 00:40:02.483
>> 基本上，就会有
[INAUDIBLE] 一次所有

00:40:02.483 --> 00:40:04.848
将生成项目，
您只需复制二进制文件和

00:40:04.848 --> 00:40:06.984
二进制文件 [INAUDIBLE]
>> 您不会赋予这很好

00:40:06.984 --> 00:40:08.149
在 [INAUDIBLE] 功能生成。

00:40:08.149 --> 00:40:09.356
>> 的权利。

00:40:09.356 --> 00:40:13.890
>> 权限，因此，这是迈出一大步
针对这种情况下前进。

00:40:13.890 --> 00:40:14.770
>> 的权限。
所以这里是可喜

00:40:14.770 --> 00:40:17.340
我们建议使用通道是，
如果需要对多目标，

00:40:17.340 --> 00:40:22.070
您应始终拥有它
备用的标准目标和

00:40:22.070 --> 00:40:24.820
然后转向数字您
选择函数

00:40:24.820 --> 00:40:27.615
实质上是哪种 API 的
服务需要公开。

00:40:27.615 --> 00:40:29.500
>> [听不到] 函数
实现。

00:40:29.500 --> 00:40:32.850
何种类型可以是
在公共的图面区域中使用

00:40:32.850 --> 00:40:34.760
到桥平台
差异，右。

00:40:34.760 --> 00:40:38.970
>> 好了，那就是类似
为.NET 标准版本控制。

00:40:38.970 --> 00:40:39.480
>> 更正。

00:40:39.480 --> 00:40:40.120
>> 是。
>> 是。

00:40:40.120 --> 00:40:40.690
>> 是。

00:40:40.690 --> 00:40:41.870
>> 非常相似，因此

00:40:41.870 --> 00:40:43.730
您只需选择最低
一个逃避，

00:40:44.880 --> 00:40:47.650
只是最简单的方法来告诉
>> 较低的版本编号

00:40:47.650 --> 00:40:48.800
办公室将停止编译和

00:40:48.800 --> 00:40:50.530
然后，使用前一个
用于编译和

00:40:50.530 --> 00:40:51.400
这就是最小的事情。

00:40:51.400 --> 00:40:55.954
>> 现在如果您还没有这样
尽管您可能能让

00:40:55.954 --> 00:40:59.718
.NET 的缓慢增长
标准的资产，但

00:40:59.718 --> 00:41:04.572
NuGet 包版本将
基本上是增加每个

00:41:04.572 --> 00:41:08.929
您不得不进行 bug 修复的时间
任何一种平台

00:41:08.929 --> 00:41:11.428
特定的实现。

00:41:11.428 --> 00:41:12.810
>> 的权利。

00:41:12.810 --> 00:41:15.582
因此，这基本上是
一种机制，您到桥

00:41:15.582 --> 00:41:18.228
平台的差异和
都感觉到有限

00:41:18.228 --> 00:41:21.126
该 API 服务的.NET 中心
本身和仍罩

00:41:21.126 --> 00:41:24.770
不必为使用者
考虑到多个平台。

00:41:24.770 --> 00:41:28.010
因此，这基本上是打开的
.NET 中心的 endedness。

00:41:28.010 --> 00:41:32.370
>> 使我感觉我们应该
只是，我知道这有点。

00:41:32.370 --> 00:41:33.660
给您明显。

00:41:33.660 --> 00:41:35.240
但我认为我们
应该只谈的

00:41:35.240 --> 00:41:39.110
像这些 60 秒
预处理器指令，

00:41:39.110 --> 00:41:42.920
人们抓住什么
它们的功能，在运行时。

00:41:42.920 --> 00:41:45.400
>> 是这样什么，该怎么办发生
在这里，如我所说过，

00:41:45.400 --> 00:41:49.190
此项目编译多个
时间就是编译器

00:41:49.190 --> 00:41:53.890
基本上为同一调用
法院基于三次，对吗？

00:41:53.890 --> 00:41:57.735
但它也传递不同
预处理器符号和

00:41:57.735 --> 00:42:01.199
他们基本上是暗指
从 TFM，名称以便

00:42:01.199 --> 00:42:03.774
它是只是思考的
您在此处看到 TFM。

00:42:06.055 --> 00:42:08.480
如果您只需转的
>> 所以这是什么样的一种约定。

00:42:08.480 --> 00:42:11.770
>> 是的它实际上是
完全是一种约定，

00:42:11.770 --> 00:42:13.660
唯一的事情就是
有点奇怪的是 UWP。

00:42:13.660 --> 00:42:15.670
但所有其他的
按照同样的事情，

00:42:15.670 --> 00:42:17.860
基本上他们
条件只是向上。

00:42:17.860 --> 00:42:20.550
实质上然后我们替换
用下划线点以便

00:42:20.550 --> 00:42:22.210
这会使其合法的标识符。

00:42:22.210 --> 00:42:22.840
>> 有意义。
>> 因此

00:42:22.840 --> 00:42:24.890
您知道究竟是什么
他们目前在此处。

00:42:24.890 --> 00:42:26.204
好的一点是，

00:42:26.204 --> 00:42:29.357
在编辑器中，它基本上
显示我的所有上下文因此

00:42:29.357 --> 00:42:31.870
我现在看到的是，
我正在为 UWP 进行编译。

00:42:31.870 --> 00:42:34.350
指示此代码路径处于活动状态。

00:42:34.350 --> 00:42:36.570
然后此代码
路径是活动的。

00:42:36.570 --> 00:42:38.120
并将该这些其他
被灰色。

00:42:38.120 --> 00:42:39.600
因此，另一个实质上的

00:42:39.600 --> 00:42:42.170
部分不考虑
源代码。

00:42:42.170 --> 00:42:44.605
如果我现在切换到，让我们说，

00:42:44.605 --> 00:42:48.590
这是的 461 仍主动
因为您说的或，但

00:42:48.590 --> 00:42:51.010
现在正在编译此代码，
并不是该代码。

00:42:51.010 --> 00:42:52.650
>> 以获得良好的视觉提示。

00:42:52.650 --> 00:42:54.680
>> 您得到非常相似
可视的内容的

00:42:54.680 --> 00:42:55.560
怎么回事，完全正确。

00:42:55.560 --> 00:42:57.090
>> 右但只是真的
使您回到家乡，

00:42:57.090 --> 00:42:59.720
您可以解释区别吗
井间如果和

00:42:59.720 --> 00:43:00.760
如果常规？

00:43:00.760 --> 00:43:03.130
>> 是这样差
这是这是

00:43:03.130 --> 00:43:04.410
>> 这如果此语句

00:43:04.410 --> 00:43:06.110
在编译时可用
对吧？

00:43:06.110 --> 00:43:08.410
这样当编译器运行时，
它将评估此事，

00:43:08.410 --> 00:43:11.650
说好用，
我需要考虑这段代码。

00:43:11.650 --> 00:43:15.453
所以基本上最终结果
说是否您就只能编写

00:43:15.453 --> 00:43:16.427
>> 这件

00:43:17.625 --> 00:43:18.405
>> 向右，因此

00:43:18.405 --> 00:43:21.865
另一点，
它的一部分将被丢弃。

00:43:21.865 --> 00:43:25.605
编译器不均匀，像
基本上，那些，读取第 15 行。

00:43:25.605 --> 00:43:27.595
>> 正确，您可以有，
甚至，在这里，语法错误

00:43:27.595 --> 00:43:29.082
它甚至没有关系。

00:43:29.082 --> 00:43:30.232
我实际上不知道的。

00:43:30.232 --> 00:43:32.942
>> 因为它只是
向右跳过的文字？

00:43:32.942 --> 00:43:34.752
>> 方上，是这样

00:43:34.752 --> 00:43:36.962
编译器实际上
看不到这些行。

00:43:36.962 --> 00:43:39.702
>> 是，然后其他漂亮
是因为它是的方式

00:43:39.702 --> 00:43:41.932
在这里，设置
因为它是一个类似的项目。

00:43:41.932 --> 00:43:43.772
也是项目的引用
所以做正确的事情，

00:43:43.772 --> 00:43:45.808
您会看到所有这些项目
引用是只引用。

00:43:45.808 --> 00:43:48.891
此 GPS 项目和
他们只会获得正确的

00:43:48.891 --> 00:43:51.687
具体实现
谁是这样这样

00:43:51.687 --> 00:43:54.340
此项目将得到
[听不到]WP 端和

00:43:54.340 --> 00:43:57.078
获取此项目
.Net 框架侧。

00:43:57.078 --> 00:43:59.642
因此即使没有 [INAUDIBLE]
使用多目标包

00:43:59.642 --> 00:44:02.259
可仅 [听不到] 解决方案
大大减少数

00:44:02.259 --> 00:44:05.155
您需要项目的思考
有关，无需维护。

00:44:05.155 --> 00:44:06.680
[听不到] 真的
强大的功能。

00:44:08.280 --> 00:44:09.230
>> Cool，我喜欢它。

00:44:09.230 --> 00:44:10.118
>> 是的它是太棒了。

00:44:11.516 --> 00:44:15.371
实际上问题非常好，其中一个
我们不能谈一谈事情

00:44:15.371 --> 00:44:18.736
是的我的意思是我猜不是，
现在重要因为我们发货

00:44:18.736 --> 00:44:21.350
Visual Studio 2015.3，
>> 的权限。

00:44:21.350 --> 00:44:22.860
>> 不过只是为了阐明
该点，如果您

00:44:22.860 --> 00:44:27.270
要使用此类需要的东西
这些 Visual Studio 于 2017 年 15.3。

00:44:27.270 --> 00:44:28.390
>> 是。
>> 如一星期前移位。

00:44:28.390 --> 00:44:30.940
>> 因此，大部分东西我
刚才介绍，像多

00:44:30.940 --> 00:44:32.990
确定目标，我认为是
它应该早转。

00:44:32.990 --> 00:44:33.590
>> 是。

00:44:33.590 --> 00:44:35.794
>> 但与说话
有关.NET 核心 2.0 和

00:44:35.794 --> 00:44:38.390
.NET 标准 2.0 中，
您必须在 15.3。

00:44:38.390 --> 00:44:40.500
>> 的权限。
>> 则不能为 15.2 或 15.1 中。

00:44:40.500 --> 00:44:42.270
>> 它基本上不起作用。

00:44:42.270 --> 00:44:42.820
>> 是。

00:44:42.820 --> 00:44:45.030
>> 我甚至不知道什么
错误是您将获得的但

00:44:45.030 --> 00:44:46.699
有可能是一些
涉及到的 unhappiness。

00:44:47.990 --> 00:44:48.850
>> 当您转沿该路径。

00:44:50.540 --> 00:44:52.650
好了，因此一个 URL
您应该还记得是

00:44:52.650 --> 00:44:54.140
此一这里。

00:44:54.140 --> 00:44:59.013
它的 netstandardfaq 这点
我前面显示的文档

00:44:59.013 --> 00:45:00.882
这是明确的。

00:45:00.882 --> 00:45:03.847
因此如果您有问题，
然而，我们还没有解答

00:45:03.847 --> 00:45:06.700
我只是添加新
对这一点的部分。

00:45:06.700 --> 00:45:08.250
>> 的权限。
>>，因此我拥有广阔

00:45:08.250 --> 00:45:11.139
要回答的问题
这里，例如，

00:45:11.139 --> 00:45:13.220
为什么是杰姆斯，例如？

00:45:13.220 --> 00:45:16.362
和版本如何工作？

00:45:16.362 --> 00:45:19.401
几乎我们的所有内容
讨论了大约会在此处列出，

00:45:19.401 --> 00:45:22.900
在这里，最上面，我们还
包含指向其他资源的链接。

00:45:22.900 --> 00:45:27.058
这就是为什么它基本上是
我猜您的一站式服务，，为

00:45:27.058 --> 00:45:28.540
全部内容。

00:45:28.540 --> 00:45:29.610
我们链接到我们的文档

00:45:29.610 --> 00:45:32.049
我们提供了视频系列，
我们在 YouTube 上创建。

00:45:33.050 --> 00:45:36.430
我们概念性的文档，我们的 API
正在此处链接的文档。

00:45:36.430 --> 00:45:39.293
因此，例如，我们要找到
出什么实际上是 doc 和

00:45:39.293 --> 00:45:41.319
发送 2.0，
实际上，您可以浏览它。

00:45:41.319 --> 00:45:43.936
您没有直接使用
在 Studio 的情报。

00:45:43.936 --> 00:45:46.702
>> 我知道，是的
体验是非常令人愉快的。

00:45:46.702 --> 00:45:49.703
>> 它是超级好，尤其是
当您搜索的类型，

00:45:49.703 --> 00:45:52.300
它是 super 快速响应，对吗？

00:45:52.300 --> 00:45:54.238
一些我们永远不会
以前在 MSDN。

00:45:54.238 --> 00:45:55.542
>> 没有，绝对没有。

00:45:55.542 --> 00:45:58.660
>> 我们实际上必须使用
整个屏幕，它是令人惊叹。

00:45:58.660 --> 00:46:00.190
>> 线外也可以。

00:46:00.190 --> 00:46:02.104
>> 它几乎是
GitHub，优于

00:46:02.104 --> 00:46:04.152
因为只有 GitHub
使用该部分。

00:46:04.152 --> 00:46:07.080
不管怎样，这就是 URL
您想要记住。

00:46:07.080 --> 00:46:10.105
当然如果您有
可以在找到我的问题

00:46:10.105 --> 00:46:12.069
使用 twitter 可以
我拍摄一封电子邮件。

00:46:12.069 --> 00:46:13.001
我收到大量的电子邮件，因此

00:46:13.001 --> 00:46:15.480
我将会有进一步反应
在电子邮件，我雇佣了

00:46:15.480 --> 00:46:18.370
额外的手可以击中我
在电子邮件上比 Twitter 上。

00:46:18.370 --> 00:46:19.450
>> 是，就是您要做的是因为。

00:46:19.450 --> 00:46:21.026
获取主，和
然后就只是 Twitter 的

00:46:21.026 --> 00:46:21.980
其余的晚上。

00:46:21.980 --> 00:46:26.768
>> 的完全真实，然后
我的妻子获取 5%的时间。

00:46:26.768 --> 00:46:30.459
>> 好了，我觉得我们比较
即将关闭此处。

00:46:30.459 --> 00:46:32.760
我认为我已经基本上
问我的问题。

00:46:32.760 --> 00:46:33.966
>> 最拿手。
>> 实际上不对，

00:46:33.966 --> 00:46:36.168
我有一个很好的
很多人询问。

00:46:36.168 --> 00:46:40.930
因此.NET 核心小组

00:46:40.930 --> 00:46:44.530
开始要考虑使用.NET
核心 2.1，大惊奇。

00:46:44.530 --> 00:46:45.103
>> 是。

00:46:45.103 --> 00:46:48.020
>> 还没有真正做完
规划存在，但

00:46:48.020 --> 00:46:50.933
将这种版本中，
也的意味着将有

00:46:50.933 --> 00:46:52.980
一个点净标准 2.1
>> 是

00:46:52.980 --> 00:46:54.640
>> 在同一时间。

00:46:54.640 --> 00:46:55.810
>> 因此不能在同一时间，因此，

00:46:55.810 --> 00:46:58.750
我的意思是今天就有点
巧合点网络

00:46:58.750 --> 00:47:01.220
标准 2.1 点净核心 2.1
具有相同的版本号。

00:47:01.220 --> 00:47:02.498
>> 好。
>> 它能被做

00:47:02.498 --> 00:47:05.087
而是.NET 3.0
这样做在.NET 核心 2.0 中，

00:47:05.087 --> 00:47:07.070
他们不是是
为保持同步。

00:47:07.070 --> 00:47:07.570
>> 好。

00:47:09.480 --> 00:47:12.710
>> 我们将引用标准
在同样的时间。

00:47:12.710 --> 00:47:14.278
>> 向右，因此
2.0 不是最后一个版本。

00:47:14.278 --> 00:47:15.454
>> 它不是最后一个，

00:47:15.454 --> 00:47:18.760
有可能会将下一个
要调用 2.1、 2.2、 2.3。

00:47:18.760 --> 00:47:22.066
但可以想象一个世界，
例如，是我们，让我们说，

00:47:22.066 --> 00:47:23.284
我们将添加 2.1 但

00:47:23.284 --> 00:47:26.740
然后相应
恰巧是 2.2 实现。

00:47:26.740 --> 00:47:29.180
这是完全有可能
具体情况取决于如何快速我们 ref

00:47:29.180 --> 00:47:31.810
相对于核心
标准，合适吗？

00:47:31.810 --> 00:47:34.258
因此，核心可能比快的 ref
标准的存在因为

00:47:34.258 --> 00:47:36.808
标准通常会
我们可以在其中的节奏性变化在 ref

00:47:36.808 --> 00:47:39.723
达成一致意见，这是一套新的
您想要无处不在的 Api。

00:47:39.723 --> 00:47:41.410
让我们将其添加到标准中。

00:47:41.410 --> 00:47:42.510
他们形成了一好的组。

00:47:42.510 --> 00:47:44.230
没关系，我们叫 2.1 和

00:47:44.230 --> 00:47:47.020
然后我们所有的工作
对标准的实施者

00:47:47.020 --> 00:47:49.200
隆起及其实现
若要实现 2.1。

00:47:49.200 --> 00:47:50.770
>> 向右，因此
这是基本计划

00:47:50.770 --> 00:47:54.020
这是，新的概念
它们显示在.NET 核心第一？

00:47:55.490 --> 00:48:00.340
他们获得认证，然后有些
要添加到组合

00:48:00.340 --> 00:48:04.750
其他实现如下所示
Xamarin 和.NET Framework 和

00:48:04.750 --> 00:48:07.330
添加到.NET 标准
接下来发生了，是吗？

00:48:07.330 --> 00:48:09.323
>> 的右侧，并
一些 Api，

00:48:09.323 --> 00:48:12.314
可能现有的 Api，我们
然而，还没有标准化

00:48:12.314 --> 00:48:14.011
一些的 Api
可能是新的 Api。

00:48:14.011 --> 00:48:16.746
因此，该新的 API 只是
第一次进入核心，我猜，

00:48:16.746 --> 00:48:19.250
当至少被
从 PCL 的角度看，

00:48:19.250 --> 00:48:21.820
因为这是一部分
这就是开放源代码。

00:48:21.820 --> 00:48:24.525
这就是我们的一部分
请更改相对较快。

00:48:24.525 --> 00:48:27.809
还有常规视图是如果
在混凝土中第一次打赌的 Api

00:48:27.809 --> 00:48:30.044
实施中，和
然后从那里，

00:48:30.044 --> 00:48:31.730
我们将在其他地方。

00:48:31.730 --> 00:48:34.877
>> 是的我猜我们永远不会
实际上即使讨论了这一点，

00:48:34.877 --> 00:48:38.431
在我们的规划，但最终
因为很明显，向上。

00:48:38.431 --> 00:48:39.139
>> 是。
>> 但

00:48:39.139 --> 00:48:43.373
我想我们实际上确实有这
我们只能将事情放在的规则

00:48:43.373 --> 00:48:46.039
.NET 的标准
可以打开源文件。

00:48:46.039 --> 00:48:48.210
>> 是的我的意思是的
逻辑的副作用

00:48:48.210 --> 00:48:49.920
使用堆栈被开源。

00:48:49.920 --> 00:48:52.351
>> 是，好的没关系。

00:48:52.351 --> 00:48:53.850
>> 然后这是这么多了。

00:48:53.850 --> 00:48:57.209
>> 是，好的嗯，人
有邻居来与您联系。

00:48:57.209 --> 00:48:58.360
>> 的罚款。

00:48:58.360 --> 00:49:00.540
>> 阅读我们的博客，
这是太棒了。

00:49:00.540 --> 00:49:01.510
我学到了很多。

00:49:01.510 --> 00:49:03.150
>> 是，
我非常喜欢它这么多了。

00:49:03.150 --> 00:49:04.170
>> 好了，谢谢各位

00:49:04.170 --> 00:49:06.966
观察另一个
在.NET 的集。

00:49:06.966 --> 00:49:08.796
非常感谢。

00:49:08.796 --> 00:49:09.296
>> 再见。