Runtime: 유형별 상속 보안 규칙 위반 : 'System.Net.Http.WebRequestHandler'. 파생 유형은 기본 유형의 보안 액세스 가능성과 일치하거나 액세스 가능성이 낮아야합니다.

나는 오늘 다른 보고서에서 이것을 보았습니다. / cc @ChadNedzlek

이는받은 편지함 System.Net.Http.dll과 비교하여 대역 외 System.Net.Http.dll의 보안 특성이 누락 되었기 때문일 수 있습니다. 받은 편지함 버전에는 AllowPartiallyTrustedCallers가 있습니다. 받은 편지함 System.Net.Http.WebRequest.dll도 마찬가지입니다. 즉, 달리 주석을 달지 않는 한 모든 것이 SecurityTransparent로 처리됩니다.

OOB System.Net.Http.dll에는 AllowPartiallyTrustedCallers가 누락되어 모든 보안이 중요합니다. 이제받은 편지함 WebRequest.dll이 OOB System.Net.Http.dll을로드 할 때 WebReqeuestHandler가 투명하기 때문에 보안 규칙을 위반하지만 파생 된 HttpClientHandler가 중요합니다.

내 재현 :

1. 파일> 새 데스크톱 애플리케이션
2. 프로젝트 속성> 서명> 강력한 이름 서명 활성화
3. System.Net.Http.WebRequest에 대한 참조 추가
4. System.Net.Http 4.1.0을 설치합니다.
5. 기본적으로 new WebRequestHandler ();

ericstj가 맞습니다. 여기에도 같은 문제가 있습니다. 이것은 System.Net.Http 4.1.0에서 복구해야하는 중요한 문제입니다. 일관성이 부족하기 때문에 .net4.6.1과 함께이 라이브러리를 사용할 수 없습니다.

이 문제는 처리하기가 매우 어렵고 특히 Azure KeyVault 클라이언트를 사용하는 것이 우리 팀에게 고통 스럽습니다. 유일한 대안은 허용되지 않는 .NET 4.5.2로 다운 그레이드하는 것입니다.

또한 이전에 나열된 해결 방법이 충분하지 않습니다. NET 4.6.x를 사용하려는 경우 안정적으로 작동하려면 다음을 수행해야합니다. 종속성 검사 비활성화, System.Net.Http 다운 그레이드, CSPROJ 편집 및 자동 바인딩 리디렉션 비활성화, 수정 app.config, 일반적으로 VS를 정리 / 종료하고 사소한 프로젝트에서도 System.Net.Http가 사용되는 것을 자주 보았으므로 다시 빌드하십시오. 이 문제를 안정적으로 수정하는 절차는 다음과 같습니다.

1. Visual Studio에서 프로젝트를 마우스 오른쪽 단추로 클릭하고 NuGet 패키지 관리를 선택합니다.
2. 설치된 탭으로 이동하십시오.
3. Microsoft.Net.Http가 아닌 SYSTEM.Net.Http로 스크롤합니다.
4. 오른쪽 창에서 설치됨이 4.0.0.0이 아닌 경우 버전을 4.0.0.0으로 설정합니다.
5. 오른쪽 창에서 종속성 동작을 종속성 무시로 설정합니다. 이렇게하지 않으면 Microsoft.IdentityModel.Clients.ActiveDirectory 패키지가 상당히 다운 그레이드되며 이는 올바르지 않습니다.
6. 업데이트를 클릭합니다.이 버튼은 실제로 "버전으로 변경"이라는 레이블이 지정되어야합니다.
7. 미리보기 창에서 나열된 유일한 변경 내용이 "Installing System.Net.Http"인지 확인합니다. 종속성 동작을 올바르게 설정하는 것을 잊은 경우 추가 변경 사항이 여기에 나열됩니다.
8. 확인 대화 상자에서 확인 / 예 / 동의를 클릭하고 처리가 완료 될 때까지 기다립니다. 완료되면 패키지 목록에 두 개의 버전 번호가 표시됩니다. 확인 표시는 사용중인 버전 옆에 있습니다.
9. NuGet 설치 탭에서 Microsoft.IdentityModel.Clients.ActiveDirectory 목록을 선택합니다.
10. 오른쪽 세부 정보 창에서 종속성 동작을 "무시"로 설정합니다. 이렇게하지 않으면이 패키지에 대한 NuGet의 유효성 검사가 실행될 때 후속 NuGet 추가가 실패합니다.
11. Visual Studio에서 File | Save All을 선택합니다.
12. 텍스트 편집기에서이 프로젝트의 CSPROJ 파일을 엽니 다.
13. / Project / PropertyGroup * 1 (Project의 첫 번째 PropertyGroup 요소)에서 다음 행을 추가하거나이 요소가 이미있는 경우이 요소의 값을 변경하십시오.
    <AutoGenerateBindingRedirects>false</AutoGenerateBindingRedirects>
14. 파일을 저장 한 다음 Visual Studio에서 프로젝트를 다시로드합니다.
15. 이 프로젝트의 app.config 파일을 엽니 다.
16. System.Net.Http에 대한 줄을 찾아 편집하여 4.1.0.0 대신 4.0.0.0으로 리디렉션합니다. 그래서 이것을 찾으십시오.

<dependentAssembly> 
<assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" /> 
<bindingRedirect oldVersion="0.0.0.0-4.1.0.0" newVersion="4.1.0.0" /> 
</dependentAssembly> 

다음으로 변경하십시오.

<dependentAssembly> 
<assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" /> 
<bindingRedirect oldVersion="0.0.0.0-4.1.0.0" newVersion="4.0.0.0" /> 
</dependentAssembly> 

1. 프로젝트를 다시 빌드하십시오. Azure Key Vault 코드를 실행할 때 예외가 발생하면 bin / debug 또는 유사한 디렉터리에있는 하나 이상의 * .config 파일이 업데이트되지 않은 것입니다. Visual Studio를 종료하여 지우고 다시 빌드해야 할 수 있습니다.

dluxfordhpf,이 문제를 어떻게 해결했는지 설명 해주셔서 감사합니다. System.Net.Http 4.0으로 리디렉션하면 .net4.6.1에서 저에게 효과적이지만 여전히 유지하기가 매우 어렵습니다 (너겟 종속성). 이 문제를 해결할 버전을 기대합니다.

리디렉션은 System.Net.Http 4.1.0에 추가 된 새 API를 사용하는 경우 문제를 일으킬 수 있습니다.

특히 Azure KeyVault 클라이언트를 사용하는 것이 우리 팀에게 고통 스럽습니다.

@ChadNedzlek 은 같은 문제를 가지고 있었고 그가 직접 만든 HttpClient를 KeyVaultClient 생성자에 전달함으로써 문제를 해결할 수있었습니다. WebRequestHandler를 사용하지 않으면 문제를 피할 수 있습니다.

예 :

c# var handler = new HttpClientHandler(); // configure handler // eg: handler.ServerCertificateCustomValidationCallback = (message, cert, chain, errors) => errors == SslPolicyErrors.None; var client = new HttpClient(handler); var kvclient = new KeyVaultClient(async (authority, resource, scope) => "foo", client);

@davidsh System.Net.Http.dll에 AllowPartiallyTrustedCallers 다시 넣어야한다고 생각합니다. / cc @morganbr

@dluxfordhpf 단계에 감사드립니다.
일시적이며 곧 수정되기를 바라지 만 여전히 프로젝트 작업을 계속할 수 있습니다!

@terrajobst 이것은 차단 생산 문제입니다. NuGet에 대한 수정 사항을 언제 얻을 수 있는지 아십니까? 감사!

이 문제를 직접 만났습니다. .Net에서 의존성 지옥으로 내려 가지 않았다면 멋질 것입니다. 그 방향으로 가고 있습니다.

편집 : 시스템 httpclient ??를 사용하기위한 이전 의견 제안으로 수정되었습니다.
new KeyVaultClient(GetAccessToken, new HttpClient(new HttpClientHandler()))
그것을 얻은 것 같았습니다 ...

Microsoft의 Nuget 패키지가 점점 더 최신 버전의 System.Net.Http에 종속됨에 따라 문제는 더욱 악화되고 있습니다. Microsoft nuget 패키지를 최신 시험판 버전으로 지속적으로 업그레이드하는 유일한 사람은 나만이 아닐 것입니다. 예를 들어 최신 버전에서 더 이상 작동하지 않는 패키지 :

Microsoft.IdentityModel.Clients.ActiveDirectory
Microsoft.TeamFoundationServer.Client
Microsoft.VisualStudio.Services.Client.
....

이 패키지를 계속 사용할 수있는 이유를 여전히 이해하지 못합니다. @terrajobst @coolcsh 이 패키지를 제거 / 수정할 수 있습니까? 복잡한 앱 환경에서 실제로 문제를 일으키고 있습니다. 문제가되는 패키지가 빌드에 들어가는 것을 방지하기 위해 몇 시간을 낭비했습니다. 감사!

우리는 NuGet에서이 깨진 것 대신 NET Framework의 System.Net.Http에 대한 바인딩을 찾고 있습니다. 이 문제는 프로젝트간에 NuGet 버전을 동기화하고, 자동 바인딩 업데이트를 방지하고, app.config를 수정 / 확인해야하므로이 문제는 터무니없고 처리하는 데 매우 비쌉니다. 놀랍게도 널리 사용되는 어셈블리에 있습니다. 아마도 MS는 KeyVault에 그다지 관심이 없습니까?

ActiveDirectory Nugget에서도 사용됩니다.

이 문제 및 손상된 NuGet 패키지가 .NET Standard를 대상으로하는 앱을 엉망으로 만드는 관련 문제로 인해 일부 라이브러리를 .NET Standard 대상에서 되돌 렸습니다. 이것은 미안한 상황입니다.

제출해 주셔서 감사합니다. 우리는 이것을 적극적으로 조사하고 있습니다. 계속 지켜봐주세요.

이것은 저에게 중요한 문제가되었습니다. 우리는 내부적으로 많은 자체 너겟 패키지를 사용합니다. 그리고 그것은 단지 bindingRedirect 혼자 두지 않을 것입니다. 내부 패키지 중 하나를 업데이트 할 때 마다 리디렉션이 newVersion="4.1.0.0" 다시 변경됩니다. 그것을 막을 방법이 있습니까, 아니면 수평선에 수정 사항이 있습니까?

HTTP를 통해 제대로 작동하는 HTTPS를 통해 애플리케이션을 실행할 때 발생했습니다. 다른 중요한 차이점이 있는지 확실하지 않습니다.
newversion="4.0.0.0" 설정의 해결 방법이 저에게 효과적이었습니다.

NETStandard 1.6.1에서 여전히 문제입니다. 왜?!

System.Net.Http 4.3.0이 나왔습니다. 누군가 시도 했습니까?

@LoulG 그래, 여전히 문제가 두렵습니다.

나는 트위터에서 @terrajobst 와 이야기를

@LoulG는 여기서 .net 코어 1.1의 릴리스로 모든 Nuget 패키지를 업데이트 했으며이 문제가 발생했습니다.

System.TypeLoadException : 유형별 상속 보안 규칙 위반 : 'System.Net.Http.WebRequestHandler'. 파생 유형은 기본 유형의 보안 액세스 가능성과 일치하거나 액세스 가능성이 낮아야합니다.

첫째, 나는 그것이 IdentityServer / IdentityServer3.AccessTokenValidation 때문이라고 생각하지만,이 문제를 읽음으로써 나는 내 상황 t_t를 이해하고 그것을 해결하기 위해 몇 시간을 보냈다.

편집하다 :
OMG,
newversion = "4.0.0.0"설정의 해결 방법이 저에게도 효과적이었습니다.

