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
>> Cuz，我已經花了兩個
這項工作的年。

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 framework 中。

00:01:09.970 --> 00:01:11.730
它們可能不會呼叫它
.NET framework 但

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 的 Io，
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 framework 中，但是

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
平台 A 決定要執行的位置
一些位元的項目過期

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
>> 因此
您無法在本質上，bifurcate

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
>> 我想的是，則為 true。

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
word 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，已
為 1x 系列的最高版本。

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 framework

00:11:10.628 --> 00:11:13.058
並採取 Xamarin，並
塑造交集。

00:11:13.058 --> 00:11:15.148
因為這基本上是
良好的 proxy 得到

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

00:11:17.073 --> 00:11:19.937
它們仍然非常類似於
.NET framework 的有。

00:11:19.937 --> 00:11:21.587
而且我們也加入一些然後
只在中的 Api

00:11:21.587 --> 00:11:23.280
.NET framework，
沒有 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 framework，例如 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
>> 不開始運轉規格。

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，在第一個投影片上，
它有種 lumped 上，使用.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
因此沒有發生的工作
若要新增 OS 支援應用程式

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] 我們的呼叫
相容性 shim 或

00:13:16.262 --> 00:13:19.585
相容模式中，這基本上
可讓您將參考 Nuget

00:13:19.585 --> 00:13:22.980
封裝，其實只有
現今在.NET framework 上運作。

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
而且沒有示範鉅，
可能有點說明

00:13:32.585 --> 00:13:34.766
更佳的性能，但這裡的想法
它是最佳的工作項目。

00:13:34.766 --> 00:13:37.037
因此，我們不知道什麼
文件庫會執行。

00:13:37.037 --> 00:13:39.123
如果它使用贏得的表單
範例中，

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
使用 blah 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
已經 de facto
它的相容還是。

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
>> 也很簡單，
如果我們 super 策略，

00:14:50.669 --> 00:14:54.222
我們會說，似乎
這些是 100

00:14:54.222 --> 00:14:58.301
最受歡迎的程式庫，
只有.NET framework。

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
眼鏡蛇很大，但
和人不像

00:15:47.930 --> 00:15:51.790
這就好像是很
我同事 pays 的干擾。

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
與 maintainer。

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
讓我們假設，Northwind 資料。

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
是預設為的 cuz。

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
不完全正確，
它 modernizes 多多練習，

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
>> 的太則為 true。

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
如果我在查閱 lip
從 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 framework 和
二進位檔。

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
這是兵一個、 七個，或
一個是警告編號

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
放火燒毀現在與
VS 的最新版本是它們

00:23:41.040 --> 00:23:44.453
種之間的差距
警告和警告

00:23:44.453 --> 00:23:49.330
從因此他們都是用相同
UI 和相同的經驗。

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
我會說，兵。

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
您有多個範圍、 cuz
更多的平台支援，

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 framework 二進位碼檔案

00:30:43.145 --> 00:30:43.691
這很豐碩。

00:30:43.691 --> 00:30:45.692
因為通常最大
可攜式、 的事

00:30:45.692 --> 00:30:47.606
您無法只
參考其他的 portables。

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
利用地球上找到
geolocation 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
不論您是目前
遭遇 （蝕色） [笑聲]。

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
我想要共用公用的 Cuz
可以存取 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
但基本上什麼我所傳回
對您代表一個 tuple 的

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 的 Cuz。

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
不提取 lat 和長
超出它。

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
您不想看到我的 Cuz
而打我不存在

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
您只需要一些和
在 [程式碼基底 ifdefs。

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 framework 中，
.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
它們做了某些事
不同的平台 A 和

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
我一定辦公用 bool
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
另一個則用於另一個則用於.Net 的 ewp
架構中，一個共用的專案。

00:39:27.050 --> 00:39:29.950
>> 看 cuz 共用的專案
就類似虛擬

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 的
服務必須公開 （expose）。

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
office 會停止編譯和

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
一般的 if？

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 framework 端。

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
可能沒有某些
不相關。

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
因此，比方說，我們想要尋找
出實際上是在文件中，

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
它是超級回應吧？

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
我要有 super 回應
我們雇用電子郵件，

00:46:15.480 --> 00:46:18.370
額外的手可以擊中我
上比在電子郵件上的 Twitter。

00:46:18.370 --> 00:46:19.450
>> 是的是您所執行的 cuz。

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
>> 的完全，則為 true，然後
我太太取得 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
有點 net 標準 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
它們不一定
處於 lockstep。

00:47:07.070 --> 00:47:07.570
>> [確定]。

00:47:09.480 --> 00:47:12.710
>>，我們將 ref 標準
經過一段時間也。

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
>> 再見 ！。