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
20 표준.NET에서 심층입니다.

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
>> 지키는 2 내가 본 경험이
이 작동 하는 년.

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
>> 몇 개의 슬라이드를가지고 I 다음
저는 데모 톤도 하 고

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
생각
자세한 내용입니다.

00:01:09.970 --> 00:01:11.730
메서드를 호출 하지 않을 수 있습니다 대로
자세한 내용은 있지만

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
>> I에 유의 해야 합니다.

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
비-창, 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 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
따라서 Pr를 사용할 때 사용
.NET에서 PRs 적용

00:02:32.390 --> 00:02:35.050
때문에 그 집의 핵심
여기서는 파티입니다.

00:02:35.050 --> 00:02:37.740
그곳에서 보고 하 고
net framework 또는 모노, 또는

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
>> 좋아요 말
3의 1을 더한

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
따라서 새 상상할 수 있습니다
네트로 기본적으로 표준

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
이전의 수 없습니다.
5 년 전 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
이 생각의 모든 honesty
실제로 가장 큰 공통 비슷합니다.

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
차이점은
더 많은 대.

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
정말 기 주제에 멍한
이 비디오를 가져올.

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
단어 대입니다.

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
이 대해 생각 하는 테이블
>> 단지 수는 jerk를

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 framework가 고

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, Unity입니다.

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
사실, 약 20, 000 추가
Api와.NET 표준에 비해

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 framework를 사용 하는

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 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
하셨는데 교차
4.7 예를 들어,.NET framework 및

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 Api Xamarin를 부탁 드렸습니다

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을 일종의 lumped는 것

00:12:10.390 --> 00:12:12.305
Kinda 이기 때문에 핵심
같은 코드 베이스에서 모두입니다.

00:12:12.305 --> 00:12:14.064
>> Mm hm입니다.
>> 표시 되지 않도록 하기 위해

00:12:14.064 --> 00:12:17.523
때문에 불행 하 게도 있음
UWP에 다양 한 런타임

00:12:17.523 --> 00:12:19.931
보다 환경
표준 창 않습니다.

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] 라고
호환성 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
데모는 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
승리 양식을 사용 하는 경우
예제에서는

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
단지 기존의 참조
프레임 워크 패키지

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
멋진 될 경우 I
현재 말할 수 있습니다.

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
이미 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
>> 자 ~
매우 전략적인 것

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
>> 올려 테이프에
public이 지금입니다.

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
실제로 종료 된 패키지
Pr에 직접 전송 구성-

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
>>와 해당 Pr 사용 된?

00:15:40.550 --> 00:15:41.540
>> 대부분의 경우 예.

00:15:41.540 --> 00:15:44.720
일정 시간 했습니다
델타 X 1

00:15:44.720 --> 00:15:47.930
코브라는 매우 큰이 고
하지 않은 사람들이 그런 느낌을

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
따라서, 기본적으로, 있는 것
Northwind는 고

00:16:30.647 --> 00:16:32.096
개발은 누구 든 지에 대 한

00:16:32.096 --> 00:16:33.920
아주 오래 된
Northwind를 인식 합니다.

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
Northwind를 찾아보십시오
이제 퇴직 하는 사람

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
데이터베이스 표현
한 일.

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 1에서 이동합니다.

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
에 기본 우리를 지키.

00:18:46.550 --> 00:18:47.450
>> 예.

00:18:47.450 --> 00:18:50.130
>> 1 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
따라서 필자가 사용한
10 년 전,

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
>>는 I
여전히 시간을 했습니다.

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
[들리지 않음] 복원
461.NET framework를 사용 하 여.

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
탐색을 시각적으로, 내 말은,
파일 우편 번호 단지 것 이지만

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
직접 확인해
it가 정상적으로 작동 합니다.

00:22:41.910 --> 00:22:45.030
수를 효과적으로
방금 경고를 표시 하지 않습니다.

00:22:45.030 --> 00:22:48.840
이와 같은 여기에서 볼 수 있듯이
여기에서 숫자

00:22:48.840 --> 00:22:50.990
뉴는 1, 7, 또는
경고 번호를 하나

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
>> 따라서
한 가지 놀 I

00:23:10.090 --> 00:23:12.750
최근에 어떤이
주말, 또는 지난 주입니다.

00:23:12.750 --> 00:23:17.090
놀 I
경고 오류입니다.

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
처럼 볼 수 있습니다
2.0, 1.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
Framework에서 실행할 수 있습니다.
버전 번호가 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
이 파란색 막대가 말하곤 했습니다.
에 대 한 프록시 같은 kinda은

00:27:03.168 --> 00:27:04.412
수 있다고 하는 Api입니다.

00:27:04.412 --> 00:27:08.646
따라서 어 볼 수 있는
SUMJUM 1.0 및 1.1 사이 고

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
20, 000가 넘는 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
>> Mm 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
최신가
버전 관련 FAQ로 이동 합니다.

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
직관적인 kinda은 있지만
지적 가치가 여전히

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.4, 1.6, 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
만 수 있습니다.
다른 노트북을 참조 합니다.

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
누구라도 현재
발생 하는 월 식 [웃음].

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 Win 표현 하 고

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
>> 두 double입니다.

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
GpsLocation, Gps 네임 스페이스
GetCoordinates 튜플입니다.

00:34:33.903 --> 00:34:36.784
실제로 보이는 정확 하 게는
RT Win 버전 간에 동일

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 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이 패키지를 참조
3 내 모든 컴파일할.

00:35:45.410 --> 00:35:46.520
>> 권한입니다.
>> 고 말할 수 있습니다.

00:35:46.520 --> 00:35:49.040
framework를 대상으로 하는 경우
이 추가 내용을 하 고 싶습니다.

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
>> 사용 하는 듯한 느낌을 I
다시 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
>>는 3 개의 폴더와
내 수, NuGet을 얻을

00:37:14.860 --> 00:37:16.630
또한 폴더 세 개를 얻을 수 있습니다.

00:37:16.630 --> 00:37:18.350
3 개의 바이너리를 사용 하 여
우리가 방금 생성 되므로

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
제가 고객 요청을 할 수 있습니다
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
>> M m입니다.

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 geo 위치를 사용 합니다.

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
따라서 우리의 경우에 하는
4 개의 프로젝트를 했습니다.

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
>> 내가 지키는 공유 프로젝트를 참조 하십시오
이 거의 같은 가상

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
4 개의 프로젝트를 올려야 하지만
하지만

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
>> 오른쪽, 즉 analagous
.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
버그 수정을 확인 해야 하는 시간
플랫폼의 하나로

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
.NET 중심의 API 서비스
자신과 아직 방패

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 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
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
Super 응답 거 야
전자 메일에 내가 고용 했습니다.

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
Get을 가정 하 고
단지 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
>> 자, 것 같아 kinda
닫기 여기로 오고 있습니다.

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
내 말은 오늘날 어느 정도
net를 점 하는 단어가 나타날

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
>> 표준 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
>> Bye입니다.