4.3으로 업데이트하려고하지만 같은 문제 : (((

업그레이드 후 여기에 동일한 문제

4.3.0에서 여전히 문제가 있습니다.

@terrajobst 이 문제에 대한 업데이트 나 @robertmclaws가 언급 한 더 깊은 문제에 대한 추가 정보를 제공 할 수 있습니까?

이 수정이 로컬로 작동하지만 Azure 클라우드 서비스에 배포 할 때 오류가 지속되는 이유는 무엇입니까?

때때로 Azure를 패키징하면 바인딩 리디렉션이 망가질 수 있으며 cspkg의 압축을 풀고 실제로 배포되는 항목을 확인합니다.

다음은 System.Net.Http.dll의 버전입니다.

나는 이것에 대해 며칠 동안 일하고 있습니다. Azure에 배포 할 때이 수정 사항을 찾아서 매우 기뻤습니다.

프로젝트에 대한 바인딩 리디렉션이 포함 된 .config 파일은 어떻습니까? 실제로 CopyLocal이 nuget 패키지에서 true이기 때문에 어셈블리의 깨진 버전을 계속 배포 할 것으로 예상하지만 바인딩 리디렉션은 어셈블리의 프레임 워크 버전이 클라우드 서비스 VM 내부에 대신로드되도록해야합니다.

그것은!!! WTH?

<dependentAssembly> <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" /> <bindingRedirect oldVersion="0.0.0.0-4.1.1.0" newVersion="4.1.1.0" /> </dependentAssembly>

내 프로젝트를 다시 살펴보면 web.config도 되돌아갔습니다. 아침에 이걸 다시 가져와야 해요. 단서를 주셔서 감사합니다!

AutoGenerateBindingRedirects를 사용하고 프로젝트에 대한 nuget 패키지를 수정하면 이전에 수동으로 수정 한 리디렉션이 손상된 버전으로 다시 "수정"됩니다. 매우 실망 스럽습니다.

그러나 문제의 일부는 새 패키지를 추가 할 때 AutoGenerateBindingRedirects를 사용하지 않으면 다른 문제도 발생할 수 있다는 것입니다.

나는 우리 앱의 새 버전을 배포해야하는 동안 일주일 넘게이 말도 안되는 일을 다루었습니다. 내가 제안 할 수있는 최선의 방법은 배포 할 때마다 web.config를 확인하는 습관을 갖는 것입니다.

예, CSPROJ에서 수동 편집을 통해 바인딩 업데이트를 비활성화 한 다음 .config 바인딩 리디렉션을 수정하고 종속성을 업데이트하지 않도록 GUI에서 NuGet을 재구성해야합니다. 그러면 괜찮습니다. 예, 이것은 주요 PITA입니다. 너무 오래 생산되어서 놀랐습니다. 우리 팀은 몇 달 동안 정기적으로 저주를 해왔습니다.

불행히도 위의 내용을 따르면 여전히 azure prod가 아닌 내 개발 환경 만 수정됩니다. 최신 pub 파일을 확인한 결과 web.config가 위에 표시된 버전으로 게시 된 내 dll과 함께 올바르게 설정되었습니다. 불행히도 내 문제는 Azure Search 라이브러리와 관련이 있으므로이 수정은 유망한 것으로 입증되었습니다. 다른 아이디어가 있습니까? 약간의 손실이 있습니다. 도와 주셔서 감사합니다.

2 개월 이상 된 이유는 무엇입니까? 이것은 큰 문제입니다. 고쳐주세요.

이것은 완전히 스톱 쉽 문제이며 반드시 해결되어야합니다.

f # $ @의 경우, 이미이 문제를 해결하십시오. 이것은 어리 석다.

@suprduprmn 모든 패키지를 업데이트하고 통합 한 다음 모든 app.config 및 web.config 파일에서이를 변경했습니다.

<bindingRedirect oldVersion="0.0.0.0-4.1.1.0" newVersion="4.0.0.0" />

그래야만 내 웹앱이 Azure에서 시작되고 System.Net.Http에 의존하는 Azure 서비스에 대한 https 호출을 할 수 있습니다. YMMV이지만 행운을 빕니다.

그리고 @terrajobst ... 이와 같은 주요 문제를 무시하는 것에 대해 공식적으로 불평 할 수있는 적절한 장소가 있습니까? 오픈 소스의 행운의 규칙은 여기에 적용되지 않습니다. 이것은 1995 년경 Microsoft Showstopper 101 항목입니다. "커뮤니티"가 도울 수있는 방법은 없습니다. 당신은 그것을 고쳐야하고 당신은 그것이 일어나지 않게하기 위해 도구와 프로세스를 설계해야합니다. 여러 Microsoft 프로젝트에서 이와 같은 것을보고 있는데 완전히 용납되지 않습니다. 테스트에 큰 격차가 있다는 것은 분명합니다. 기본 시나리오는 런타임에 제대로 작동하는 것은 말할 것도없고 단순히 설치하거나 새로 빌드하지 않습니다.

이 문제에 대응하는 데 오랜 시간이 걸린 XXXL에 대해 사과드립니다. 마지막 응답 이후 1 개월이 지났으며 문제는 3 개월 이상 열렸습니다. 이와 같이 영향력이 큰 문제에는 이것이 허용되지 않는다는 데 동의합니다.

그것은 오늘 아침에 제 관심을 끌었고 지난 몇 시간 동안 역사적인 발굴을 시도했습니다. 좋은 소식은 올바른 사람들이 지난 몇 주 동안 문제를 조사하고 있다는 것입니다 (아마도 더 오래, 모든 기록을 확인하지 않았을 수도 있음). 슬프게도 솔루션은 매우 복잡합니다. (그래서 아직 좋은 답변이나 ETA가 없습니다 (우리 측의 업데이트 부족에 대한 변명은 아니지만).
몇 가지 잠재적 인 해결책이 있지만 전문가조차 아직 합의하지 않았으며 각각에 대한 단점이 있습니다.
다음 주에 문제에 대한 일일 동기화를 시작하여 가능한 한 빨리 문제에 대한 해결책을 찾을 것입니다. 적어도 매주 업데이트가있을 때 업데이트를 게시 할 것입니다.

안타깝게도이 시점에서 제가 할 수있는 최선의 방법입니다 (즉, 진지하게 사과하고 확신하며 진지하게 대우하고 최대한 빨리 해결하기 위해 최선을 다할 것입니다). 대안 제안이있는 사람은 모두 귀입니다.

@karelz 지금 당장 문제를 실제로 해결하는 데 팀의주의를 분산시키고 싶지는 않지만 개인적으로이 문제의 근본 원인과 QA를 통해 어떻게 진행되었는지에 대한 사후 분석을 듣고 싶습니다. 이것은 큰 골칫거리를 일으켰고 투명성이 어느 정도 신뢰를 얻을 것이라고 생각합니다.

@jahmai 이해했습니다. 저도

응답 해 주셔서 감사합니다. 현재 가장 좋은 해결책은 System.Net.Http 4.0.0을 가리 키지 않는 패키지를 비활성화 하는 것 입니다. 불량한 패키지 버전이 2 개 이상 있습니다. 처음부터 NuGet을 통해이 물건을 배포하는 것이 중요하지 않나요?

ms 팀 @ 포옹

또한 아시다시피이 문제 사이에 HttpClient 관련 문제가 너무 잘못 설계되고 Microsoft.Security.Owin.Jwt 관련 문제가 현재 종속성에 대해 손상되고 .NET Core의 상태 ...

지금은 .NET 개발자가 되려면 엄청나게 실망스러운 시간입니다. 이제 각 배포에는 30 분 동안 어셈블리 바인딩 참조를 확인해야하므로 프로덕션에서 앱이 손상되지 않습니다. 이것은 내가 오랫동안 옹호해온 Microsoft가 아닙니다. 여러분을 사랑하고, 전혀 가혹하고 싶지 않습니다 ...하지만 현재의 질을 회복하기 위해서는 힘든 사랑이 필요한 것 같습니다.

무엇이든해야합니다. 이전 4.0 패키지를 참조하는 4.3.1을 배송하는 것을 의미하더라도. 제발 곧하세요.

감사합니다. FWIW, 브레이킹 체인지가 필요하다면 그렇게하세요. 우리는 이것을 싫어하지만, 우리는 몇 달 동안 고통을 안고 살아 왔고 이제 우리는 당신이 참여하고 있다는 것을 알았으므로 API를 약간 변경해야하더라도 몇 가지 더 기다릴 수 있습니다.

여기에 뭔가가 있습니다. 저는 15 년 동안 C # 앱을 출시했습니다. 아이러니하게도 Microsoft에서 더 높은 수준의 추상화를 제공함에 따라 이전에는 걱정할 필요가 없었던 내부를 깊이 파고 드는 데 점점 더 많은 시간을 소비하고 있습니다. 당신은 잘못하고있다.

이 라이브러리에서 신뢰 플래그를 되 돌리는 것이 왜 큰 문제인지 이해할만큼 똑똑하지도 않고 내 앱에서 더 많은 제어 권한이없는 이유도 이해하지 못합니다.

런타임에 컴파일러가 포착하지 못한 임의의 라이브러리와 패키지 관리로 인한 오류에 놀라고 싶다면 Ruby로 앱을 작성했습니다.

빠른 업데이트:
이번 주에 여러 번 만났습니다. 우리는 옵션을 브레인 스토밍하고 자금을 파악했습니다.
@CIPop 은이 문제에 대해 최우선 과제로 작업하고 있습니다 (다음 주부터 나머지 연도 동안 OOF가 될 @davidsh 에서 작업을 전환했습니다).

상태:

• @onovotny 의 원래 재현을 재현하고 작은 재현을
• 우리는 아래의 해결책 [3]을 추구하고 있습니다-나머지 미해결 질문에 초점을 맞추고 있습니다. 즉, 옵션의 기술적 타당성을 검증합니다.
• 우리는 아래의 병렬 솔루션 [2]에서 스카우트하고 있습니다. 즉, 솔루션이 생태계에 미치는 영향을 평가하는 공개 질문을 스카우트합니다.

문제 설명

• 6 월에 System.Net.Http 4.3.0.0“OOB”를 출시했습니다.
  
  
  
  • 주목할만한 콘텐츠 (이 컨텍스트의 경우) : HttpCient, HttpClientHandler
  
  
  • 고객 가치 : 인증서 지원, http2 지원, 데스크톱의 WinHttp 스택
  
  
  • 데스크톱을 제외한 모든 플랫폼이 정상적으로 작동합니다. 데스크톱의 경우 API 표면에 PartialTrust 코드에 대한 SecurityAttributes가 없습니다 (APTCA = AllowPartialTrustCodeAttribute).
  
  
  • Desktop에서 OOB 라이브러리는 플랫폼의 일부이며 APTCA가있는 System.Net.Http 4.0.0.0의 사용을 재정의합니다.
  
  
• System.Net.WebRequestHandler 4.0.0.0은 Desktop의 일부입니다.
  
  
  
  • System.Net.Http에 의존하고 APTCA가 있으므로 APTCA를 갖기 위해서는 System.Net.Http가 필요합니다.
  
  
  • System.Net.Http (InternalsVisibleTo가 있음)의 내부 형식을 사용합니다.
  
  
  • .NET Core에서 원하지 않는 "지루한"레거시 유형입니다.
  
  
• OOB System.Net.Http 4.3.0.0과 System.Net.WebRequestHandler 4.0.0.0에 대한 참조를 (간접적으로) 가져 오는 라이브러리 (3 개 이상의 NuGet 패키지 및 데스크톱의 ASP.NET Core 앱)가 있습니다. 콤보는 응용 프로그램이 실행되지 않도록합니다.

솔루션

1. [허용되지 않음] 수동 바인딩 리디렉션 – 애플리케이션 별 수동 다운 그레이드 (바인딩 리디렉션을 통해) System.Net.Http 4.3.0.0에서 4.0.0.0으로 – 무엇 / 어디서인지 이해하기 어렵고 앱별 수동 단계입니다.
   
   
   
   • 참고 : 오늘은 "해결 방법"으로 사용됩니다.
   
   
2. [후보] OOB 결정 실행 취소 – 4.3.1.0을받은 편지함 데스크톱 4.0.0.0으로 재전송합니다.
   
   
   
   • 단점 : 새로운 기능에 의존하는 고객을 깰 것입니다.
   
   
   • 열린 질문 : 데스크톱의 WCF 또는 기타 NuGet 라이브러리가 영향을 받나요?
   
   
3. [후보] System.Net.Http에 보안 특성을 뿌리십시오.
   
   
   
   • Desktop에 대해서만 수행하고 (#if 사용), 다른 패키지에 전파하지 말고 (Desktop 참조에 대해 컴파일), 나중에 적용 할 테스트를 추가하십시오.
   
   
   • 단점 : System.Net.Http의 데스크톱 구현과 관련된 일부 WebRequestHandler 속성이 작동하지 않습니다 (구현을 전환 할 때 설계 상).
   
   
   • 기술 노트 : 비동기 메서드는 SecurityTransparent (Roslyn 컴파일러 제한) 여야하므로 (SecurityCritical) PInvoke를 호출 할 수 없습니다. 이러한 각 PInvoke 호출에 대해 SecuritySafeCritical 래퍼 메서드가 있어야합니다 (다소 추악하지만 간단 함).
   
   
   • 열린 질문 : WebRequestHandler의 내부 종속성을 새로운 WinHttp 기반 System.Net.Http와 함께 사용할 수 있습니까?
   
   
4. [거부 됨] 데스크톱에서만 OOB WebRequestHandler
   
   
   
   • 단점 : 문제를 밀어 붙입니다 (일부 APTCA 어셈블리가 이에 의존).
   
   
   • 단점 : System.Net.Http의 데스크톱 구현에 특정한 일부 WebRequestHandler 속성이 작동하지 않습니다 (설계 상) – 위의 [3] 참조
   
   
   • 단점 : 모든 사람이 종속성을 추가하거나 NuGet에 최신 버전을 설치하도록 지시해야합니다.
   
   
5. [CANDIDATE] System.Net.WebRequestHandler.dll을 System.Net.Http NuGet 패키지로 번들링
   
   
   
   • 위의 [4]와 같은 2 가지 단점 :
     
     
     
     
     
     1. 단점 : 문제를 밀어 붙입니다 (일부 APTCA 어셈블리가 이에 의존).
     
     
     
     2. 단점 : System.Net.Http의 데스크톱 구현에 특정한 일부 WebRequestHandler 속성이 작동하지 않습니다 (설계 상) – 위의 [3] 참조
     
     
     
   
   

자세한 정보를 주셔서 감사합니다. 감사합니다.

옵션 2의 조합과 4.3을 5.0으로 재배송하는 것은 어떻습니까? 기술적으로 중요한 변경 사항이므로 데스크톱 용 OOB WebRequestHandler.dll도 v5.0으로 제공 할 수 있습니다. 그러면 WinHttp에서 기능을 다시 구현하고 매핑되지 않는 속성을 사용하지 않으며 SemVer가 허용하는 방식으로 모든 사람이 앞으로 나아갈 수 있습니다. 업스트림은 여전히 ​​코드를 수정해야하지만 메이저 릴리스에서는 예상치 못한 일이 아니며 5.0을 포함하지 않도록 패키지를 상위 바인딩 할 수도 있습니다.

내 말은, 전체 프레임 워크 패키지 그룹을 동일한 버전 번호로 배송하고 싶다는 생각이 들었지만 a) 기존 데스크톱 버전 관리를 따르지 않고 모든 것을 4.0으로 출시했을 때 이미 망쳤습니다. 어셈블리 버전 관리는 이미 모든 위치에 있습니다 (System.Security.Claims 4.3 패키지는 바인딩 리디렉션을 빌드해야 할 때 매우 짜증나는 4.0.2 dll을 제공합니다). 그래서 피해는 이미 이루어졌습니다.

dotnet / corefx # 3은 나에게 유일한 근본 원인 솔루션처럼 보입니다.

@robertmclaws 우리는 버전 변경이 차이를 만들 것이라고 생각하지 않습니다. 대부분의 사람들 (앱 및 라이브러리 소유자)은 일반적으로 패키지에서 "최신으로 업그레이드"하기 만하면됩니다. 버전이 얼마나 많이 변경되었는지 (마이너 대 메이저) 상관하지 않습니다. 따라서 브레이킹 임팩트는 정확히 동일합니다.
여러 가지를 결합 할 때만 "파괴"효과가 나타나는 것은 더 나쁩니다. 이것이이 문제가 처음에 빠져 나간 이유입니다. 우리는 그 콤보에 대한 테스트를하지 않았습니다 (그리고 괜찮다고 생각합니다. 모든 조합을 테스트 할 수는 없지만 나중에 사후에 논의 할 수 있습니다).

나는 누구도 전체 프레임 워크 그룹 버전에 대해 너무 신경 쓰지 않는다고 생각합니다. 솔직히 말해서 대부분의 고객에게 도움이 될 것이라고 믿으면 숫자를 변경하는 것에 투표 할 것입니다. 거의 도움이되지 않을 것입니다. 그것은 단지 우리의 메시지를 "예, 당신은 망가졌습니다-그것이 버전이 말하는 것입니다, 당신은 버전을 취할 때 당신이 어떤 종류의 것에 동의하는지 깨닫지 못했습니다."라는 메시지를 바꿀 것입니다. 이것은 IMO 절름발이입니다.

의견의 차이를 감안할 때 다른 사람들의 생각에 관심이 있습니다.이 게시물에서 upvotes / downvotes를 사용하십시오.

• 👍 만약 당신이 저의 의견에 동의한다면, 즉 5.0으로 변화를 가져 오는 것이 변화를 가져 오지 않을 것이라고 생각하고 대부분의 사람들은 여전히 ​​깨지고 혼란스럽고 영향을받을 것입니다.
• 👎 당신이 @robertmclaws의 제안에 동의하는 경우, 즉, 당신은 5.0 의지 도움말 사람들은 다른 라이브러리와 콤보를 중단하고 개발자들에게 불필요한 고통을 방지 할 수 있기 때문에 그들이 아니라, 패키지 멀리해야한다 선행을 이해로 주요 변경을 출하 생각합니다.

주요 변경 사항의 버전 관리를 위해 5.0이 좋은 생각이라고 생각하지만 그렇게 강력하게 생각하지 않습니다.

나는 여전히 처음 에이 문제의 원인에 대해 매우 혼란 스럽습니다.
장소. 너희들은 정말로 내 머리 위로 말하고있다.

버전 번호 일치에 대해 상당히 신경을 쓰지만
이 문제를 멈추기 위해 가서 처리하겠습니다.

나는 몇 달 전에 대부분의 방법에 대한 기사를 읽지 않았습니까?
System.Net.Http 라이브러리가 재건 된 라이브러리에 찬성하여 일몰 중 이었습니까?

2016 년 12 월 15 일 오후 3:18에 "Karel Zikmund" [email protected]이 작성했습니다.

@robertmclaws https://github.com/robertmclaws 우리는
버전 변경은 차이를 만들 것입니다. 대부분의 사람들 (앱 및 라이브러리
소유자) 일반적으로 패키지에서 "최신으로 업그레이드"만하면됩니다.
버전이 얼마나 변경되었는지 (부대 대 전공) 상관하지 마십시오. 그래서 속보
영향은 정확히 동일합니다.
"브레이킹"효과는 다음과 같은 경우에만 나타납니다.
여러 가지를 결합합니다. 이것이이 문제가
첫 번째 장소-우리는 그 콤보에 대한 테스트가 없습니다.
괜찮습니다. 모든 조합을 테스트 할 수는 없지만
사후 분석).

나는 누구도 전체 프레임 워크 그룹 버전에 대해 너무 신경 쓰지 않는다고 생각합니다.
어느 한 쪽. 솔직히, 대부분의 고객에게 도움이 될 것이라고 믿었다면
숫자 변경에 투표 할 것입니다.
거의 도움이됩니다. 우리의 메시지를 "예, 당신은
깨진-그 버전이 말하는 것입니다. 당신은 어떤 종류의
버전을 복용 할 때 동의하는 것 "은 IMO 절름발이 변명입니다.

의견의 차이를 감안할 때 다른 사람들의 생각에 관심이 있습니다.
이 게시물에 upvotes / downvotes를 사용하십시오 :

• 👍 나에게 동의한다면, 즉 브레이킹 체인지를 배송한다고 생각하는 경우
  5.0은 차이를 만들지 않고 대부분의 사람들은 여전히 ​​부서 질 것입니다.
  혼란스럽고 영향을 받았습니다.
• 👎 @robertmclaws https://github.com/robertmclaws에 동의하는 경우
  즉, 5.0으로 주요 변경 사항을 배송하는 것이 도움이 될 것이라고 생각합니다.
  사람들은 패키지에서 멀리 떨어져 있어야한다는 것을 미리 이해합니다.
  다른 라이브러리와의 콤보를 깨고
  개발자에게 불필요한 고통.

—
댓글을 달았 기 때문에 수신 한 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/dotnet/corefx/issues/11100#issuecomment-267446604 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AAavtBRE24SlHsZHCYm5OhPbOGs6MfRzks5rIa68gaJpZM4JsdDX
.

동의합니다. 오늘 초 이메일에서 몇 가지 세부 정보를 얻었지만 여전히 확실하지 않습니다. 내부 문제에 대한 좋은 설명을보고 제안 된 솔루션을 이해하는 것이 좋을 것입니다.

@karelz 여기서하려는 작업에 감사하지만 "버전 5.0"이 무엇을 의미하는지에 대한 설문 조사에 참여하는 것은 모두의 시간 낭비입니다. 엔지니어링이 아닌 사회화는 GitHub입니다. 이 문제를 해결하는 5.0 버전을 오늘 출시하고 모든 작은 주석을 올바르게 설정하고 코드를 리팩토링하는 방법을 알아낼 때 6.0을 출시 할 것입니다.

"대부분의 사용자 (앱 및 라이브러리 소유자)는 일반적으로 최신 버전으로 업그레이드하기 만하면됩니다."와 같은 문구는 유용하지 않습니다. 이것이 Perl 6, Python 3, Rails 3 & 4, Node.js 1,2,3,4,5 & 6이 일을 쪼개는 방법입니다. 그 리드를 따르지 말자.

@dluxfordhpf @ciel 불행히도 이것은 설명하기 어려운 영역입니다. 이 모든 것은 더 이상 사용을 권장하지 않는 "레거시"코드 액세스 보안에서 비롯됩니다.

다음은 그 목적이 무엇인지에 대한 요약입니다.
https://msdn.microsoft.com/en-us/library/ee191569 (v = vs.110) .aspx
https://msdn.microsoft.com/en-us/library/dd233102(v=vs.110).aspx

실제 문제는 @karelz 가 한 수준의 보안 투명성 유형 (데스크톱 프레임 워크에있는 방식으로)으로 덜 제한적인 보안 자세를 가진 유형에서 파생하려고 시도하는 것과 관련이 있습니다 (속성이 누락 되었기 때문). OOB 버전). 이것은 개념으로서의 CAS가 데스크탑 .net 이외의 다른 곳에 존재하지 않기 때문입니다.

위 문서의 컨텍스트에서 상속 규칙 에 대한이 섹션을 참조하십시오.

다양한 보안 수준에서 유형 상속에 필요한 규칙을 설명합니다.

감사! 저는 CAS에 익숙합니다. 기술은 훌륭합니다.

.NET Core, .NET Standard 등의 모든 버전 번호 변경 사항을 감안할 때 al. 작년에 (그리고 4.6.2에서 실행되는 NuGet에서 4.3 버전의 새 코드를 출시하면서 Microsoft가 버전 번호가 중요하지 않다고 생각할 수도 있음을 이해합니다.하지만 매우 복잡한 애플리케이션 아키텍처를 단독으로 관리하고 20 개 이상의 OSS NuGet을 제공하는 사람으로서 패키지, 나는 전적으로 동의하지 않습니다.

호환성을 확인하지 않고 "모두 업데이트"를 누르는 것은 .NET에서 앱을 망치고 런타임까지 알 수없는 가장 쉬운 방법입니다. SemVer를 고수하는 것이 온전함을 유지하는 유일한 방법입니다. 주 버전을 늘리면 무언가가 손상 될 것임을 알립니다. 당신이 변화를 신호 할 때, 당신은 당신이 그것을 해결하기 위해

제안 된 수정 사항은 나에게 좋게 들리지만 테스트 매트릭스에 대해 언급하고 싶습니다. 데스크톱 .NET에서 HttpClient를 사용하는 것은 가까운 미래에 중요한 일이 될 것입니다. 이 콤보는 모든 가능성을 테스트 할 수 있거나 테스트해야하는 것은 아니지만 사실이지만 실제로 테스트해야합니다.

네, 테스트는 나에게도 copout처럼 들립니다. 단위 테스트 프로젝트에 상위 100 개 패키지를 추가하고 쓰레기가 계속 실행되는지 확인하세요. 마이크로 소프트가 테스터를 해고하고 "커뮤니티"가 대신이 문제를 분류하도록 할 수 있다는 사실을 깨닫기 전에 Microsoft가 사용했던 기본적인 엔지니어링과 같은 것 같습니다. 정말 끔찍하고 짜증나는 시간 낭비입니다.

Windows ME와 Vista를 가져온 '오래된'QA가 우수했기 때문입니다.

또한 그들을 모욕하면 일이 더 빨리 끝날 것이라고 확신합니다.

2016 년 12 월 16 일 오전 7:46에 "chadwackerman" [email protected]이 작성했습니다.

네, 테스트는 나에게도 copout처럼 들립니다. 상위 100 개 추가
단위 테스트 프로젝트에 패키지를 추가하고 쓰레기가 계속 실행되는지 확인하십시오.
Microsoft가 이전에했던 기본 엔지니어링과 같은 것 같습니다.
테스터를 해고하고 "커뮤니티"가이를 분류하도록 할 수 있음을 깨닫고
대신 물건을 꺼내십시오. 정말 끔찍하고 짜증나는 시간 낭비입니다.

—
당신이 언급 되었기 때문에 이것을 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/dotnet/corefx/issues/11100#issuecomment-267597137 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AAavtAUL3pmMiSRnFBe7DEa0y5AaZoVXks5rIpZIgaJpZM4JsdDX
.

아무도 크리스마스 파티에 초대하지 않는 팀 리더를 찾았습니다.
사람들을 똥처럼 취급합니다.

2016 년 12 월 16 일 오전 8시 26 분에 "chadwackerman" [email protected]이 작성했습니다.

헛소리를 부르면 믿거 나 말거나 일이 더 빨리 완료됩니다.
그렇지 않으면 당신은 한 줄을 작성하지 않은 백만장 개발 관리자가 있습니다.
10 년 만에 "와우이 Github는 정말 깔끔합니다.
그림 이모티콘을 찬성 / 축소하고 설문 조사를 열어 결정하지 않아도됩니다. "
몇 달간 일하고 6 개월 만에
내부 심사 회의 시간. 그것은 잘못된 사회적 신호이며
솔직히 말해서 우리에게 품질을 가져다 준 BS 엔지니어가
새턴 V 로켓 처럼요 그리고 최고의 언어 패키징이었던 .NET
이 모든 것이 온라인에 있기 훨씬 전에이 공간에있는 모든 것의 표준 라이브러리
어리 석음이 시작되었습니다.

—
당신이 언급 되었기 때문에 이것을 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/dotnet/corefx/issues/11100#issuecomment-267604666 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AAavtEigDK5EqlA4LQVlxB_lfamMgHanks5rIp9-gaJpZM4JsdDX
.

또는 몇 달 동안 무시되었던 문제에 대해 Microsoft가 마침내 조치를 취하도록하여 전체 팀의 차단을 해제하는 방법을 배운 사람을 찾았을 수도 있습니다.

Microsoft는 내부적으로 완전히 중복 된 버그 목록과 우선 순위를 가지고 있습니다. Github는 사회적 말도 안되는 무리입니다. 그들은 어쨌든이 문제에 대한 풀 요청을받지 않으므로 고객 지원 스레드로 바뀝니다. 개발자들은 여기서 나쁜 일을했고 그들이 그것을 듣는 것은 괜찮습니다.

그것을 듣고있는 개발자들 사이에는 뚜렷한 차이가 있습니다.
참을 수없는 새끼. 모욕적 인 발언이 유일한 방법이라면
당신은 적어도 당신의 사람들을 꾸짖는 것에 집착해야합니다.
당신을 참기 위해 지불합니다.

2016 년 12 월 16 일 오전 8:34에 "chadwackerman" [email protected]이 작성했습니다.

아니면 전체 팀의 차단을 해제하는 방법을 배운 사람을 찾았을 수도 있습니다.
몇 달 동안 무시되었던 문제에 대해 Microsoft가 마침내 조치를 취하도록했습니다.

Microsoft는 내부적으로 완전히 중복 된 버그 목록과 우선 순위를 가지고 있습니다.
Github는 사회적 말도 안되는 무리입니다. 그들은 풀 리퀘스트를받지 않을 것입니다.
어쨌든이 문제는 고객 지원 스레드로 바뀝니다. 개발자
여기서 나쁜 일을했고 그들이 그것을 듣는 것은 괜찮습니다.

—
당신이 언급 되었기 때문에 이것을 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/dotnet/corefx/issues/11100#issuecomment-267606461 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AAavtHTdxym7pvR9KRomyIT14FVaILLFks5rIqF8gaJpZM4JsdDX
.

나는 마이크로 소프트가 "GitHub number_of_comments로 정렬"을 사용하여 @karelz 가 "자금 파악"이라고 정중하게 유출 한 것을 지원하기 때문에 응답 할 것입니다. GitHub 이모 지 척도를 사용하여 사회적 가치도 검증 할 수 있습니다.

친구가 들어 와서 SemVer는 중요하지 않다고 말했습니다. 그것이 얼마나 어리석은지를 지적하는 것은 엔지니어로서 우리의 의무입니다. 실제 경험이있는 선임 관리자 나 실제 세상에 어떤 영향을 미치는지 실제로 아는 더 후배가 필요한 전형적인 경우입니다. GitHub에서 시장 역할을하는 중간 관리자가 여기서 진짜 문제입니다. 이제 우리 모두가 하루를 보낼 수 있도록 아래로 엄지 손가락을 자유롭게 클릭하십시오. 감사합니다.

예,이 버그는별로 였고, sev1의 주요 경로가 공개 된 것을보고 놀랐습니다. 그러나 IMHO의 진정한 고통은 NuGet의 디자인 때문입니다. 프로젝트에서 사용하는 모든 NuGet 패키지는 해당 프로젝트의 모든 소비자가 수동으로 참조해야합니다. 그것은 불필요한 중복과 잘못된 설계이며, 실패에 대비합니다. 동기화 마법사는 기본 디자인이 나쁠 때 쓸모가 없습니다. NUGET은이 버그가 그토록 고통스러운 이유입니다. 그렇지 않으면 우리는 연기가 나고 Util에 불쾌한 해결 방법을 넣고 잊어 버릴 수 있습니다. 그러나 이제 우리는 매달 성장하는 18 개 정도의 소비 프로젝트 모두에서주의해야합니다. 그렇기 때문에이 버그가 매우 고통 스럽습니다. NuGet으로 인해 수정 사항을 하나의 프로젝트로 격리 할 수 ​​없으며 모든 것을 만지고 계속 수행해야합니다.

또한 데스크탑 / 윈도우 .NET이 중요하다는 감정을 반영합니다. Microsoft .NET이 Linux에 출시된다는 소식을 듣게되어 기쁩니다.하지만 돈은 Windows에 있습니다. 여기에서 우리가 최고의 경험을하게 될 것입니다.

우리 팀의 지속적인 불만은 "왜이 모든 패키지를 다운로드

좋아, 나는 조금 더 멀리 가고있다. 시간과 관심을 가져 주셔서 감사합니다. 문서에서 오타를 테스트 / 평가 / 확인하는 데 도움이되는지 알려주세요. 필요한 모든 것을 기꺼이 도와 드리겠습니다.

이 문제 (및 dotnet / runtime # 17786)가 우리에게 많은 고통을주는 이유는 클라우드 서비스를 Azure 웹 역할에서 Service Fabric 서비스로 이동하고 netcore / netstandard로 이동해야했지만 여전히 전체 프레임 워크에서 실행 중이었기 때문입니다. 앱.

처음에는 한동안 작동하는 것처럼 보이는 바인딩 리디렉션 해결 방법을 수행했지만 우리 개발자는 실수로 app.config를 되돌리고 너겟 패키지를 업데이트하고 AutoGenerateBindingRedirects와 싸우면서 지속적으로 무언가를 깨뜨리고있었습니다 (비활성화는 악몽이었습니다).

마지막으로 모든 곳에서 HttpClientHandler를 사용하도록 강요하여이 문제를 해결했습니다. 여기에는 자체 코드 변경, 타사 라이브러리에서 문제 제기, 리플렉션과 같은 해킹 및 타사 코드 복제를 사용하여 문제를 해결하는 것이 포함되었습니다.

따라서 솔루션이 무엇이든 새 패키지가 최신 HttpClient / HttpClientHandler를 지원하지 않으면 가져 오지 않습니다. 지금은 일이 잘되고 있기 때문에 큰 문제는 아닙니다. 그러나 코드를 netstandard로 옮기고이 문제를 야기 할 수있는 더 많은 타사 패키지를 업데이트하는 것을 막고 싶지 않기 때문에 "실제 수정"이 곧 나올 필요가 있습니다.

@dluxfordhpf ... 제안 된 솔루션을 이해하도록 내부 문제에 대한 좋은 설명을 보면 좋을 것입니다 ...

https://github.com/dotnet/corefx/issues/11100#issuecomment -267394198에서 문제를 설명하려고했습니다.
간단히 말해서 :

• Http NuGet 패키지 4.1 / 4.3은 .NET Framework에서 Http 4.0을 "재정의"하지만 보안 특성은 없습니다. 또한 후드 아래에서 다른 OS 구성 요소를 사용합니다 (예 : "큰 변화"+ 잠재적 인 코너 케이스 (이 문제와 직접적으로 관련되지는 않지만 문제가 있다는 신호)).
• WebRequestHandler는 .NET Framework의 일부일 뿐이지 만 Http 4.0에 의존하며 Http의 보안 특성이 필요합니다.
• NuGet에서 Http 4.1 / 4.3에 의존하고받은 편지함 4.0 .NET Framework 버전을 여기로 리디렉션하면 WebRequestHandler를 사용할 수 없습니다.
• 설상가상으로 Http에는 .NET Standard 1.6의 일부인 몇 가지 새로운 API가 있으며 일부 구성 요소는 이에 의존합니다. 따라서 단순히 이전 버전으로 롤백 할 수는 없습니다.
• 그리고 물론 세부 사항은 그것을 더욱 복잡하게 만듭니다.
• 명백한 말 : "올바른 해결책"은 없습니다. 전반적으로 영향이 적은 것을 선택하는 것이 중요합니다.

@chadwackerman ... "버전 5.0"이 무엇을 의미하는지 설문 조사에 참여하는 것은 모든 사람의 시간 낭비입니다. 엔지니어링이 아닌 사회화는 GitHub입니다.

그것은 사회화되지 않습니다. 투표를 보면 문제에 대한 만장일치의 의견이 없음을 알 수 있습니다. 따라서 CoreFX 팀 (.NET 고객과 10 년 이상의 경험을 가진)이 " 우리가 원하는대로 메이저 버전에 관심을 기울이지 않는다 "는 의견을

@chadwackerman ... 오늘이 문제를 해결하고 6.0 ..을 제공하는 5.0 버전을 제공하겠습니다.

위에 배치 한 옵션 [2]입니다 (버전 번호가 다름). 그것은 우리가 동시에 탐구하고있는 것입니다. 솔루션의 영향을 감안할 때 " 예-그게 당연히 옳은 일 입니다.

@robertmclaws ... Microsoft는 버전 번호가 중요하다고 생각하지 않을 수 있습니다. 변경 사항을 원하는 대로 수정할 수 있습니다.

우리가 올바른 버전 관리를 믿지 않는다고 말하지 않았습니다. 우리는 개발자의 상당 부분이 신경 쓰지 않고 모든 것이 항상 완벽하게 호환되기를 원한다고 믿습니다. 즉, 메이저 버전의 범프에서도 원하는 것을 할 수 없습니다. 이는 .NET 서비스 및 NuGet 패키지 배송에 대한 우리 팀의 수년간의 경험을 기반으로합니다.

@gulbanana ...이 콤보는 실제로 모든 가능성을 테스트 할 수 / 테스트해야하는 것은 아니지만 사실이지만 테스트를 받아야합니다 ...

동의합니다. 이제 중요한 콤보라는 것을 알았으므로 커버리지를 추가해야합니다. 그리고 Http NuGett 패키지와 관련된 다른 유사한 콤보가 없는지 확인하기 위해 영역을 좀 더 살펴 봐야합니다.

@chadwackerman ... 단위 테스트 프로젝트에 상위 100 개 패키지 추가 ...

재밌게도 1 년 전에 올바른 테스트 범위가 부족하여 UWP 용 잘못된 메타 패키지를 출시했을 때 제안한 것과 비슷합니다. 그렇게 쉽지는 않습니다. 흥미로운 버그 (이와 같은)를 잡으려면 코드도 연습해야합니다. 종종 동일한 테스트에서 두 콤보에서 코드를 연습해야합니다 (이 특정 경우는 아님). 테스트 인프라에서 전반적으로 꽤 어렵습니다.
우리가 놓쳤을 수있는 제안과 아이디어가 있으면 알려주십시오. 해당 주제에 대한 새로운 문제를 시작하겠습니다.

@chadwackerman ... 그리고 "커뮤니티"가이 물건을 대신 분류하도록하세요 ...

우리 (CoreFX 및 CLR 팀에 대해 말할 수 있습니다)는 GitHub를 통해 커뮤니티에 제품 테스트를 아웃소싱하지 않습니다. 우리는 우리가 배송하는 제품의 품질에 대해 높은 기준을 가지고 있습니다.

(우연한 핫키가 끝내기 전에 답장을 보냈습니다 ... 계속하려면 ...)

@chadwackerman ... Microsoft는 내부적으로 완전히 중복 된 버그 목록과 우선 순위를 가지고 있습니다.

CoreFX 및 CoreCLR 팀에서는 사실이 아닙니다. GitHub는 모든 .NET Core의 기본 버그 데이터베이스입니다. 다른 비 오픈 소스 제품 ( "전체".NET Framework 및 .NET Native)은 주로 내부 버그 데이터베이스를 사용합니다.

@chadwackerman ... 어쨌든이 문제에 대한 풀 요청을받지 않을 것입니다 ...

위의 모든 우려 사항을 처리 / 설명 할 수없는 풀 리퀘스트 (제출자가 개인적으로 동의하지 않는 경우 포함)는받지 않습니다. 모든 영향을 생각하지 않고 빠른 해킹을 할 수있는 오픈 소스 프로젝트가 있습니까? 고객의 20 % 이상이 바닥에 있다면 ... (아직) 그렇지 않습니다.

@chadwackerman ... 마이크로 소프트는 @karelz 너무 정중로 유출 된 것을 지원하기 위해 "일종의 GitHub의에 NUMBER_OF_COMMENTS에서"사용 "자금 알아." ...

첫째, number_of_comments는 우리가주의를 기울이는 측정 항목이 아닙니다 (누군가가 "수동으로"지붕에서 벗어난 것을 알아 차리지 않는 한). 그리고 그것은 "펀딩"과는 아무런 관련이 없습니다.
우리는 고객에게 영향을 미치는 모든 것에주의를 기울입니다. 투표 수 또는 고객 불만족 (GitHub, Twitter, 블로그 게시물 댓글 등)이 있습니다.
이 버그는 내 레이더에 "중요한 고객 불만족"(이 스레드의 다른 MS 직원이 내부적으로 문제를 제기 함)으로 떠 올랐기 때문에 내가 개입했습니다.
우리는 현재 가능한 한 많은 자금을 지원하고 있습니다. 유일하게 더 높은 우선 순위는 보안 문제이거나 고객의 20 % 이상이 해결 방법없이 현장에 있습니다.
BTW : 모욕을 던지는 것은 속도를 높이거나 의사 결정에 영향을 미치지 않습니다.

@dluxfordhpf ... 오타에 대한 문서를 테스트 / 평가 / 확인하는 데 도움이 될 수 있는지 알려주세요 / 필요한 것이 무엇이든 기꺼이 도와 드리겠습니다 ...

감사합니다. 제안 해 주셔서 감사합니다. 우리는 더 많은 종단 간 시나리오를 검증하기 위해 준비된 (그리고 우리가 가지고있는 재현에 대해 검증 된) 도움을받을 수있을 것입니다. 일부 엔드-투-엔드 시나리오 만 수정하고 다른 시나리오는 동일하거나 다른 방식으로 고장난 상황을 피하고 싶을 것입니다.

@jahmai ...하지만 우리 개발자들은 실수로 app.config를 되돌리고, nuget 패키지를 업데이트하고, AutoGenerateBindingRedirects와 싸우면서 끊임없이 무언가를 깨뜨리고있었습니다 (비활성화는 악몽이었습니다). ...

감사! 이는 우리가 듣고 이해해야하는 일상적인 개발 작업에 대한 문제의 영향을 명확히하는 좋은 예입니다. VS 툴링과의 콤보로 인해 작업하기에 진정한 악몽이된다는 것을 이해하는 데 도움이됩니다. 릴리스 계획 및 날짜 (해결 방법을 결정하는대로 시작하겠습니다)를 확정 할 때이를 고려할 것입니다.

@jahmai ... 새 패키지가 최신 HttpClient / HttpClientHandler를 지원하지 않으면 가져 가지 않습니다 ...

다시 말씀 드리지만 좋은 피드백입니다. 우리는 하나의 솔루션으로 완전히 구매하기 전에 전체 엔드 투 엔드 수정 및 릴리스 스토리를 플러시하려고 여전히 노력하고 있습니다. 다른 시나리오 (예 : 귀하의 시나리오)에 미치는 영향을 이해하지 않고 해킹을 해제하는 것은 우리에게 절실한 조치가 될 것입니다. 해결 방법을 모르거나 적절한 수정 비용이 매우 많이 드는 경우에만이를 고려할 것입니다. 우리는 아직 거기에 있지 않습니다.

지금부터는 기술적 인 논의를합시다.

빠른 업데이트:
솔루션 [3] 위에 설명 된 " System.Net.Http의 Sprinkle Security 속성 "은 비용이 많이 드는 것으로 보이므로 (6w +) 내부 구현 세부 정보를 다시 조정했습니다. 패키지 4.0 버전에서 원래 Http 구현을 사용하는 것을 고려하고 있습니다. + 가능한 한 최선을 다해 8 개의 새로운 API를 구현합니다 (일부는 기술적으로 해결 방법으로 중단 될 수 있음). http2 지원 및 기타 "새로운 WinHttp 스택"기능은 기본적으로 사용할 수 없습니다. 원하는 사람은 누구나 특수 생성자를 호출해야합니다 (기술적으로 중요한 변경 사항이지만 새로운 4.1 / 4.3 기본 기능에 의존하는 사람은 많지 않을 것입니다). .
비용은 지금까지 상당히 낮은 것으로 보이지만 최종 계획을 결정하기 전에 여전히 추적하고 2 개의 손실 끝 (API) 비용을 지불하고 있습니다. 우리는 적어도 2 개의 API에 대해 몇 가지 "흥미로운"호환성 결정을 내려야하지만, 수정이 릴리스되는 시간을 늦추지 않아야합니다.

BTW : 솔루션 [2] " OOB 실행 취소 결정 "은 원래 예상했던 것보다 더 많은 영향을 미치는 것으로 나타났습니다 (예 : .NET Standard 1.6을 깨고 장기적인 혼란과 설명을 생성 함). 위의 비용이 너무 비싸거나 불합리한 것으로 판명되는 경우 현재로서는 최후의 수단으로 유지하고 있습니다.

현재이 문제와 관련된 엣지 케이스를 살펴보고 있다면 다음 사항을 확인해 볼 가치가 있습니다.
https://github.com/gulbanana/repro-netstandard-httpclient

이 솔루션은 현재 vs2017rc에서 netfx 및 netstandard를 사용하면 system.net.http의 충돌 버전이 발생 함을 보여줍니다. 나는 그것이 OOB 일과 어떻게 관련되어 있는지 잘 모르겠습니다.

@karelz 솔직히 여기에 감사하고 솔직히 존경하지만 마지막으로 버전 관리 경적을 울릴 것입니다.

CoreFX 팀 (.NET 고객에 대한 10 년 이상의 경험을 보유한)을 신뢰하지 않는 경우 "사람들이 주 버전에 관심을 기울이지 않는다"라는 의견을 ... NET 서비스 및 NuGet 배송에 대한 우리 팀의 수년간의 경험을 기반으로합니다. 패키지 ...

이것이 어떤 논리적 오류인지는 확실하지 않지만 이와 같은 대규모 버전 관리 문제의 한가운데서 버전 관리에 대해 깊이있는 미묘한 경험이있는 팀 이해를 주장 할 수는 없습니다.

바라건대 우리는 적어도 메이저 버전 번호를 높이 지 않고 브레이킹 체인지를 갖는 것이 모든 세상에서 최악이라는 데 동의 할 수 있습니다. 하지만 여기 있습니다. "예산"과 "개발 시간 6 주 이상"에 대해 이야기하면서 ... 실제로 작동하지 않았고 사용하지 않는 구식 신뢰 시스템을 위해. 컴파일러의 무시 된 문제 때문입니다.

Amazon Web Services는 지난 여름 모든 서비스에 대해 완전한 .NET Core 지원을 제공했습니다. 그들의 최근 업데이트는 기준을 netstandard 1.5에서 1.3으로 낮 춥니 다. 한편 Azure 팀은 Blob을 작동시킬 수도 없습니다.

여러분은 https 웹 요청을 전 세계적으로 차단하는 비트를 빌드 중에 조용히, 런타임에 큰 소리로 전달했지만 4 개월 후에도 해결할 계획이 아직 없습니다. 분명히 당신이 작업하고 있기 때문에 지금은 이것을 떨어 뜨릴 것입니다.하지만 여기에 더 큰 문제가 밤에 당신을 방해하지 않는다면 ...

솔직하고 설명 해주셔서 감사합니다.

@chadwackerman ... 이와 같은 대규모 버전 관리 문제의 중간에 버전 관리에 대해 깊이있는 미묘한 경험이있는 팀 이해를 주장 할 수 없습니다. ... 적어도 주 버전 번호를 높이 지 않고 주요 변경 사항을 적용하지 않는 것이 모든 세상에서 최악이라는 점에 적어도 동의 할 수 있기를 바랍니다. 하지만 여기 있습니다. ...

두 가지 큰 가정을하고 있습니다.

1. 가정 : 배송 전에 주요 변경 사항이 알려져 있습니다 (일명 중단으로 이해 됨).
   
   
   
   • 이것은 "의도하지 않은 주요 변경 사항"클래스의 경우와 같이이 문제의 경우가 아닙니다. 네, 가끔은 실수가 있습니다 :(. 중요한 측정 기준은 IMO : 빠른 반응 (지금까지이 문제에 대해 우리가이 문제에 대해 제대로하지 않았다는 데 동의합니다) 및 그러한 실수의 감소 / 낮은 빈도입니다.
   
   
2. 가정 : 버전 관리 전문가는 모든 변경 사항을 검토 할 수 있으며 (그렇지 않음) 일반적으로 사람들은 실수를하지 않습니다 (공상 과학).
   
   
   
   • 이 특정 사례에서 System.Net.Http API 계획 (데스크톱 용 새로운 8 개 API)은 버전 관리 전문가에 의해 출시되기 전에 상위 수준에서 검토되었습니다. 그들은 옵션에 대한 제안과 지침을 제공했습니다. 안타깝게도 파괴 수준은 누구도 (지역 전문가도 버전 관리 전문가도 아님) 미리 인식하지 못했기 때문에 선택한 솔루션이 이러한 문제로 이어집니다.
   
   

또한 버전 관리에 대한 우리의 경험을 무시함으로써 기본적으로 " (.NET 팀)이 큰 실수 (이 버그)를 저지르면 과거 이력과 고객에 대해서도 자신을 전문가라고 부를 수 없다는 점을 지적하고 싶습니다.
그것은 IMO의 큰 망치이며 현실적이지 않습니다. 사람 / 팀은 가끔 실수를합니다 (이것처럼). 그렇다고 주변 지역 (또는 특정 지역)의 전문가가 되기에는 적합하지 않습니다. 핵심은 그들이 실수로부터 배우고 미래에 더 잘할 수 있는지입니다.

@chadwackerman ... "예산"과 "개발 시간 6 주 이상"에 대해 이야기

비용은 "slapping attributes"가 아니라 쉬운 부분입니다. 비용이 많이 드는 부분은 옵션 [3]에 대한 미해결 질문입니다.

https://github.com/dotnet/corefx/issues/11100#issuecomment -267394198 : 열린 질문 : WebRequestHandler의 내부 종속성을 새로운 WinHttp 기반 System.Net.Http에서 작동하도록 만들 수 있습니까?

꽤 많은 작업이고 내부 종속성이 너무 심합니다.

나는 이것에 대한 모든 토론에 정말로 감사합니다. 진지하게. 그것은 굉장. 이것에 대해 열어 주셔서 감사합니다.

하지만 결국에는 dotnet / corefx # 1 문제가 있습니다. 여러분은 스택의 주요 부분을 다시 작성했습니다. 거의 모든 것의 중심이되는 부분. 그리고 원격으로도 적절한 테스트 커버리지가 없습니다. 전문가가 필요 하지 않아야합니다. WebRequestHandler가 작성되었을 때 (또는 Core로 이식하지 않기로 결정한) 명확하게 문서화 된 테스트 케이스가 있어야하며, 여러분이 몽키 작업을 시작했을 때 깨졌어 야합니다.

.NET 4.0 관련 제품을 5 년 넘게 출시 한 후,이 문제를 포착했을 통합 테스트 적용 범위를 갖지 못한 것에 대한 변명의 여지가 없습니다. 변명을한다면 팀에게 탁월함을 요구하는 것은 아닙니다.

있었다면 :

• 적절한 테스트 범위
• 적절한 QA 프로세스
• 적절한 베타 릴리스
• 특정 패키지를 담당하는 특정 팀에 문제를 제출하는 적절한 방법

... 이것은 일어나지 않았을 것입니다.

팀이 :

• .NET의 모든 단일 측면을 동시에 다시 작성하여 바다를 끓이는 데 너무 열중하지 않았습니다.
• ".NET 5 / MVC 6"프로젝트가 시작된 이후이 문제에 대해 목소리를 높여 온 우리의 경고에 유의하십시오.

... 이것은 일어나지 않았을 것입니다.

.NET을 크게 망가 뜨린 실패의 조합입니다. 전에는 기억하지 못했던 규모입니다. 하지만 생태계의 많은 부분을 무너 뜨 렸고 고치기가 점점 더 어려워지고 있습니다.

여기에는 _ 매우 실제 _와 _ 상당한 _ 비용이 있습니다. 몇 주 전에 CI 서버를 종료하고 수동으로 배포하여 매번 수동으로 web.config를 확인해야했습니다. 하루에 한 번 이상 배포합니다. 다른 일을하는 데 그 시간을 소비해야하는 지연은 말할 것도없고 추가 작업 시간에 주당 수백 달러가 소요됩니다.

다시 말하지만, 이것은 HttpClient 아키텍처의 기존 결함을 처리하는 수많은 시간을 고려하지도 않았습니다. 즉, 인스턴스를 적절하게 처리하지 못하고 TCP 연결을 열어두고 DNS 항목을 너무 오래 캐싱하지 않습니다.

그래서, 당신은 이것에 대해 약간의 결함을 잡을 것입니다. 그리고 당연히 그렇습니다.

그리고 수정이 얼마나 "비싸다"는 것을 고려할 때, 나는 당신이 그것을 올바르게 고치기 위해 몇몇 최고의 사람들로 구성된 타이거 팀을 배치하고 한 사람의 어깨에 두지 않기를 바랍니다.

... 구타는 사기가 좋아질 때까지 계속됩니다.

그들이 인정한 실수를 고치도록하고 재치에 묶여 있지 않도록하십시오.

분명하게 말하면, 저는 마지막 게시물로 죽은 말을이기려고하는 것이 아닙니다. 그러나 나는 최근에 마이크로 소프트로부터 너무 많은 변명을 보았다. "이름 지정은 어렵습니다." "버전 관리는 어렵습니다." "사람들은 실수를합니다." 이것은 탁월함을 위해 노력하는 팀이 아니라 약점에 대한 사고 방식입니다. 여기 나와서 토론 한 @karelz 를 정말 존경합니다. 그러나 모든 MSFT 직원은 무슨 일이 일어 났는지 정당화하는 것을 그만두고 사람들이 기록을 수정하는 데 시간을 할애 할 필요가 없다고 느끼도록해야합니다. 이것은 DateTime 또는 기타를 사용할 때 매우 중요한 예외가 아닙니다. 한 명 이상의 사람이 자신의 업무에서 탁월함을 요구하지 않기 때문에 엄청난 효과가 발생하므로 그렇게 취급해야합니다. 유일하게 유효한 응답은 다음과 같습니다. "실패했습니다. 우리는 .NET을 깨뜨 렸습니다. 문제가 해결 될 때까지 쉬지 않을 것입니다." 5 년 전 구가 공연을했을 때 그랬을 텐데.

.NET에서 오랜 시간 일한 끝에 최근에야 그의 직책을 맡은 @karelz 에게 공감합니다. 그리고 그는 확실히 그의 팀을 방어 할 필요가 없습니다. 나는 여기 노동자들을 탓하지 않는다. 분명히 관리 문제입니다.

그러나 Microsoft 관리의 특정 계층에서 널리 퍼져있는 순환 논리와 일종의 이중 대화가 실제로 해당 항목을 사용하는 실제 고객 앞에서 제대로 작동하지 않는 것을 보는 것은 충격적이지 않아야합니다.

.NET Core에서 Microsoft SQL Server는 서명되지 않은 값을 쓰는 기능을 잃었습니다. 다시 2014 년으로 거슬러 올라가는 UserVoice 사이트의 맨 위에있는 무시 된 문제입니다. 기업은 데이터베이스 스키마 (특히 서명되지 않은 것과 같은 조정)를 변경하는 사치가 없습니다. 두 프로그램 관리자가 세 번 후에 같은 페이지를 볼 수 없기 때문입니다. 연령. 한편 Redis와 SQLite (그게 뭐든간에)는 잘 작동하고 Scott Hanselman은 마치이 물건이 실제로 작동하는 것처럼 트레이드 쇼 데모를 진행합니다. 여기에는 내부 현실과 외부 현실 사이의 격차가 확실히 벌어지고 있으며 문제는 (정중하게) 환기되어야합니다.

명명은 어렵습니다. 버전 관리는 어렵습니다. 마이크로 소프트는 최첨단에서 죽어가는 포도 나무에 이르기까지 모든 종류의 산업에서 고객을 다루는 독특한 관점을 가지고 있습니다. 게임에서 "명백한"것처럼 보이는 개발 접근 방식의 개념은 CRM 시스템에서 이질적입니다. 문제에 접근하는 방법, 중요하고 중요하지 않은 것은 다양합니다. 그런 다음 진보 된 기술, 문제에 대한 다양한 접근 방식을 추가합니다. DAO 대 ADO.NET 대 LINQ 대 EF는 일반적인 쉬운 비교를 사용합니다. 마지막으로, 인터넷 서버 영역에서의 경쟁, 턴키 태블릿을 사용한 완전히 새로운 하드웨어 모델 및 Balmer 바이러스. 다른 한계와 장점을 가진 완전히 새로운 사고 방식과 모델링 문제.

한때 나는 유명한 대기업에서 일했습니다. 한 제품 그룹은 초기화 방법에 따라 호출 스택을 다르게 해석하는 업데이트 된 공유 구성 요소가있는 제품을 출시했습니다. 그들은 우리 제품으로 테스트하지 않았고 우리 제품이 매번 붐을 일으켰습니다. 분명하지만 어쨌든 배송했습니다. 우리는 이것을“친절한 화재”사건이라고 불렀습니다.

D 드라이브에 설치하면 특정 조건에서 제거시 제품이 HD의 모든 파일을 삭제할 수있는 버그를 한 번 놓쳤습니다. 우리는 $ 40k의 프레스 CD를 구워야했습니다.

사람은 완벽하지 않고 우리는 실수를합니다. 그러나 비난은 쓸모없는 개념입니다. 수치심과 굴욕과 같은 파괴적인 개념을 통해 우리를 강력하게 만듭니다. 겸손과 용서는 더 강력합니다. 그것이 우리가 더 잘하고, 더 나은 방법을 배우고, 때로는 단순히 무언가가 중요한 이유입니다.

예, 문제는 저도 화나게하지만 해결되고 있습니다. 그리고 당신은 무엇을 알고 있습니다-어쨌든 시도조차 괴롭히기 전에 수십 년 동안 이와 같은 오픈 소스 문제는 시들었습니다. Linux 시스템에 Kerberos를 시도하거나 GSSAPI를 살펴보십시오. InitializeSecurityContext / AcceptSecurityContext는 훨씬 쉽습니다. 돈 문제.

한때 나는 유명한 대기업에서 일했습니다. 한 제품 그룹은 초기화 방법에 따라 호출 스택을 다르게 해석하는 업데이트 된 공유 구성 요소가있는 제품을 출시했습니다. 그들은 우리 제품으로 테스트하지 않았고 우리 제품이 매번 붐을 일으켰습니다. 분명하지만 어쨌든 배송했습니다. 우리는 이것을“친절한 화재”사건이라고 불렀습니다.

그것들은 두 가지 다른 제품이었습니다. .NET은 단일 제품입니다. 그리고 나는 한 사람을 비난하려는 것이 아닙니다. 나는 그 과정을 비난한다. 마이크로 소프트가 OSS로 갔기 때문에 역사상 가장 안정적인 개발 프레임 워크를 창 밖으로 내놓는 데 도움이되는 프로세스를 포기한 것 같습니다. NuGet 대신 .NET 4.6.3으로 배송 되었다면 이것이 잡혔을 것 같습니다.

OSS 로의 서투른 전환은 확실히 문제에 도움이되지 않습니다. 나는 OSS를 비난하지 않지만 마이크로 소프트는 명백한 실수를 모두 저지른 것을 자랑스럽게 생각한다.

소프트웨어를 설명하기 위해 "품질"과 같은 단어를 사용하지만 지금은 "참여"와 같은 단어를 사용합니다. .config 파일을 수동으로 편집해야하기 때문에 하루에 추가로 20 번 집으로 전화하는 인스트루먼트 컴파일러를 실행하는 것은 "추가 작업"이 아닙니다. 그러나 이것은 오늘날 전체 인터넷의 신화입니다.

Linux 경험이없는 많은 사람들이 GitHub에서 Linux 사용자 모드 shim을 라이브로 작성하도록 결정한 BashOnWindows 팀을 고려하십시오. 이 작업은 기본적이지만 지루한 체크 박스 엔지니어링 실습이며 기능 우선 순위에 대한 커뮤니티 피드백을 포함 할 이유가 전혀 없습니다. 그러나 그들은 갔다.

6 개월이 지난 후 "커뮤니티"는 일정 기간 내에 끝나는 파일을 처리 할 수 ​​없다고 말해야했습니다. 이것은 소프트웨어 엔지니어링이 아닙니다. 그것은 일종의 이상한 마케팅 활동입니다. 계획에 내재 된 관리자는 피드백을받을 자격이 있습니다. 그리고 그 중 일부는 듣기에 불쾌 할 수 있습니다.

추가 편집 : Bash debacle과 유사한 거래. 깨진 비트를 실시간으로 전달하고, 다른 구성 요소 (Windows 업데이트의 일부로 만 설치할 수 있음)와의 이상한 연결, 그리고 물론 Scott Hanselman은 컴파일러는 물론 tar를 실행할 수 없다는 사실에도 불구하고 라이브 데모를 수행합니다.

여기에있는 수사 중 일부는 Microsoft의 "좋은 옛날"을 연상 시키는데, 이는 우리가 지금 목격하고있는 모든 변화가 Microsoft의 진화에 대한 고객 요구에 대한 직접적인 대응이기 때문입니다.

우리는 폐쇄 된 소스와 엄격한 리버스 엔지니어링 (디 컴파일) 규칙에 지 쳤기 때문에 참조 소스와 이제는 오픈 소스를 얻었습니다.

우리는 컴퓨터에 설치된 모든 응용 프로그램에 영향을 미치는 .net Framework 버그에 지 쳤고 수정하는 데 오랜 시간이 걸렸고 기업 배포 및 IT 부서가 모든 .net Framework 버전 업데이트가 발생하기 전에 자격을 갖추도록 요구했습니다. 사용 가능한 즉시 수정 사항을 푸시 할 수 있도록 앱과 함께 nuget 패키지를 제공합니다.

우리는 Microsoft Connect가 다른 모든 버그를 "설계된대로 작동하는"것으로 종료하거나 릴리스 일정을 잡는 데 6 개월이 걸리는 것에 지쳤습니다. 이제 실제로 코드를 작성하는 팀이 Github 프로젝트를 훨씬 더 긴밀하게 관리하고 커뮤니티는 모든 커뮤니티 제기 작업 항목에 대해 2c를 쉽게 줄 수 있습니다.

우리는 Microsoft가 커뮤니티의 모든 좋은 아이디어를 취하고 Microsoft가 아닌 도구와 잘 작동하지 않는 독점 복제를 만드는 데 지쳤으므로 이제 NPM, Gulp, NodeJS 등을 사용하게되었습니다.

우리는 C #이 Windows에서만 실행 가능하고 Mono와 같은 프로젝트는 모든 곳에서 #ifdef를 사용하여 버그 또는 기능 부족을 해결해야하면서 동등성을 유지하기 위해 고군분투하고 있었기 때문에 이제 Xamarin이 참조 소스를 사용하여 Mono 개발을 추진하고 최신 C # 언어를 코딩하고 .net, UWP, iOS, Android 및 netcore에서 동일한 코드 기반을 공유합니다.

이 모든 것이 한꺼번에 일어나고 있습니다. 주어진 시간에 문제의 절반 만 해결하는 완벽하고 안정적인 기능을 제공하는 동안 Microsoft가 따라 잡기를 기다리지 않을 것입니다.

제 문제는이 모든 변화가 한 번에 일어나고 있다는 것이 아닙니다. 이와 같은 문제가 등장하는 것도 아닙니다. 저에게 진짜 문제는 _ 이 문제가 주요 문제로 인식되기까지 몇 달이 걸렸고 _ 더 많은 시간이 걸린다는 것입니다 _.

3 주 동안 업데이트가 없습니다. 여러분 새해 복 많이 받으세요.

@karelz의 인용문을 추가하려면 여기에

적어도 매주 업데이트가있을 때 업데이트를 게시 할 것입니다.

@chadwackerman 진지하게, 당신의 나쁜 태도 가이 문제를 더 빨리 해결하는 데 도움이되지 않는다는 것을 이해합니까? 그리고 그것과는 별개로, 당신은 여기서 당신 자신을 바보로 만들고 있습니다. 어조를 향상 시키십시오.

무슨 톤? 그는 정확하다는 이점이있는 성명서를 작성하고 모두에게 새해 복 많이 받으세요. 부정적으로 생각했다면 그게 문제입니다.

그리고 그 첫 번째 진술과 관련하여 : 이것은 런타임까지 나타나지 않는 주요 주요 문제입니다. 5 년 전 ScottGu 또는 Rob Howard는 수정 사항이 배송 될 때까지 24 시간 내내 팀을 구성했을 것입니다. 이제 그것은 단지 "알다시피, 우리는 그것에 대해 알아볼 것입니다."

사람들을 행복하게 만드는 것이 무엇인지 알고 있습니까? 문제를 해결. 그렇지 않으면 열받은 고객이 있고 그들 중 일부는이 스레드에 있습니다. 그들은 화를 낼 모든 권리 가 있습니다. 그러니 @pollax라는 분개와 관련이있는 다른 것을 찾으십시오. 당신은이 스레드에 의미있는 어떤 것도 기여하지 않았고, 아무도 당신에게 GitHub 사고 경찰을 기름 부음하지 않았습니다. 또한이 문제에 회사의 $ 5K 이상을 낭비하지 않았습니다.

좋아, 아마도 나는 그것에 대해 많이 읽었고 그가 이전 코멘트에서 사용한 어조 때문에 나는 약간 아이러니 한 어조로 마지막을 읽었다. 미안합니다.
문제에 관하여 들려요. 나는 나 자신에 대해 고민하고 있습니다 (그렇지 않으면이 문제를 그렇게 면밀히 보지 않을 것입니다). 돈 / 자원 측면에서 내가 가지고 / 낭비하지 않은 것에 대한 가정을하지 마십시오. 그러나 개발자로서 최악의 경우 주요 문제를 해결하려고 할 때 누군가가 당신을 쳐다 보는 것임을 압니다.

나는 당신의 풍자 읽기에 동의하며 그것이 생산적이지 않다는 데 동의합니다. 나는 또한“언제 고쳐질 것인가”라는 느낌에 동의한다. 안타깝게도이 주요 경로 CAT1 문제는 많은 사람들이이 문제에 대해 상당한 목소리를 낼 때까지 관심이 없었습니다. 이 문제를 해결하기 위해 내부적으로 프로세스가 개선되기를 바랍니다. 우리가 고칠 수있는 유일한 방법이 저주를 통해서만 가능하다면 우리 모두에게 짜증이 날 것입니다.

또한 Exceptionless nuget 패키지를 사용하여 전체 프레임 워크에서 이런 일이 발생한다는 보고서를 받고 있습니다. 확실한 수정 사항이나 해결 방법이 있습니까?

또한 전체 프레임 워크 4.6.2를 실행하는 Windows 서비스에서 자체 호스팅 ASP.NET Core를 가져옵니다. 종속성 NETStandard.Library 1.6.1은 System.Net.Http 4.3.0을 사용하도록합니다.

종속성 NETStandard.Library 1.6.1은 System.Net.Http 4.3.0을 사용하도록합니다.

이 모든 상황에서 가장 큰 문제입니다.

점점 더 많은 패키지가 메타 패키지에 대한 종속성을 가져 와서 내가 가진 모든 종속성을 업그레이드해야합니다 (또는 특정 항목을 다운 그레이드 / 무시하는 힘든 전투에 맞서 싸워야합니다).

이것은 시스템 종속성의 "혼합 및 일치"에 대한 이전 약속과 상반됩니다.

매 두 번째 패키지가 .net 1.6과 버그가있는 System.Net.Http를 가져 왔기 때문에 시스템을 4.6.1에서 4.5.2로 다운 그레이드해야했습니다.

이것이 제 3 자 패키지 일 뿐이라면, 나는 그것들을 돌아 다니며 더 세분화 된 종속성을 사용하도록 유지 관리자에게 귀찮게 할 수 있지만 대부분의 deps는 MS에서 왔으며 MS가 세분화 된 종속성을 사용하지 않을 것으로 예상합니다. .net 1.6을 너겟 파일에 넣으십시오.

지난 며칠 동안 업데이트를 보낼 계획 이었으므로 다음과 같습니다.

@CIPop 의 작업은 보안 문제로 인해 선점되었습니다. 그의 작품은 @davidsh에 의해 선택되었습니다. @davidsh 는 이번 주 초 (즉, 지금 언제든지) PR을 제출할 계획입니다.

실행 계획 및 상태에 대한 세부 정보는 다음과 같습니다.

높은 수준의 계획 :
A. CoreFX의 net46 빌드에서 WinHttpHandler를 HttpClientHandler로 대체
B. 4.1.0.0 OOB 패키지에서 소개 한 HttpClientHandler에 8 개의 새로운 API 구현

실행 계획 :

2017/1/12 수정 -실행 계획이 최상위 게시물 https://github.com/dotnet/corefx/issues/11100#issue -173058293으로 이동되었습니다.

@niemyjski 견고한 수정 사항이나 해결 방법이 있습니까?

문제가되는 패키지를 4.0.0.0 (https://github.com/dotnet/corefx/issues/11100#issuecomment-246469893 참조)으로 다운 그레이드하는 해결 방법이 있습니다. -이것이이 문제가 그토록 고통스러운 주요 이유입니다.

이 문제를 해결하기 위해 내부적으로 프로세스가 개선되기를 바랍니다. 우리가 고칠 수있는 유일한 방법이 저주를 통해서만 가능하다면 우리 모두에게 짜증이 날 것입니다.

여기에 프로세스 개선에 대한 몇 가지 아이디어 (및 질문)가있어 향후 중요한 영향을 미치는 문제가 오랫동안 눈에 띄지 않도록 방지 할 수 있습니다. 그러나 수정 사항이 배송 된 후 의도적으로 논의를 연기하고 있습니다.

우!

잘 했어 @karelz

업데이트 해주셔서 감사합니다. PlatformNotSupported는 레거시 소프트웨어가 의존하지 않는 새로운 API이기 때문에없는 것보다 낫습니다.

사후 수정처럼 들리지만 바인딩 리디렉션을 통한 통합은 여전히 ​​필요하지만 이전 어셈블리가 아닌 최신 어셈블리로 리디렉션해야합니다. 어떤 너겟이 올바르게 생성 될 수 있습니까?

PR dotnet / corefx # 15036이 체크인되었으므로이 문제는 wrt net46에서 사라집니다. System.Net.Http.dll은 이제 .NET Framework의 기본 제공 HTTP 스택을 사용합니다. 이는 WebRequestHandler와 100 % 호환성이 있음을 의미합니다.

MyGet 개발 피드에서 최신 패키지를 사용해보십시오. 오늘 현재 다음과 같은 최신 빌드 System.Net.Http.dll 패키지를 사용하는 것이 좋습니다.
https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Net.Http

버전 4.4.0-beta-24913-02.

명령 줄 도구 또는 Visual Studio를 사용하여 NuGet 패키지 소스 피드를 변경하여 개발 피드 패키지를 사용할 수 있습니다.

명령:

명령 줄 :
nuget.config에 다음을 추가합니다.요소:

<add key="myget.org dotnet-core" value="https://dotnet.myget.org/F/dotnet-core/api/v3/index.json" />

비주얼 스튜디오:
VS에서 도구-> 옵션-> Nuget 패키지 관리자-> 패키지 소스-> 추가, 소스에서 다음 URL을 사용합니다. https://dotnet.myget.org/F/dotnet-core/api/v3/index.json

두 경우 모두 MyGet 개발 피드를 목록의 첫 번째 피드로 나열해야합니다.

그리고 dotnet / corefx # 15036의 수정 사항을 요약하기 위해 원래 .NET Framework System.Net.Http 4.0 API 표면과 100 % 앱 호환성이 있고 WebRequestHandler 사용할 때 100 % 앱 호환성이 있습니다.

HttpClientHandler (. NET Core 1.1 이상에 포함됨)에 추가 된 최신 속성에 대한 지원 수준과 관련하여 다음은 'net46'대상에서 실행할 때 이러한 최신 속성의 예상 동작을 요약 한 것입니다. :

1) 공개 bool CheckCertificateRevocationList
PlatformNotSupportedException 던짐

2) 공개 X509CertificateCollection ClientCertificates
구현

3) 공용 ICredentials DefaultProxyCredentials
구현

4) 공용 int MaxConnectionsPerServer
현재 ServicePoint 로직에 대해 구현 됨

5) public int MaxResponseHeadersLength
구현

6) 공공 IDictionary속성
구현

7) 공용 기능ServerCertificateCustomValidationCallback
현재 내부 HttpWebRequest 를 HttpRequestMessage 에 매핑 할 수 없기 때문에 첫 번째 매개 변수가 항상 null 인 것을 제외하고 구현됩니다.

8) 공용 SslProtocols SslProtocols
PlatformNotSupportedException 던짐

우후! 감사합니다!

누구든지 @davidsh 의 비트를 검증 할 기회를 얻었습니까? 이 스레드에 암시 된 7 가지 시나리오에 대한 종단 간 유효성 검사를 정말 환영합니다.

지금까지 @onovotny 의 단순화 된 재현을 검증 할 수있었습니다. 우리가 로컬에서 가지고 있지 않은 재현에 대해 몇 가지 더 많은 확인을 얻는 것이 좋을 것입니다. 감사!

그런 다음 변경 사항을 1.1 브랜치로 포팅하고 패치를 출시 할 예정입니다.

이번 주에 몇 가지 테스트를 할 것입니다. 방금 에스컬레이션에 들어갔 기 때문에 추측으로는 1-2 일 동안 시작할 수 없습니다.

@dluxfordhpf 감사합니다! 당신의 도움을 주셔서 감사합니다.

방금 프로젝트에 4.4.0-beta-24913-02를 설치했습니다. 제 사건에 도움이되는 것 같습니다.

사례 : 전체 프레임 워크 4.6.2를 실행하는 Windows 서비스에서 자체 호스팅 ASP.NET Core. 종속성 NETStandard.Library 1.6.1은 System.Net.Http 4.3.0을 사용하도록합니다.

내 경험상 myget 피드가 매우 느립니다. System.Net.Http 4.4.0-beta-24913-02를 설치하는 데 몇 분이 걸렸습니다.
OK https://dotnet.myget.org/F/dotnet-core/api/v3/registration1/system.net.http/index.json 82079ms
OK https://dotnet.myget.org/F/dotnet-core/api/v3/registration1/system.net.http/index.json 93813ms

확인하고 시나리오를 설명해 주신 @ annemartijn0 에게 감사드립니다!

이 페이지가 결과를 반환하는 데 현재 5 ~ 7 분 정도 걸립니다.
https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Net.Http

마이크로 소프트는 왜이 그늘진 작은 회사와 어리석은 작은 사이트에 중요한 인프라를 아웃소싱합니까? 벨기에에있는 Tech Tomato라는 회사에 귀하의 비즈니스와 내 비즈니스를 고정하기로 결정 하셨나요?

어쨌든 ... 이미 myget 피드가 있었지만 Visual Studio를 다시 시작한 후 대화 상자에있는 "업데이트"단추를 클릭 한 다음 Visual Studio를 두 번째로 다시 시작할 때까지이 라이브러리를 가져 오지 않았습니다. 현재 Visual Studio 2015가 내 패키지를 복원하려고 시도하는 동안 이것을 입력하고 있습니다.

업데이트 : Visual Studio는 여전히 흔들리고 있지만 myget 페이지 새로 고침이 마침내 나타났습니다. 이 버전의 라이브러리를 하루에 수십 번 다운로드 할 수 있습니다. 한편 Visual Studio는이를 "System.Net.Http-75.8K 다운로드"로 요약합니다. 나는 항상 이러한 통계가 잘못된 것을 말하고 있다고 가정했지만 여기에 내가 원하는 것이 아닌 이유에 대한 좋은 예가 있습니다. .NET 역사상이 어리석은 순간에 명시 적으로 광기를 선택하지 않고 의도 치 않게 알파 테스터가되지 않도록 최소한 현재 버전 상태와 요약을 알려주세요.

5 시간 후에도 여전히이 패치를 시도 할 수 없습니다.

Attempting to gather dependency information for package 'System.Net.Http.4.4.0-beta-24913-02'
with respect to project '...', targeting '.NETFramework,Version=v4.6.1'

오분 뒤...

Package 'System.Net.Http 4.4.0-beta-24913-02' is not found in the following primary source(s):
'https://dotnet.myget.org/F/dotnet-core/api/v3/index.json'. Please verify all your online package
sources are available (OR) package id, version are specified correctly.

.NET은 타이어 화재입니다.

@chadwackerman . 베타 / 알파 / 비 프로덕션 피드에 _ 옵트 인 _ 했으므로 문제 등을 제외 할 준비가되었음을 의미합니다. 즉, 저는 오랫동안 myget (유료 구독)을 사용해 왔으며 문제가 거의 없습니다. 그것. 그래서 어쩌면 .. 어쩌면 .. 그것은 당신의 컴퓨터 / 네트워크 연결 / 무엇이든간에? (지난 12 개월 이상 MyGet을 사용하여 정말 큰 성과를 거두었습니다).

.NET은 지금 당장 타이어 화재가 아닙니다. 물론, 치즈가 _ 무더기 _ 움직이고 있고, 움직이는 부품과 부품이 많이 잘못 될 수 있습니다. 그러나 RC 및 RTM 비트가 출시되어 훌륭한 일을하는 사람들이 많습니다. 저는 개인적으로 공개 릴리스 만 사용하기로 결정했습니다. 더 이상 베타 나 RC도 사용하지 않습니다. 그래서 제 기대는 문제는 적지 만 더 오래 기다려야한다는 것입니다. 따라서이 중 일부가 정말 실망 스럽다는 것을 발견했다면-이 개발 작업 중 일부가 RTM 상태에 도달 할 때까지 조금 더 기다리십시오.

corefx 팀 (및 .NET-core 세계의 다른 팀)의 작업은 bad-ole-Balmer-day에 비해 github / open-and-transparent 진행과 관련하여 훌륭하고 환영 받았습니다. 모두는 리포 유지 관리자에게 긍정적이고 도움이되도록 노력합니다. 여기에있는 모든 사람은 인간이며 한 번에 한 바이트 씩 세상을 더 나은 곳으로 만들기 위해 노력하고 있습니다.

@chadwackerman 지금 myget 피드가 고통받는 것 같습니다. myget이 어떻게 작동하는지 100 % 확신 할 수는 없지만 전용 호스트 ( "dotnet.myget.org")가 있다면 피드가 실제로 테넌트되고 QOS 제한이 있다고 생각합니다.

여기로 이동하면 패키지가 존재하지만 표시되는 데 시간이 걸립니다. https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Net.Http

@PureKrome 저는이 빌드를 확인하라는 요청을받은 전 Microsoft 개발자 관리자입니다 (위 참조). .NET 팀의 아무도 모르기 때문에이 버그를 내부적으로 에스컬레이션 한 후. 그리고 이제 그들은 나에게 빌어 먹을 바이너리를 보낼 수 없습니다

나는 타이어 화재를 볼 때 압니다. 나는 생계를 위해 마이크로 소프트에 내 놓곤했다.

@chadwackerman 피드 문제에 대한 불만을 이해할 수 있습니다. 그러나 ( '멍청한 작은 사이트'와 '그냥 작은 회사')라는 이름은 순서가 맞지 않습니다.
Tech Tomato는 자격을 갖춘 개인이 설립 / 운영합니다. @maartenba , 귀하의 전 고용주가 MVP 수상자, 현재 MS 직원 인 @xavierdecoster . 혁신을 장려하는 국가 (내가 선호하는)에서. 회사 이름은 거의 관련이 없으며 회사가 벨기에에서 설립되었음을 보여줍니다. .NET Core 팀은 솔루션을 위해 워싱턴 주 레드몬드를 넘어서고 있습니다.
이 문제를 해결하는 데 도움이되는 건설적인 기여를 기대합니다.

운영자가 편집 한 콘텐츠

이 스레드의 일부 댓글에 대해 행동 강령 보고서가 제출되었으며 그 결과 해당 강령을 위반 한 것으로 판단되는 일부 자료를 제거했습니다. 이에 대한 질문이나 우려 사항이 있으면 [email protected]로 이메일을 보내

@chadwackerman 회사에서 귀하의 이전 직위는 권한을 부여하지 않습니다. 또한이 스레드에 대한 대부분의 '기여'는 구조적이지 않을뿐만 아니라 사소하고 유치하며 주제에서 벗어난 것입니다. 다른 곳에서 트롤하십시오.

안녕하세요 여러분-여기 .NET 재단의 Martin 이 이것을 설명하고 싶었습니다.

이 스레드에 의해 제기 된 원래 문제가 실망스럽고 사람들이 해결하기를 원한다는 점에 깊이 감사드립니다. 또한 품질과 배송, 전반적인 느낌의 강도에 대한 더 큰 우려를 이해합니다. 팀은이 문제를 해결하기 위해 노력하고 있으며 계속해서 사람들을 업데이트 할 것입니다.

그 동안 전문적인 어조를 유지하고 타인에 대한 인신 공격으로 인식 될 수있는 발언은 삼가 해 주시기 바랍니다. 나는 감정의 힘을 일부 보존하고 지나치게 위생적으로 처리하지 않기 위해 편집 한 내용을 고의적으로 조명했습니다.

다른 사람이 Tech Tomato에 연락을 시도한 적이 있습니까? 내 문의에 대한 응답이 없습니다.

피드를 추가 한 후 이상한 빌드 경고를 분류하는 실제 작업을 시도하면 다음과 같습니다.

Attempting to gather dependency information for package
'System.Net.Http.4.4.0-beta-24913-02' targeting '.NETFramework,Version=v4.6.1'
Gathering dependency information took 1.55 min

Attempting to gather dependency information for package 
'Microsoft.Extensions.Configuration.Json.1.1.0' targeting '.NETFramework,Version=v4.6.1' 
Gathering dependency information took 2.2 min

... 등등.

이 링크는 페이지를 표시하는 데 여전히 5 분 이상 걸립니다.
https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Net.Http

이것이 a) 아직 수정되지 않았 음 b) 커뮤니티에서 무시되고 c) 일상적인 개발의 일환으로 .NET 팀이이 버그를 유발 한 프로세스, 도구, 문화 및 관리의 명백한 결함을 강화하는 역할을합니다. 처음부터-버그 자체는 제가 개인적으로 내부적으로 에스컬레이션 할 때까지 몇 달 동안 무시되었습니다.

@karelz가 약속 한 사후 부검을 기대하고 있습니다.

안녕하세요 차드,

그 페이지로드 시간은 우리가보고있는 것입니다. NuGet 복원 시간이 정상이 아닙니다. 가능하면 사용중인 NuGet.exe 버전에 대한 언급과 -Verbosity Detailed 스위치가 활성화 된 추적을 통해 MyGet.org의 지원을 통해 (MyGet)에 문의 할 수 있습니까? 이는 성능 문제를 정확히 파악하는 데 도움이 될 것입니다.

감사!

패키지 관리자 콘솔 호스트 버전 3.5.0.1996

myget.org 피드를 추가하면 Visual Studio가 견고 함에서 불안정 해짐에 따라 명령 줄에서 로그를 가져 오는 방법을 살펴 보겠습니다. 그리고 일단 패키지를 잡아 당기는 오류가 발생하면 모든 것이 넘어집니다.

ps @karelz : 타이어 화재.

www.nuget.org/downloads의 최신 (야간) NuGet.exe를 사용하여이 명령 줄을 사용해 볼 수 있습니까 ?

정확한 명령 : NuGet.exe install System.Net.Http -Version 4.4.0-beta-24913-02 -Verbosity Detailed

이렇게하면 모든 중간 다운로드 작업도 출력됩니다. 감사!

@maartenba :

보낸 링크에서 "latest"는 https://dist.nuget.org/win-x86-commandline/latest/nuget.exe를 가리 킵니다

야간 패키지 NuGet.CommandLine.4.0.0-rtm-2254.nupkg를 다운로드하고 여기에 nuget.exe 설치를 실행했지만 myget.org에서 파일을 가져 오지 못했습니다. 참고 : dotnet.myget.org에서 404를 반환하는 데 1.5 초가 걸립니다.

이것이 야간 빌드 또는 로컬 패키지를 설치하는 올바른 방법이 아닌 경우 알려주십시오. 오프라인으로 전환하려면 Gmail에서이 사용자 이름으로 이메일을 보내주세요.

도와 드리겠습니다.하지만 ... 와우. 4.0.0-rtm 버전 임에도 불구하고 어떻게 든 5 가지 다른 수동 방법이있는 패키지 관리자의 야간 드롭을 사용하여 기본 패키지 호스트의 보조 패키지 호스트 문제를 해결하는 것이 아니라 단순함의 방향으로 진행되어야합니다. 배포 페이지에서 자체 업데이트되며, 각 페이지에는 수동 사용자 개입이 필요합니다.

ps @karelz ... 아, 신경 쓰지 마. :)

완전히 동의하지만 로그는 병목 현상이있는 곳을 찾는 데 매우 유용합니다 (보조 패키지 호스트, 클라이언트 자체, 미친 CDN 노드, 우주선 등). 오프라인으로 연락하여이 문제를 파악할 수 있는지 확인합니다. 도움을 주셔서 감사합니다.

myget.org가 매우 느리다는 것을 알아 차 렸지만 "합리적인"시간 (공용 Wi-Fi 네트워크에서)에 문제의 패키지를 성공적으로 설치할 수있었습니다.

OK https://dotnet.myget.org/F/dotnet-core/api/v2/package/System.Net.Http/4.4.0-beta-24913-02 971ms
Installing System.Net.Http 4.4.0-beta-24913-02.

전체적인 myget.org 속도 저하를 확실히 조사해야하지만 아마도이 문제의 범위를 벗어나는 것입니다. 결국 일반적인 고객 시나리오는 아닙니다. @maartenba 그것을 논의하기에 가장 좋은 장소는 어디입니까?
여기에서 (이 특정 문제에 대해) 창의적인 해결 방법을 사용하여 엔드 투 엔드 유효성 검사를 차단 해제하는 방법에 중점을 두겠습니다.
또한 다른 사람들이 @chadwackerman 만큼 심하게 차단되었는지 또는 @chadwackerman 의 경험이 다른 사람들에 비해 극도로 나쁜지

@chadwackerman 여기서 주요 목표는 종단 간 시나리오를 검증하는

피하고 싶은 마지막 수단은 시나리오 유효성 검사를 완전히 건너 뛰는 것입니다. 다른 엔드-투-엔드 시나리오의 유효성이 확인되지 않으면 괜찮을 수 있습니다 ( @maartenba가 있는 최악의 시나리오를 가정하면 귀하의 매우 나쁜 myget.org 경험 문제를 해결할 수 없습니다 :().

@karelz 가 Chad와 함께 오프라인 상태로 전환하면 무슨 일이 일어나고 있는지 알아 내면 여기로 다시보고 할 것입니다.

배경 사실 :

• myget.org 피드는 매일 빌드, CI, dev-workflow 등에서 사용됩니다. 따라서 매일 많은 문제가 발생합니다. 이러한 성능 문제는 이러한 시나리오에서 나타나지 않습니다 (과거에 작업을 수행했을 때 개발자의 워크 플로에 영향을 주었기 때문에 작업을 수행했습니다. 지난 몇 달 동안 동기화 시간이 30 ~ 60 분으로 단축되었습니다). 내 이해는 .NET 팀 또는 커뮤니티의 누구든지 VS에서 myget 피드를 사용하는 경우가 드물다는 것입니다. IMO는 해당 시나리오에서 나쁜 성능이 눈에 띄지 않게 된 이유를 설명합니다.
• 이 문제는 2016/12/9에이 스레드의 동료에 의해 나에게 전달되었습니다. 그래서 여기에서 토론에 참여했습니다. 다른 내부 에스컬레이션에 대해 알지 못합니다. 이 문제를 여러 팀 (거의 매일)에 걸쳐 내부적으로 지속적으로 추진하고 있다는 점을 감안할 때이 문제와 관련된 모든 이벤트를 알고 있다고 생각합니다.

@karelz 예, 같은 날짜 2016/12/9에 내부 연락을 통해이 문제를 에스컬레이션했습니다. 사후 분석 후 개인적으로 작업하는 세부 정보, 이메일 및 프로젝트를 제공하고 오프라인으로 마무리 할 수 ​​있습니다. 아마도 개인적으로, 아마도 알코올을 사용했을 것입니다.

나는 MyGet.org가 동부 및 서부 해안에있는 여러 친구의 컴퓨터에서 오작동하는 것을 확인했습니다. Mine은 최근 Visual Studio 2015를 새로 설치했으며 추가 기능이 없으며 ReSharper도 없습니다. Visual Studio의 사용자 피드백 및 오류 처리가 좋지 않습니다. 여기에서도 다른 사용자가 유사한 지연을보고합니다. 스레드를 해제하기 위해 지금은 이것을 떨어 뜨릴 것이지만 MyGet이 지루하지 않고 전체 NuGet 패키징 시스템 (및 NuGet 자체 업데이트 기능)이 희미하게 고무 타는 냄새가 나지 않는다고 가정해서는 안됩니다. 이 버그의 원인이됩니다. 둘 다 원래 근본 원인의 일부로, 심지어 현재까지도 수정 사항을 테스트하고 제공하려는 노력의 일환으로 사용되었습니다.

이 스레드에서 계속 논의해야하는지 아니면 다른 스레드를 열어야하는지 확실하지 않습니다. 어쨌든 : 상태보고!

이메일을 통해 @chadwackerman 과 연락을

"느림"에 대해-예비 프로파일 링은 이것이 패키지 버전의 수와 프로토콜 데이터의 다운로드 크기에 미치는 영향으로 인해 발생했음을 알려줍니다. 예를 들어 일부 패키지는 메타 데이터를 수집하기 위해 4MB의 JSON 데이터를 다운로드하고 구문 분석해야합니다. 이로 인해 NuGet 클라이언트에서 큰 메모리 사용량이 급증하고 JSON 데이터의 보트로드를 구문 분석해야합니다. 클라이언트의 4.0.0 nightlies가 더 잘 작동하는 것처럼 보이지만 확실히 개선의 여지가 있습니다.

MyGet 측에서는 이러한 프로토콜 Blob에 대한 페이징을 구현하여 프로토콜의 다운로드 크기를 줄일 것입니다. 게시하는 데 일주일이 걸릴 수 있습니다. 또한 이러한 요청에 대해 서버와 클라이언트를 모두 프로파일 링하고 양쪽에 최적화의 여지가 있는지 확인합니다.

또한 페이지로드 시간을 단축하는 방법도 검토하고 있습니다 (그러나 이는 2 차적이며 빠른 설치 / 복원 작업이 우선입니다).

몇 시간의 실험 끝에 Visual Studio를 중단하지 않고 System.Net.Http 4.4.0-beta-24913-01로 업그레이드 할 수있었습니다. 그런 다음 24913-01에서 24913-02로 업그레이드하려고 시도했지만 충돌 대신 적절한 오류가 발생했습니다.

2017 년이며 전체 시스템에 대한 핵심 HTTP 구성 요소의 야간 빌드를 "월요일 빌드"에서 "화요일 빌드"로 업데이트하려면 8 코어 i7에서 벽시계 시간이 5 분 이상 걸리며 4GB 이상의 RAM이 필요합니다.

문제의 프로젝트는 27 줄의 코드로 구성된 웹 작업 (브랜드가 변경된 명령 줄 앱)입니다.

흥미롭게도 @karelz 는 이것이 전체 .NET 팀에서 훌륭하게 작동하며 현지 스타 벅스에서 라떼를 마시면서도 바이너리를 빨아들이는 데 전혀 문제가 없다고 말합니다.

문제의 패키지를 "합리적인"시간 (공용 Wi-Fi 네트워크에서)에 성공적으로 설치할 수있었습니다.
https://dotnet.myget.org/F/dotnet-core/api/v2/package/System.Net.Http/4.4.0-beta-24913-02 971ms

다음은 몇 가지 대체 사실입니다.

'.NETFramework, Version = v4.6.1'을 대상으로하는 'webjob'프로젝트와 관련하여 'System.Net.Http.4.4.0-beta-24913-02'패키지에 대한 종속성 정보를 수집하려고합니다.
종속성 정보 수집에 4.22 분 소요
DependencyBehavior 'Lowest'로 패키지 'System.Net.Http.4.4.0-beta-24913-02'에 대한 종속성 해결 시도
패키지 'System.Net.Http.4.4.0-beta-24913-02'설치 조치 해결
'System.Net.Http.4.4.0-beta-24913-02'패키지 설치 조치를 해결했습니다.
System.OutOfMemoryException : 'System.OutOfMemoryException'유형의 예외가 발생했습니다.
Newtonsoft.Json.Linq.JContainer.ReadContentFrom (JsonReader r)
Newtonsoft.Json.Linq.JContainer.ReadTokenFrom (JsonReader 리더)
Newtonsoft.Json.Linq.JObject.Load (JsonReader 리더)
NuGet.Protocol.HttpSource. <> c.b__15_0 (스트림 스트림)

이 MyGet / NuGet 문제를 새로운 문제로 옮겨 주시겠습니까? 원래 문제와는 관련이 없습니다.

@onovotny- 문제를 다시 여는 것을 고려할 수 있습니다. 이 문제는 이제 매우 길어 문제의 유용성이 감소했습니다.

스레드를 감시하는 대신 @richlander 대신 수정 프로그램을 설치하고 특정 문제가 해결되면보고 하시겠습니까? 모두가이 중요한 문제에 의해 차단 된 것처럼 보이지만 사람들은 수정을 테스트하기 위해 실제 작업을 수행하는 것보다 GitHub 핑퐁을 사용하는 편이 낫습니다.

커뮤니티에서보고 한 모든 ~ 7 개의 엔드-투-엔드 시나리오 테스트 (커뮤니티의 도움 요청, myget에서 마스터 패키지 사용 단계 제공)

7 가지 시나리오는 무엇입니까? 모두가 도울 수 있습니까?

@richlander 문제를 다시 열어 드리겠습니다. @karelz 의 업데이트

내 사용 사례는 4.0.1-rc2-24027에서 마지막으로 작동했던 Azure Storage API로 작업했습니다. 지금 작동하는 것 같습니다. MyGet에서 내 프로젝트의 모든 패키지를 업데이트하는 데 약 20 분이 걸렸으므로 간단한 테스트 만 수행했습니다.

@onovotny 다시 열지 마십시오. 여기에 추진력이 있고 적어도 부분 해상도에서 몇 인치 떨어져 있습니다. 스레드는 지금 막 참여하는 모든 사람에게 압도적이지만, 더 깊은 문제를 드러내는 다른 오래 지속되는 해결되지 않은 문제와 마찬가지로 그래야합니다. GitHub는 이런 일을 싫어합니다.

새 바이너리가 하나의 로컬 앱에서 호환되는지 확인했습니다. 놀랄 일이 아닙니다. 그런 다음 해당 종속성을 잘라내어 내 웹 작업 프로젝트에 붙여 넣으려고했지만 Azure에서 작동하지 못했습니다. Webjob은 정상적으로로드되지만 트리거되면 실패하고 System.Net.Http를로드 할 수 없습니다. 이것은 분명히 내 잘못이고 나는 그것을 고칠 훈련을 알고 있습니다. 하지만 저는이 버그가 처음 열렸을 때로 돌아 왔습니다. 비틀기 바인딩 리맵과 NuGet을 만질 때 모든 지옥이 풀리고 엄청난 시간을 낭비하고 프로젝트는 로컬에서 모든 테스트를 통과하지만 배포시 런타임에 중단됩니다. .

따라서 우리의 시나리오는 다음과 같습니다.

1. 종속 (Raven.Database) 패키지는이 문제에보고 된대로 런타임에 중단 된 WebRequestHandler를 사용합니다.
2. 우리 코드는 새로운 HttpClientHandler 유형과 속성을 사용합니다.

이전에는 바인딩 리디렉션 수정을 시도했지만 이로 인해 분쟁이 발생했고 결국 해킹 (반사 주입, 타사 코드 복제 및 수정)을 사용하여 문제를 해결했습니다.

베타로 업데이트하고 모든 해킹 코드를 제거했으며 모든 것 (브라우저에서 데이터베이스에 이르기까지 우리의 애플리케이션, 엔드 투 엔드)이 로컬에서 작동하는 것처럼 보입니다! 아직 Azure 플랫폼에서 코드를 시도하지 않았으므로 완료되면 다시 확인하겠습니다. 그러나이 중요한 진행 상황을 고려합니다.

또한 패키지를 업데이트 할 때 Visual Studio 패키지 관리자 콘솔을 사용하고이 명령을 사용하여 패키지를 업데이트하는 것이 허용되는 것으로 나타났습니다 (다른 피드 구성을 추가 한 다음 UI를 사용하는 것보다 매우 고통 스럽습니다).

Update-Package System.Net.Http -Version 4.4.0-beta-24913-02 -Source https://dotnet.myget.org/F/dotnet-core

20 개의 프로젝트를 업데이트하는 데 6 분 53 초가 걸렸습니다.

모든 프로젝트에는 다음 바인딩 리디렉션이 자동으로 생성되었으므로 바인딩 리디렉션을 전혀 조작 할 필요가 없습니다.

    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-4.2.0.0" newVersion="4.2.0.0" />
      </dependentAssembly>
    </assemblyBinding>

하이 파이브를 할 시간입니다!

@jahmai 명령 줄을 사용했을 때 참조를 4.0에서 4.2로 업데이트하거나 필요한 복사 플래그를 추가하지 않았습니다. System.Net.Http 및 종속성에 대해 설정되어 있는지 확인하고 Azure에서 제대로 작동해야합니다.

우리의 시나리오는 System.Net.Http의 형식에 대한 직접적인 종속성입니다.
한 프로젝트에서 Update-Package System.Net.Http -Version 4.4.0-beta-24913-02 -Source https://dotnet.myget.org/F/dotnet-core 테스트했는데 지금까지 잘 작동하는 것 같습니다. 아주 좋은 소식입니다.
업데이트 4.0.0.0에서 4.2.0.0으로의 바인딩 리디렉션이 자동으로 적용되었음을 언급하는 것을 잊었습니다.

Nuget / MyGet 문제와 관련하여이 단일 프로젝트에 대해 다음 출력을 얻었습니다.

종속성 정보를 수집하는 데 37.47 초가 걸렸습니다.
너겟 작업을 실행하는 데 35.15 초가 걸렸습니다.
경과 시간 : 00 : 01 : 14.7537429

시간대 UTC +01 : 00에 있으며 MyGet이 언제 가장 많은 트래픽을 받고 있는지 알 수 없습니다.

@pollax 감사합니다. 우리는 문제를 발견했습니다 (위의 마지막 설명 참조)-클라이언트 + 서버 조합. 개선을 위해 노력하고 있습니다.

MyGet의 베타 System.Net.Http 라이브러리를 사용하여 내 시나리오에서 작동했는지 확인할 수 있습니다.

• System.Net.Http를 사용하는 라이브러리에 대한 종속성이있는 .NET 4.6 콘솔 애플리케이션

Nuget 패키지를 MyGet에서 다운로드하는 데 약 90 초가 걸렸고 app.config의 bindingRedirect가 올바르게 적용되었습니다.

어딘가에 설명 된 경우 더 많은 시나리오를 테스트하는 데 도움을 드리겠습니다.

흥미로운 부작용 : Windows 전용 .NET 라이브러리의 4.4.0 베타를 추가하면 Linux에서 .NET Core 애플리케이션의 배포가 중단되었습니다.

"dotnet 복원"은 패키지 검색 시간이 60 초로 하드 코딩됩니다. 그리고 "dotnet publish"지원과 같은 특정 플랫폼 만 선택할 수있는 플래그가 없습니다. 따라서 크로스 플랫폼 라이브러리의 경우 작은 Linux 작업자 노드가 불필요하게 많은 Windows 바이너리를 다운로드 한 다음 MyGet에 도달하면 시간이 초과되고 실패합니다. 놀랍게도 32GB 컴퓨터에서 Visual Studio를 충돌시키는 메모리 부족 문제는 0.75GB Linux 작업자에게 영향을주지 않습니다.

예, 다른 곳에 기록했습니다. 그리고 예, 아직 보지 못하더라도이 버그와 관련이 있습니다.

시나리오 확인을 도와 주신 모든 분들께 감사드립니다! 우리는 지금까지 5 개의 확인을 받았습니다-최상위 게시물의 링크가있는 자세한 목록을 참조하십시오. 나는 다음 단계로 넘어 가기에 충분한 검증이라고 생각합니다.

• [4.a.ii] 아직 NuGet 분석을 추적 중입니다.
• [5.a] @davidsh 에게 릴리스

• [5.b] 릴리스 프로세스를 준비하고 있습니다 (이사 수준의 승인이 필요하지만 고객에게 미치는 영향을 고려할 때 어떤 푸시 백도 기대하지 않습니다).

• 저는 패치 릴리스에 대한 공식 정보를 준비하고 있습니다-모든 기술적 주요 변경 사항 및 해결 방법을 나열 합니다 (데이터에 대해

그동안 누군가가 (이 특정 문제와 관련하여) 우려 사항을 발견하면 최대한 빨리 그렇게 말하십시오. 손가락이 엇갈 렸다.

@onovotny- 문제가 현재 진행중인 것으로 보이

@karelz ServiceBus 종속성이있는 4.6 명령 줄 (Azure webjob)과 Azure Batch에 대한 종속성이있는 4.6 앱이 포함 된 시나리오를 확인할 수 있습니다. 또한이 문제에서 벗어나기 위해 이전에 .NET Core로 이동 한 AWS 및 Dropbox에 대한 종속성이있는 세 번째 앱 (오늘 테스트하기 위해 이전 버전을 가져옴).

dotnet 복원 문제는 https://github.com/NuGet/Home/issues/2534 , Contributor Covenant 고정 백 채널, 타이어는 https://github.com/Azure/azure-storage-net/issues/372 , MyGet에서 되살아납니다. 전송 된 로그, https://github.com/dotnet/cli/issues/5328 에서 요청 된 추가 성능 로그, 그리고 사후 토론을 위해 거대한 팝콘 가방을 샀습니다.

귀하의 도움과 확인을 위해 @chadwackerman 에게 감사드립니다! 도중에 발생한 문제에 대해 죄송합니다.
최상위 게시물을 업데이트했습니다.

위의 내 목록에서 :

저는 패치 릴리스에 대한 공식 정보를 준비하고 있습니다-모든 기술적 주요 변경 사항 및 해결 방법을 나열 합니다 (데이터에 대해

맨 위에있는 게시물에 정보를 추가했습니다. 각각의 해결 방법이있는 기술적 주요 변경 사항 목록 (4)은 "변경 사항의 영향-주요 변경 사항"섹션을 참조하십시오.

기술적 인 주요 변경 사항의 영향을받는 NuGet 라이브러리 (최상위 게시물에 설명 됨)-운 좋게도 이러한 새로운 API를 사용하는 4 개의 NuGet 라이브러리 :

System.Private.ServiceModel_4.3.0

• https://www.nuget.org/packages/System.Private.ServiceModel/
• 저자 : dotnetframework
• 다운로드 : 11K (최신 버전) / 800K (전체)
• 설명 : 직접 사용하기위한 내부 구현 패키지가 아닙니다. 직접 참조하지 마십시오. System.ServiceModel 패키지의 구현을 제공합니다.
• 메모:
• 상태 : 패키지가 영향을받지 않음 -WCF 팀의 @zhenlan @mconnew 가 .NET Core 빌드에서만 속성을 사용함을 확인했습니다. 데스크톱에서는 기본 제공 데스크톱 바이너리로 돌아갑니다.

Consul_0.7.2.1

• https://www.nuget.org/packages/Consul/
• 이름 : 영사
• 저자 : https://www.nuget.org/profiles/highlyunavailable
• 다운로드 : 500 (최신 버전) / 65K (전체)
• 설명 : https://github.com/PlayFab/consuldotnet/blob/master/CHANGELOG.md
• 메모:
  
  
  
  • 2 가지 사용법 : https://github.com/PlayFab/consuldotnet/search?utf8=%E2%9C%93&q=ServerCertificateCustomValidationCallback
  
  
  • GitHub에 제출 된 문제 : https://github.com/PlayFab/consuldotnet/issues/79
  
  
  • nuget.org를 통해 작성자에게 보낸 이메일
  
  
• 상태 : 패키지가 영향을받지 않음 (GitHub 문제 https://github.com/PlayFab/consuldotnet/issues/79 마감 됨)

Octopus.Client_4.6.1

• https://www.nuget.org/packages/Octopus.Client/
• 저자:
  
  
  
  • https://www.nuget.org/profiles/paulstovell
  
  
  • https://www.nuget.org/profiles/OctopusDeploy
  
  
• 다운로드 : 250 (최신 버전) / 55K (전체)
• 설명 : 없음
• 메모:
  
  
  
  • GitHub에 제출 된 문제 : https://github.com/OctopusDeploy/OctopusClients/issues/121
  
  
  • 지원 별칭으로 보낸 이메일 : [email protected]
  
  
  • nugget.org를 통해 작성자에게 이메일 전송
  
  
• 상태 : 패키지가 영향을받지 않음 (GitHub 문제 https://github.com/OctopusDeploy/OctopusClients/issues/121의 세부 정보)

Geotab.Checkmate.ObjectModel_5.7.1701

• https://www.nuget.org/packages/Geotab.Checkmate.ObjectModel/
• 이름 : Geotab SDK
• 저자 : https://www.nuget.org/profiles/neilcawse
• 다운로드 : 150 (최신 버전) / 10K (전체)
• 기술:
  
  
  
  • MyGeotab 고객 데이터베이스에 액세스하기위한 SDK 라이브러리
  
  
  • https://my.geotab.com/sdk/default.html#/whatsNew 에서 전체 목록 변경 사항을
  
  
• 메모:
  
  
  
  • nugget.org를 통해 작성자 (geotab.com CEO)에게 이메일 전송
  
  
• 상태 : 소유자에게 연락 함, 응답 대기 중

영향을받는 모든 패키지 작성자에게 불편을 끼쳐 드려 죄송합니다.

Linux의 Visual Studio / NuGet 충돌 / 스와핑에서 : 그 이유는 NuGet 프로토콜이 작동하는 방식에 있습니다. 이 문제의 결과를 문서화했습니다 : https://github.com/NuGet/Home/issues/4448

MyGet 측에서는이 서버 측을 완화하는 주말 (현재 테스트 중, 2 월 7 일 월요일 ETA) 이후 변경 사항을 배포 할 것입니다.

MyGet 측의 수정이 적용되었습니다. Visual Studio에서 잘 작동합니다. NuGet.exe를 사용할 때 https://dotnet.myget.org/F/nuget-build/api/v2/package/NuGet.CommandLine(4.0 nightly)에 포함 된 NuGet.exe를 사용해야합니다. 3.5 는 종속성을 파악하지 못하는 것 같습니다 (항상 그런 것은 아닙니다). 기록 된 버그 : https://github.com/NuGet/Home/issues/4512

이 @maartenba에 대해 자세히 알아 보셔서 감사합니다. 사소한 도구 수정으로도 영향을 과소 평가하지 마십시오!

전체 .NET 팀이 Visual Studio 충돌과 NuGet 문제를 모두 놓칠 수 있다는 점이 흥미 롭습니다.

디버거에서 중단 점을 설정하는 데 문제가있는 사람이 있으면 80 명 이상의 Microsoft 개발자 방에 손을 들어달라고 요청한 적이 있습니다. 나는 두 손을 얻었다. 컴파일러가 심볼 형식을 변경하여 최신 컴파일러 없이는 프로젝트를 빌드 할 수 없었지만 디버거는 아직 업데이트되지 않았습니다.

몇 달 동안 아무도 중단 점을 설정할 수 없었습니다. 두 플랫폼에서는 스택 추적도 얻을 수 없었습니다! 나는 내가 유일한 다른 사람이기 때문에 오전 1시에 빌드 랩에 호출을 받고, 문서를 본 적도없는 프로세서의 어셈블리로 가득 찬 화면을 얻고, 역 추적을 풀고 디버거가 디버거에 충돌합니다.

새 버전의 Visual Studio에 연결되는 새 버전의 패키지 관리자를 dogfood하는 동안 프로젝트 형식을 구문 분석하는 코드를 변경하는 동안 프로젝트 형식을 변경하면 이러한 결과가 나타납니다. 필멸자는 한 번에 너무 많은 변화를 처리 할 수 ​​있으며 이것이 개발자가 공을 사방에 계속 떨어 뜨리는 이유입니다. 우리와 그들 모두!

누군가가 모든 app.config에서 bindingRedirect 수정을위한 간단한 powershell 스크립트를 원한다면 여기에 있습니다. 아마도 최선의 해결책은 아니지만 현재 많은 웹 작업 하위 프로젝트가있는 프로젝트가 있으며 일부 패키지를 업데이트 한 후 모든 파일 바인딩을 수동으로 변경하는 것이 정말 실망 스럽습니다.

param(
    [string]$SourceDirectory,
    [string]$Package,
    [string]$OldVersion,
    [string]$NewVersion
)

Write-Host "Start fixing all app.config"

[array]$files = get-childitem $sourceDirectory -Include app.config App.config -Recurse | select -expand FullName
foreach ($file in $files)
{
    Write-Host $file
    $xml = [xml](Get-Content $file)
    $daNodes = $xml.configuration.runtime.assemblyBinding.dependentAssembly
    foreach($node in $daNodes)
    {
        if($node.assemblyIdentity.name -eq $package)
        {
            $updateNode = $node.bindingRedirect
            $updateNode.oldVersion = $OldVersion
            $updateNode.newVersion =$NewVersion
        }
    }
    $xml.Save($file)
}

Write-Host "Done"`

사용 예 :
./scripts/FixAppConfig.ps1 -SourceDirectory "--project-path--" -Package "System.Net.Http" -OldVersion "0.0.0.0-4.3.0.0" -NewVersion "4.0.0.0"

언제 다시 공개 되나요? :)

화요일에 release / 1.1.0 브랜치로 변경되었습니다-패키지 버전 4.3.1. 브랜치의 모든 패키지는 어제 안정적으로 전환되었습니다 (독립적 인 노력이지만 우리에게도 도움이됩니다 :)).
@davidsh 는 myget 피드 (ETA : 오늘)에서 온 전성 테스트를 수행 한 다음 여기에서 커뮤니티 (ETA : 오늘, EOD)에서 마지막 유효성 검사를 요청합니다. 해당 빌드에 대한 최종 유효성 검사가 완료되면 패키지를 NuGet으로 푸시합니다. 내 기대는 일주일도 채 걸리지 않을 것입니다.

우리는 왜 이것이 최선이고 유일한 해결책인지 Shiproom을 설득해야했기 때문에 진행과 의사 소통이 지연되었습니다.
또한 .NET Standard 2.0에서이 금지 외 패키지를 완전히 제공하지 않고 모든 기능을 기본 데스크톱 프레임 워크로 전달하기위한 계획 (배송 실 피드백 기반)을 준비하고 있습니다 (.NET Core 기능은 변경되지 않음). -즉, .NET Standard 2.0을 대상으로하는 경우 바인딩 리디렉션이 필요하지 않습니다. 모든 시나리오에 미치는 영향에 대한 세부 정보가 있으면이 스레드를 업데이트하겠습니다 (1 ~ 2 주 후).

이는 반가운 소식이며 netstandard2.0을 사용하기 쉽게 만들 것입니다.

@davidsh 가 릴리스 브랜치에서 4.3.1 패키지를 확인했습니다 (경고 : myget은 그에게 매우 느 렸습니다-5 분)
검증 단계는 다음과 같습니다.

MyGet 개발 피드에서 최신 패키지를 사용해보십시오. 당신은 System.Net.Http.dll 패키지의 최신 STABLE (안 시험판) 빌드를 사용하는 것이 좋습니다 - 4.3.1 :
https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Net.Http

명령 줄 도구 또는 Visual Studio를 사용하여 NuGet 패키지 소스 피드를 변경하여 개발 피드 패키지를 사용할 수 있습니다.

명령:

명령 줄 :
nuget.config에 다음을 추가합니다.요소:

<add key="myget.org dotnet-core" value="https://dotnet.myget.org/F/dotnet-core/api/v3/index.json" />

비주얼 스튜디오:
VS에서 도구-> 옵션-> Nuget 패키지 관리자-> 패키지 소스-> 추가, 소스에서 다음 URL을 사용합니다. https://dotnet.myget.org/F/dotnet-core/api/v3/index.json

두 경우 모두 MyGet 개발 피드를 목록의 첫 번째 피드로 나열해야합니다.

[편집하다]
구성 파일에서 4.1.1.0에 대한 바인딩 리디렉션을 예상합니다.

<dependentAssembly>
    <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-4.1.1.0" newVersion="4.1.1.0" />
</dependentAssembly>

다음 단계로 상위 게시물 '실행 계획'을 업데이트했습니다.

• 5.c ~ 7 개의 엔드 투 엔드 시나리오 (대부분)의 최종 / 마지막 검증-이전에 (또는 다른 사람) 도움을 준 사람들, 시나리오 간략한 설명을 확인한 후 회신 해 주시겠습니까? 감사! (거의 다 왔어)
  
  
  
  • cc : @ annemartijn0 @karelkrivanek @jahmai @pollax @MikeGoldsmith @chadwackerman @dluxfordhpf @onovotny
  
  
• 5.d myget.org에 패키지 게시

확인을 시도했지만 해당 패키지를 설치하는 동안 오류가 발생합니다.

유효성 검사를 할 때 새로운 프로젝트로 작업했습니다.

"바인딩 리디렉션 업데이트 실패"오류가 패키지 및 어셈블리 버전의 다운 그레이드 때문이라고 생각합니다. 현재 프로젝트는 [마스터] 브랜치의 패키지를 기반으로하는 것으로 보입니다. System.Net.Http.4.4. *는 [master] 분기의 패키지 번호입니다 (.NET Core 2.0 시험판의 일부). System.Net.Http의 어셈블리 버전은 4.2. *입니다.

System.Net.Http 버전 4.3.1 패키지는 STABLE (시험판이 아님) 패키지이며 .NET Core 1.1 서비스 분기 (.NET Core 1.1.1 서비스 릴리스와 호환 가능)에서 빌드됩니다. 어셈블리 버전이 다른 System.Net.Http dll의 바이너리가 포함되어 있습니다.

발견 한 버그는 Visual Studio / NuGet이 System.Net.Http의 변경된 어셈블리 버전에 대한 바인딩 리디렉션을 다시 작성하려고 할 때입니다.

따라서 새로운 솔루션 / 프로젝트를 만들 수 있습니다. 또는 바인딩 리디렉션을 삭제 한 다음 다시 넣으십시오.

참고로. 내 패키지 설치의 내 로그 :

Attempting to gather dependency information for package 'System.Net.Http.4.3.1' with respect to project 'Net46HttpTest3', targeting '.NETFramework,Version=v4.6.1'
Gathering dependency information took 4.27 min
Attempting to resolve dependencies for package 'System.Net.Http.4.3.1' with DependencyBehavior 'Lowest'
Resolving dependency information took 0 ms
Resolving actions to install package 'System.Net.Http.4.3.1'
Resolved actions to install package 'System.Net.Http.4.3.1'
Retrieving package 'System.Security.Cryptography.Encoding 4.3.0' from 'CoreFx Dev Feed'.
Retrieving package 'System.Security.Cryptography.Primitives 4.3.0' from 'CoreFx Dev Feed'.
Retrieving package 'System.Security.Cryptography.Algorithms 4.3.0' from 'CoreFx Dev Feed'.
Retrieving package 'System.Security.Cryptography.X509Certificates 4.3.0' from 'CoreFx Dev Feed'.
Retrieving package 'System.Net.Http 4.3.1' from 'CoreFx Dev Feed'.
  GET https://dotnet.myget.org/F/dotnet-core/api/v2/package/System.Net.Http/4.3.1
Adding package 'System.Security.Cryptography.Encoding.4.3.0' to folder 'c:\users\dshulman\documents\visual studio 2015\Projects\Net46HttpTest3\packages'
Added package 'System.Security.Cryptography.Encoding.4.3.0' to folder 'c:\users\dshulman\documents\visual studio 2015\Projects\Net46HttpTest3\packages'
  OK https://dotnet.myget.org/F/dotnet-core/api/v2/package/System.Net.Http/4.3.1 302ms
Installing System.Net.Http 4.3.1.
Added package 'System.Security.Cryptography.Encoding.4.3.0' to 'packages.config'
Successfully installed 'System.Security.Cryptography.Encoding 4.3.0' to Net46HttpTest3
Adding package 'System.Security.Cryptography.Primitives.4.3.0' to folder 'c:\users\dshulman\documents\visual studio 2015\Projects\Net46HttpTest3\packages'
Added package 'System.Security.Cryptography.Primitives.4.3.0' to folder 'c:\users\dshulman\documents\visual studio 2015\Projects\Net46HttpTest3\packages'
Added package 'System.Security.Cryptography.Primitives.4.3.0' to 'packages.config'
Successfully installed 'System.Security.Cryptography.Primitives 4.3.0' to Net46HttpTest3
Adding package 'System.Security.Cryptography.Algorithms.4.3.0' to folder 'c:\users\dshulman\documents\visual studio 2015\Projects\Net46HttpTest3\packages'
Added package 'System.Security.Cryptography.Algorithms.4.3.0' to folder 'c:\users\dshulman\documents\visual studio 2015\Projects\Net46HttpTest3\packages'
Added package 'System.Security.Cryptography.Algorithms.4.3.0' to 'packages.config'
Successfully installed 'System.Security.Cryptography.Algorithms 4.3.0' to Net46HttpTest3
Adding package 'System.Security.Cryptography.X509Certificates.4.3.0' to folder 'c:\users\dshulman\documents\visual studio 2015\Projects\Net46HttpTest3\packages'
Added package 'System.Security.Cryptography.X509Certificates.4.3.0' to folder 'c:\users\dshulman\documents\visual studio 2015\Projects\Net46HttpTest3\packages'
Added package 'System.Security.Cryptography.X509Certificates.4.3.0' to 'packages.config'
Successfully installed 'System.Security.Cryptography.X509Certificates 4.3.0' to Net46HttpTest3
Adding package 'System.Net.Http.4.3.1' to folder 'c:\users\dshulman\documents\visual studio 2015\Projects\Net46HttpTest3\packages'
Added package 'System.Net.Http.4.3.1' to folder 'c:\users\dshulman\documents\visual studio 2015\Projects\Net46HttpTest3\packages'
Added package 'System.Net.Http.4.3.1' to 'packages.config'
Successfully installed 'System.Net.Http 4.3.1' to Net46HttpTest3
Executing nuget actions took 2.41 sec
========== Finished ==========
Time Elapsed: 00:06:40.8451462

흠, 테스트 할 때 혼란 스럽습니다. 4.3.1로 업데이트하고 web.config에서 다음 바인딩 리디렉션을 얻었습니다.

<dependentAssembly>
    <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-4.1.1.0" newVersion="4.1.1.0" />
</dependentAssembly>

예상?
아마도 스레드의 초기에 뭔가를 놓쳤거나 이것은 혼란스러운 패키지 버전 대 dll 버전 미스 매치 상황 중 하나 일 수 있습니다.
또한 패키지를 제거하고 바인딩 리디렉션을 제거한 다음 다시 설치했는데 동일한 결과를 얻었습니다.

Works On My Machine ™ ️ 빌드 및 실행.

덧붙여서 나는 왜이 버전이 4.4에서 4.3.1로 떨어졌는지 잘 모르겠지만 괜찮습니다.

4.4 버전이 최신 버전이지만 아직 시험판이며 .NET Core 2.0의 일부로 배송 될 예정이므로 버전은 번호 매기기에서 제외되었습니다. @karelz 는 수정이 먼저 있었기 때문에 패키지를 먼저 테스트 해달라고 사람들에게 요청했습니다.

4.3. * 패키지는 RTM .NET Core 1.1을 기반으로합니다. 그리고 그 서비스 릴리스가있을 것입니다. 따라서 해당 코드베이스를 기반으로하는 업데이트 된 패키지는 System.Net.Http의 경우 4.3.1입니다 (.NET Core 1.0 패키지는 System.Net.Http의 경우 4.3.0 이었으므로).

아마도 스레드의 초기에 뭔가를 놓쳤거나 이것은 혼란스러운 패키지 버전 대 dll 버전 미스 매치 상황 중 하나 일 수 있습니다.

예, 이것은 혼란 스럽습니다. NuGet 패키지 버전은 바이너리의 .NET 어셈블리 버전과 동일하지 않습니다.

System.Net.Http 4.3.1 NuGet 패키지의 경우 4.1.1.0 어셈블리 버전이있는 System.Net.Http 바이너리가 포함되어 있습니다. 따라서 올바른 결과를 얻고 있습니다.

엔드 투 엔드 시나리오를 검증 해 주신 @pollax 에게 감사드립니다 (최상위 게시물 업데이트 됨).
nuget.org에서 최종 수정 사항으로 출시하기 전에 몇 가지 유효성 검사를 더 기다리고 있습니다.

지침에서 바인딩 리디렉션을 놓친 것에 대해 사과드립니다 (잠재적 인 GAC로 인해 어셈블리 버전이 자동으로 충돌한다는 것을 깨닫지 못했지만 의미가 있습니다).
또한 myget이 myget의 모든 패키지를 사용하도록 강요하는 것에 대해 사과드립니다. myget에서 단일 패키지를 가져 오는 단계가 있는지 내부적으로 확인하기 위해 내부적으로 연락을 취하고 있습니다. 적어도 향후 검증을 위해.

@davidsh 내가 OOF 인 동안 종단 간 유효성 검사를 조정 해 주시겠습니까? ~ 3 개의 유효성 검사가 완료되면 @leecow / @weshaggard 에게 nuget.org 에 패키지를 게시하도록 요청하십시오. 감사!

얘들 아,

주제에서 약간 벗어 났지만 여기서 팀에 한마디하고 싶었습니다. 이 문제는 매우 활발했고 반응은 때때로 적대적이었습니다. 적대감에도 불구하고 저는 여기의 개발팀이 수업과 함께 그것을 처리했다고 느낍니다.

지원 해주셔서 감사합니다. 실수가 발생합니다. 고쳐 주셔서 감사합니다. 시간이 걸린다는 것을 알고 있습니다.

새 버전이 문제를 해결한다는 또 다른 확인입니다.

KeyVault를 사용하여 4.3.1로 충돌하여 문제를 해결했습니다.

안녕하세요, SignalR에이 문제가 있습니다. 하지만 System.Net.Http 4.3.1은 어떻게 얻습니까? 나는 단지 4.3.0 in
https://www.nuget.org/packages/System.Net.Http/

아차, CoreFx에 대한 메시지를 놓친 - https://dotnet.myget.org/F/dotnet-core/api/v3/index.json

내 SignalR 문제를 해결합니다.

다른 사람들이 언급했듯이 피드는 매우 느립니다. 4.3.1이 일반 너겟 채널에 들어갈 가능성이 있습니까? 토요일 오후 1시 30 분, 워 ... (출발까지 8 분)

'.NETFramework, Version = v4.6'을 대상으로하는 'TranslateKumquat.Translate.Tests'프로젝트와 관련하여 'System.Net.Http.4.3.1'패키지에 대한 종속성 정보를 수집하려고합니다.
종속성 정보를 수집하는 데 5.85 분이 걸렸습니다.
DependencyBehavior 'Lowest'를 사용하여 'System.Net.Http.4.3.1'패키지에 대한 종속성을 해결하려고합니다.
기존 packages.config 파일에서 하나 이상의 해결되지 않은 패키지 종속성 제약 조건이 감지되었습니다. 패키지를 추가하거나 업데이트하려면 모든 종속성 제약 조건을 해결해야합니다. 이러한 패키지가 업데이트되는 경우이 메시지가 무시 될 수 있습니다. 그렇지 않으면 다음 오류가 현재 패키지 작업을 차단할 수 있습니다. 'System.Net.Http 4.3.0'
종속성 정보를 해결하는 데 0ms가 걸렸습니다.
'System.Net.Http.4.3.1'패키지 설치 조치 해결
'System.Net.Http.4.3.1'패키지 설치 조치 해결

'.NETFramework, Version = v4.6'을 대상으로하는 'DictKumquat.Dict.CE.Tests'프로젝트와 관련하여 'System.Net.Http.4.3.1'패키지에 대한 종속성 정보를 수집하려고합니다.
종속성 정보를 수집하는 데 3.84 분이 걸렸습니다.
DependencyBehavior 'Lowest'를 사용하여 'System.Net.Http.4.3.1'패키지에 대한 종속성을 해결하려고합니다.
기존 packages.config 파일에서 하나 이상의 해결되지 않은 패키지 종속성 제약 조건이 감지되었습니다. 패키지를 추가하거나 업데이트하려면 모든 종속성 제약 조건을 해결해야합니다. 이러한 패키지가 업데이트되는 경우이 메시지가 무시 될 수 있습니다. 그렇지 않으면 다음 오류가 현재 패키지 작업을 차단할 수 있습니다. 'System.Net.Http 4.3.0'
종속성 정보를 해결하는 데 0ms가 걸렸습니다.
'System.Net.Http.4.3.1'패키지 설치 조치 해결
'System.Net.Http.4.3.1'패키지 설치 조치 해결

@karelz Azure Storage API 시나리오가 MyGet의 4.3.1 버전으로 재 검증되었습니다.

더 빨리 응답하지 않아서 죄송합니다.

@tofutim 종속성을 수집 이유로 인해 유선으로가는 메타 데이터를 많이 느립니다 - https://github.com/NuGet/Home/issues/4448

나는 그것을 생각했다. nuget.org로 가져 오기위한 ETA가 있습니까?

@davidsh 안녕하세요 David, 이번 주 4.3.1이 너겟으로 만들까요? 나는 상당히 복잡한 프로젝트를 가지고 있으며 대기 시간이 프로젝트의 패키지 수에 따라 확장되어야하는 것처럼 느껴집니다. 그래도 고치는 것이없는 것보다 낫습니다. nupkg를 어딘가에 복사 할 수 있다고 생각합니다.

'.NETFramework, Version = v4.6'을 대상으로하는 'qi'프로젝트와 관련하여 'Kumquat.Translate.8.6.2'패키지에 대한 종속성 정보를 수집하려고합니다.
종속성 정보를 수집하는 데 8.76 분이 소요되었습니다.

최근 8.76 분

@davidsh 이것은 OwlMQ 메일 링리스트에 방금 나타났습니다. 업데이트 된 패키지로 문제가 해결되었다고보고 할 수 있습니다.

앞서가는 팀에게 감사드립니다. 멋진 일!

패키지의 모든 유효성 검사에 감사드립니다.

System.Net.Http 4.3.1 패키지가 NuGet.org로 승격되었습니다.

https://www.nuget.org/packages/System.Net.Http/4.3.1

흠, 매우 기괴함-RavenDB 클라이언트가 이제 4.1.1 어셈블리를 찾을 수 없다고 불평합니다.

편집 :주의 사항-Acme.Core는 RavenDB.Client를 참조하고 Acme.Main은 Acme.Core를 참조합니다. VS2015는 System.Net.Http를 종속성으로 복사하지 않지만 바인딩 리디렉션이 있습니다-> 붐. 예상되는 동작입니까? 물론 간단하게 고칠 수 있습니다 ...

해결 된대로 문제를 종결합니다. 여기서 작업 해 주신 @davidsh 와 @CIPop 에게 감사드립니다!
인내심에 감사드립니다. 지연에 대해 사과드립니다. 다음 단계 : 사후 분석 (약속대로)-여기 주변의 모든 역사적 세부 정보를 확인하려면 2 주 정도 기다려주세요.

@georgiosd 새 문제를 제출하고 재현을 제공 할 수 있습니까? (이상적으로는 새 프로젝트로 시작)

@karelz 감사합니다!

참고 :

• 확인 된 시나리오 목록 (미래에 필요할 경우를 대비하여)과 패키지 링크로 최상위 게시물을 업데이트했습니다.
• 앞으로는 전체 피드 대신 myget의 특정 패키지 만 사용하여 모든 것을 최신으로 가져 오는 문제 (및 속도 저하 문제)를 해결하는 단계를 살펴볼 계획입니다. 곧 필요하지 않기를 바랍니다.

@karelz 빠른 질문 : 사후 분석이 완료되면 어디에서 정보를 찾을 수 있습니까? 이 스레드에서 _or_ 다른 스레드 / 장소?

@PureKrome 나는 확실히이 스레드를 업데이트 할 것입니다-이미 관심있는 모든 사람들이 알림을받는 것이 더 쉽습니다. 또한 내 목표는 사후 분석을 경시하지 않고 사람들에게 숨기지 않는 것입니다.
나는 토론에 대한 새로운 문제를 만들 것입니다 (예상대로) ;-).
높은 수준에서 다음을 다룰 계획입니다.

1. 문제가 어떻게 출시 되었습니까? 앞으로 이러한 상황을 어떻게 방지 할 수 있습니까?
2. 수정하는 데 6 개월이 걸린 이유는 무엇입니까? 왜 이전에는 영향력이 큰 문제로 취급 / 전달되지 않았습니까? 미래에 영향이 큰 문제를 조기에 인식하고 대응하는 방법은 무엇입니까?
3. 기타 문제 (예 : 전반적인 의사 소통)

또한 4.3.1에서 문제가 발생하거나 제대로 작동하지 않는 것을 발견하면 (예 : @georgiosd 's find above ), 여기에서 인식을 위해 언급해야하지만,보다 쉬운 토론 / 후속 조치를 위해 세부 사항을 별도의 문제로 작성해야합니다.

@karelz (및 MS 팀)에게 감사합니다. 이 스레드를 계속 구독하겠습니다. 👍

좋은 싸움을 계속하십시오, 팀! 💯

나는 또한 @ chadwackerman2 에게 감사해야한다

.NET 역사상 가장 성가신 버그 중 하나를 해결 한 것에 대해 다시 한 번 축하드립니다. :)

@karelz 그렇게

@georgiosd 모르겠어요-별도의 문제에서 논의하는 것이 더 쉬울 것입니다 ;-) (올바른 전문가

이 작업을 도와 주셔서 감사합니다, @karelz

제가 사후 부검에 늦었다는 것을 알고 있습니다. 죄송합니다.
나는 잊지 않았다, 나는 더 높은 우선 순위로 인해 아직 도달하지 못했다.
앞으로 1-2 주 안에 사후 부검을 끝내기 위해 열심히 노력하겠습니다.

안녕하세요,이 문제를 해결하는 데 모두 참여했습니다. Cant는 내가 모든 너트와 볼트를 이해한다고 말할 수 있지만 여전히 이해하지 못하는 것은 솔루션을 VS 2015 Update 3에서 VS 2017로 업그레이드했을 때만 발생하는 이유입니다. 문제의 솔루션은 ASP.Net Core 프로젝트를 대상으로하는 세트였습니다. .net 프레임 워크 4.6. Azure KeyVaultClient를 사용하여 문제가 발생했습니다.

고마워, Donal

안녕하세요 @karelz , 저는 지금까지 이틀 연속 연구하고 작업했지만이 문제를 해결할 수 없습니다. 모든 System.Net.Http 패키지가 버전 4.3.1로 업데이트되었지만 여전히 동일한 오류가 발생합니다. 제발 도와주세요, 나는 다른 무엇을 시도하거나 어디로 가야할지 모르겠습니다. 감사!

FileNotFoundException : 파일 또는 어셈블리 'System.Net.Http, 버전 = 4.1.1.0, Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a'를로드 할 수 없습니다. 시스템이 지정된 파일을 찾을 수 없습니다.

여기 내 .csproj

netcoreapp1.1

$ (PackageTargetFallback); portable-net45 + win8 + wp8 + wpa81;

aspnet-IbmVcaCore-5aa05652-04e7-4a42-9fd6-8dbc1c8b98fe

@parismiguel :(. 앱에 4.0.0.0에서 4.1.1.0으로 bindingRedirects가 있습니까?

<dependentAssembly> 
    <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" /> 
    <bindingRedirect oldVersion="0.0.0.0-4.1.1.0" newVersion="4.1.1.0" /> 
</dependentAssembly> 

bindingRedirects 스토리를 더 원활하게 만드는 방법을 찾고 있습니다. https://github.com/dotnet/corefx/issues/9846#issuecomment -287941109

업데이트 : 오류를 살펴보면 문제는 4.1.1.0 버전을 찾을 수 없다는 것입니다. 올바른 어셈블리 버전이 실제로 있는지 앱 디렉터리를 확인할 수 있습니까?

빠른 @karelz , 대단히 감사합니다! 이전 게시물에서 bindingRedirects 항목을 보았지만 어디에 배치해야할지 모르겠습니다 ... .csproj 내부에서 시도했지만 버전 4.1.1.0과 관련하여 오류 (.txt로 첨부)가 있습니다. m 잘 모르겠어요 ... 4.3.1로 업그레이드하면 안 되나요?

IbmVcaCore.csproj.txt

바인딩 리디렉션은 app.config 또는 web.config 파일로 이동합니다.

자세한 내용은 다음을 참조하십시오.
https://msdn.microsoft.com/en-us/library/7wd6ex19 (v = vs.110) .aspx

안녕하세요 @davidsh , 도와 주셔서 감사합니다!
내 프로젝트에 해당 파일이 없습니다. Visul Studio 2017 템플릿을 사용하는 NET Core 프로젝트 빌드입니다. 제가 무엇을 놓치고 있습니까?

Re : 4.3.1 vs. 4.1.1-4.3.1은 NuGet 패키지 버전, 4.1.1.0은 어셈블리 버전입니다 (ildasm / ILSpy / VS가 표시합니다).
NuGet 버전과 어셈블리 버전은 약간 혼란스럽고 어느 버전에 속하는지 연결하기가 어렵습니다. 문서 (예 : NuGet 페이지)를 통해 점을 연결할 수있는 경우 더 자세히 살펴볼 사항 목록에 있습니다.

.NET Core를 사용하는 경우 bindingRedirects가 필요하지 않으며이 문제는 전혀 영향을 미치지 않습니다. 이 문제는 데스크톱 (= .NET Framework)에만 해당됩니다.
4.3.1 NuGet 패키지는 .NET Core 어셈블리가 아닌 데스크톱 어셈블리 만 수정했습니다.

그래도 문제가 있으면 새 버그를 신고하고 저를 태그 해주세요. 이 문제는 상당히 많은 사람들에게 퍼져 나가고 있습니다 (충격적 이었기 때문에), 귀하의 문제는 그것과 관련이 없습니다 (적어도 그렇게 보임). 모든 사람의 GH 알림 /받은 편지함에 친절하게 대합시다.

모두에게 : 저는 제가 약속 한 사후 분석을 추적하기 위해 새로운 이슈 dotnet / corefx # 17522를 만들었습니다.
슬프게도 아직 그다지 진전을 이루지 못했습니다 :( ... 적어도 관심있는 모든 사람은이 문제를 따르고이 문제에 대한 잠재적 인 소음을 피할 수 있습니다 (사람들이 관심있는 것에 집중하도록 돕습니다).

@karelz 감사합니다. 귀하의 지침에 따라 귀하의 새로운 문제 추적기에 게시하겠습니다. 문안 인사.

@parismiguel이 내가 만든 새로운 문제가 아니라 새로운 문제를 만드십시오. 내가 만든 것 (# 17522)은이 문제 (# 11100)를 해결하는 데 오랜 시간이 걸린 사후 분석을위한 것입니다.

@karelz 에게 감사

나는 완벽한 폭풍을 통해 이것을 만난 것 같습니다.

Azure Key Vault (2.0.6) 및 Octopus Client (4.15.3)의 조합과 함께 Azure Functions 미리보기를 사용하고 있습니다.

System.Net.Http 에서 4.3.2 업그레이드를 시도했지만 Key Vault 를) 사용하려고하면 여전히 실패합니다.

팁이 있습니까?

뿡뿡

4.3.2 너겟 패키지의 어셈블리가 실제로 런타임에 사용되는지 확인해 주시겠습니까? (4.3.1에서 수정 됨)