938

.NET Standard 2.0을 지원한다는 것은 다음 플랫폼을 모두 지원한다는 의미

• .NET 프레임워크 4.6.1
• .NET 코어 2.0
• 모노 5.4
• 자마린.iOS 10.14
• 자마린.맥 3.8
• 자마린.안드로이드 7.5
• UWP vNext(올해 말 출시)

이전 버전과의 호환성 shim을 사용하여 RestSharp를 실행할 때 대부분 작동합니다. HTTP 호출을 호출하는 데 사용되는 기본 클래스에 문제가 있을 뿐입니다. HTTP 클라이언트가 새 HttpClient 로 전환된 경우 작동해야 합니다.

개인적으로 여기 사무실에서 RestSharp를 꽤 많이 사용하고 있으며 이미 ASP.NET Core를 사용하여 실행되는 새로운 클라우드 기반 솔루션을 작업 중이므로 RestSharp가 최신 .NET으로 업데이트되는 것을 보고 싶습니다. 새로운 REST 라이브러리로 전환할 필요가 없도록 버전을 변경합니다.

@qJake .NET Standard 2.0에는 API 표면이 크게 확장되어 있으므로 HttpClient로 전환하는 대신 HttpWebRequest를 유지할 수 있습니다. 심을 사용하여 경험한 문제가 더 이상 존재하지 않을 수 있습니까?

왜 .NET Standard 2.0인가? 사용 가능한 가장 낮은 버전을 대상으로 하는 것을 고려하십시오.

@mguinness @dotnet/corefx 프로젝트에서 이 주석 을 참조하십시오 - HttpWebRequest 는 .NET Standard의 일부가 아니지만 System.Net.Http.HttpClient 는 .NET Standard의 일부입니다.

UWP 현재 버전도 지원하는 것을 고려하십시오. (Fall Creators 업데이트 이전)

UWP 현재 버전은 netstandard1.4를 의미합니다. 이것이 어떤 결과를 가져올지 잘 모르겠습니다. 실험을 시작해야 합니다.

@qJake Well HttpWebRequest 는 .NET Standard 2.0에 있으며, 귀하의 어설션은 .NET Standard 1.6 이하에만 해당됩니다.

@mguinness 오, HttpClient 전환합니까?

사람들은 현재 버전의 UWP 문제로 인해 1.4를 원합니다. NETStandard 2.0은 UWP vNext에서만 지원됩니다.

@qJake FWIW, 이전 버전의 .NET Standard에서 사용할 수 있는 System.Net.Requests nuget 패키지도 있습니다.

얘들아, 이것에 대한 업데이트 또는 ETA가 있습니까? 내 dotnet core 2 앱에서 RestSharp를 사용할 계획이며 패키지를 전환하고 싶지 않습니다.

진행중인 작업입니다. 레거시 항목이 제거되었지만 JSON.NET도 릴리스에 함께 가져올 것입니다. 계속 지켜봐 주세요.

WIP: https://github.com/alexeyzimarev/restsharp/tree/netstandard

AWS Lambda에 사용해야 하는데 RestSharp.NetCore 105.2.3을 사용할 때 AWS 반환 오류
-- 감지된 패키지 다운그레이드: 4.3.0-preview1-24530-04에서 4.1.0으로 System.Reflection.

RestSharp는 4.1을 사용하지만 AWS는 .NetCoreApp 1.0에 대해 4.3 버전 세트를 지원합니다.

System.Runtime.Serialization.Primitives.4.3.0-preview1-24530-04에 종속된 버전입니까?

우리는 .net 코어로 이동하고 있으며 .net 표준 2.0에서 RestSharp를 참조할 수 없다는 것을 발견했습니다. nuget 패키지 설치에 실패했습니다.

패키지 'RestSharpSigned 105.2.3'은 프로젝트 대상 프레임워크 '.NETStandard,Version=v2.0' 대신 '.NETFramework,Version=v4.6.1'을 사용하여 복원되었습니다. 이 패키지는 프로젝트와 완전히 호환되지 않을 수 있습니다.
패키지 복원에 실패했습니다. 에 대한 패키지 변경 롤백

@trampster 상태를 잘못 이해하고 있는 것

이해합니다. 수요가 있음을 알리기 위해 게시한 것입니다. 또한 .net 표준 2.0을 릴리스할 때 Microsoft에서 발표한 .net 표준 2.0의 .net 전체 dll을 참조하기 위한 .NET Framework 호환성 모드가 여기에서 작동하지 않음을 보여줍니다. 따라서 해결 방법이 없습니다. 차단됩니다.

우리는 다른 Rest 라이브러리로 이동할 필요가 없는 것을 선호하지만 필요하다면 그렇게 할 것입니다. 이 변환에 걸리는 시간에 따라 달라집니다.

흥미롭게도 nuget https://www.nuget.org/packages/RestSharp.NetCore 에 98,895 다운로드가 있는 RestSharp.NetCore 패키지가 있습니다. 내가 그것을 믿을 수 있다면.

@trampster 이는 억제될 수 있는 nuget 경고입니다. 기존 .NET Framework 라이브러리 재사용을 참조하세요. 또한 csproj의 대상 프레임워크는 무엇입니까? netcoreapp2.0 또는 v4.6.1입니까?

마지막 줄을 다시 살펴보십시오. 롤백했습니다. 그 후 나는 RestSharp에 대한 언급이 없습니다.

또한 내 게시물을 읽으면 netcore2.0 또는 v4.6.1이 아닌 .net 표준 2.0에서 사용하려고 한다는 것을 알 수 있습니다.

또한 경고에는 v4.6.1이 사용되었지만 RestSharp nuget 패키지에는 v4.6.1이 없다는 점에 유의해야 합니다.

@trampster 호환성 브리지를 사용하여 .NET Core 2.0 앱에 성공적으로 설치했지만 실행하려고 하면 HttpWebRequest 사용으로 요약되는 런타임 예외가 발생합니다. NuGet 패키지 설치 오류가 발생하지 않았으므로 이상합니다. 😃

나는 또한 이것을 실행하고 있습니다 :\ @alexeyzimarev 커뮤니티가 어떻게 도움을 줄 수

.NET Core 앱에서 현재 nuget 패키지 를 사용하는 것은 전체 프레임워크를 대상으로 하는 경우에만 가능합니다.

새 .NET Core 콘솔 앱을 만들고 패키지 관리자에서 Install-Package RestSharp -Version 105.2.3 를 실행하고 다음 코드를 Main에 추가했습니다.

```C#
var 클라이언트 = 새로운 RestClient();
client.BaseUrl = 새로운 Uri("https://api.github.com/");

var 요청 = 새로운 RestRequest();
request.Resource = "사용자/restsharp/리포지토리";

var 응답 = client.Execute(요청);
```

netcoreapp2.0을 타겟팅하면 System.PlatformNotSupportedException: Operation is not supported on this platform. 되지만 csproj에서 <TargetFramework>net46</TargetFramework> 로 변경하면 작동합니다.

우리는 전체 프레임워크를 대상으로 하지 않습니다

@niemyjski 이 라이브러리가 업데이트될 때까지 기다리는 동안 RestSharp.NetCore 를 사용해 보세요. 다음 라이브러리에서 사용 중이므로 사용하기에 충분히 안정적이어야 합니다.

ADH.푸시코어
앱베이어샤프
CoreLib.Web
카우치DB.클라이언트
DocuSign.NetCore
Flip.PomboCorreio.Connector
FluentEmail.Mailgun
GiphyApiClient.NetCore
인터콤.코어
IronSphere.Henchmen
MasterCard-Core-비공식
엠뱅크닷넷
MessageMedia.REST.API.NetCore
미니오.넷코어
MiX.Integrate.Api.클라이언트
OdinSdk.BaseLib.Core
OneSignal.AspNet.Core.SDK
OneSignal.CSharp.SDK.Core
Onlinesites.ShopFacilBradesco
pusher-http-dotnet-core
RepositoryFramework.Api
RepositoryFramework.EntityFramework
RestSharp.Newtonsoft.Json
RestSharp.Newtonsoft.Json.NetCore
Slack.Webhooks.Core
StoneCo.PomboCorreio.Connector
SwitchAPI.커넥터
Syncromatics.Clients.Metro.Api
TransportApi.Sdk.NetCore
Twilio.NetCore
UtilityFramework.Application.Core
UtilityFramework.Services.Iugu.Core

RestSharp.NetCore의 업로더가 누구인지 아는 사람이 있습니까? 나는 거기 github를 보았고 RestSharp의 포크가 없습니다. 패키지에 라이센스가 나열되어 있지 않습니다. 제가 알기로는 악성 코드입니다.

이 프로젝트를 소유한 사람은 restsharp 패키지 네임스페이스의 소유권을 찾아야 하며... 아마도 해당 패키지를 삭제해야 합니다. 패키지를 디컴파일하여 악성 콘텐츠가 포함되어 있는지 확인할 수 있습니다.

2017년 10월 5일 오후 10시 57분,

@niemyjski (https://github.com/niemyjski) 이 라이브러리가 업데이트될 때까지 기다리는 동안 RestSharp.NetCore(https://www.nuget.org/packages/RestSharp.NetCore/)를 사용해 보세요. 다음 라이브러리에서 사용 중이므로 사용하기에 충분히 안정적이어야 합니다.

ADH.푸시코어
앱베이어샤프
CoreLib.Web
카우치DB.클라이언트
DocuSign.NetCore
Flip.PomboCorreio.Connector
FluentEmail.Mailgun
GiphyApiClient.NetCore
인터콤.코어
IronSphere.Henchmen
MasterCard-Core-비공식
엠뱅크닷넷
MessageMedia.REST.API.NetCore
미니오.넷코어
MiX.Integrate.Api.클라이언트
OdinSdk.BaseLib.Core
OneSignal.AspNet.Core.SDK
OneSignal.CSharp.SDK.Core
Onlinesites.ShopFacilBradesco
pusher-http-dotnet-core
RepositoryFramework.Api
RepositoryFramework.EntityFramework
RestSharp.Newtonsoft.Json
RestSharp.Newtonsoft.Json.NetCore
Slack.Webhooks.Core
StoneCo.PomboCorreio.Connector
SwitchAPI.커넥터
Syncromatics.Clients.Metro.Api
TransportApi.Sdk.NetCore
Twilio.NetCore
UtilityFramework.Application.Core
UtilityFramework.Services.Iugu.Core

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하거나 GitHub(https://github.com/restsharp/RestSharp/issues/992#issuecomment-334651808)에서 확인하거나 스레드를 음소거(https://github.com/notifications/unsubscribe-auth)하세요. /AA-So9HrYQHV5nlV1m7W7eY-y_F5cBqqks5spaUXgaJpZM4PLH2m).

@alexeyzimarev 오늘 프리릴리즈 nuget 패키지를 얻을 기회가 있습니까? 베타 버전이고 모든 테스트가 작동하더라도 일부 다른 사항이 변경될 수 있습니다.

슬픈 RESTsharp는 Core 2.0에서 작동하지 않습니다. HttpClient로 돌아갔다고 가정합니다.

@niemyjski 아니요, 죄송합니다. WebRequest를 HttpClient로 변경하고 있는데 이것은 큰 변화입니다. 그 이유는 WebRequest가 netstandard 2.0에서만 사용할 수 있고 1.6을 지원하기를 원하기 때문입니다.

@niemyjski 도움이 필요하면 변경 사항을 별도의 분기에 게시할 수 있습니다.

이제 실제로 netstandard 2.0으로 전환했습니다. netstandard 1.6은 너무 많은 작업을 수행하는 것 같습니다. 하지만 여전히 HttpClient를 사용하고 싶습니다.

이것을 확인하십시오: https://github.com/restsharp/RestSharp/tree/netstandard
홍보 환영합니다.

@amivit 당신은 그것을 실현하기 위해 당신의 시간을 기여할 수 있습니다, 그렇죠?

WebRequest를 HttpClient로 변경하고 있는데 이것은 큰 변화입니다. 그 이유는 WebRequest가 netstandard 2.0에서만 사용할 수 있고 1.6을 지원하기를 원하기 때문입니다.

System.Net.Requests nuget 패키지가 있으므로 잘못된 설명입니다.

처음에는 WebRequest를 고수하고 시간이 지나면서 HttpClient로 전환하는 것이 어렵습니까?

@mguinness 이 패키지를 사용해 보셨습니까? 나는 했다.

@mguinness 우리는 말할 수 있습니다 - 1.6은 잊어버리고 2.0으로 가고 WebRequest를 유지합니다. 저는 개인적으로 괜찮습니다.

@alexeyzimarev 죄송합니다. 기여할 시간이 없습니다. 나는 원한다. RESTsharp가 처음부터 HttpClient에 의존하지 않는다는 사실에 놀랐습니다. 2012년부터 WebClient 또는 .NET 4.5에 비해 개선된 기능이 없었습니까?

@amivit 아마 고장나지 않았다면 고치지 마세요.

미미미만 해서 죄송합니다 :rofl:
그러나 내 클라이언트 응용 프로그램을 .net core 2.0으로 업그레이드한 후 RestSharp에 대한 몇 가지 경고가 표시됩니다.

경고 NU1603: RestSharp.NetCore 105.2.3은 System.Runtime.Serialization.Formatters(>= 4.0.0-rc4-24217-03)에 의존하지만 System.Runtime.Serialization.Formatters 4.0.0-rc4-24217-03은 그렇지 않습니다. 설립하다. System.Runtime.Serialization.Formatters 4.3.0-preview1-24530-04의 대략적인 최상의 일치가 해결되었습니다.

지금은 응용 프로그램을 실행하려고 하지 않았습니다. 작동하지 않을 것 같습니다.
따라서 RestSharp는 아직 .net core 2.0을 지원하지 않습니다. 하지만, 언젠가는 될까요? 날짜가 이미 있습니까? (기고자로서) 이 일을 할 수 있도록 도와드릴까요?

@matthiasburger 는 netstandard 분기를 확인합니다. 귀하의 댓글 위에 몇 개의 게시물만 언급했습니다.

지금은 2.0으로 가십시오. 나중에 항상 http 클라이언트로 변경할 수 있습니다 ... 또한
동기화 방법을 갖도록 컴파일러 지시문이 있는지 확인하십시오.
(뼈대)

감사 해요
-블레이크 니에미스키

2017년 10월 11일 수요일 오전 6:43 Alexey Zimarev [email protected]
썼다:

@matthiasburger https://github.com/matthiasburger netstandard 확인
나뭇 가지.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/restsharp/RestSharp/issues/992#issuecomment-335782906 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AA-So8akA6MlKfoypWDSAqaElcYBPoAks5srKnUgaJpZM4PLH2m
.

sry @alexeyzimarev 때로는 모든 것을 읽어야 합니다. 살펴봅니다 :)

@niemyjski 모든 pragma 지시문이 제거되었습니다. 플랫폼, 프레임워크 등마다 편차가 있는 것을 원하지 않습니다. 이것이 netstandard가 해결하기 위해 선언한 것이며 저는 그것을 사용할 것입니다.

자, 이제 netstandard 분기가 서명된 것과 서명되지 않은 모두에 대해 빌드됩니다. 여전히 실패한 네 가지 테스트(인코딩, 디코딩)가 있습니다. 통합 테스트는 아직 포함되지 않았습니다. 이번 주에 코드를 완료할 수 있기를 바랍니다. 하지만 빌드 및 팩을 DotNetCli로 전환하려면 더 많은 작업이 필요합니다.

알겠습니다. 모두 작동하는 것 같습니다. HttpListener(통합)에서 지원되지 않는 예외로 인해 두 가지 테스트를 조건부로 무시해야 했습니다. 적절한 서버와 함께 사용할 때 작동할 것으로 예상하십시오.

이제 DotNetCli를 사용하고 nuget.exe 사용을 중지하도록 빌드 스크립트를 변경해야 합니다.

멋진 일을 계속하십시오 @alexeyzimarev! 첫 발매가 너무 기대됩니다👍

https://www.nuget.org/packages/RestSharp/106.0.0-alpha0277을 테스트

VS2017 및 .NET Core 2.0을 대상으로 하는 실제 IIS에서 테스트된 106.0.0-alpha0277

ErrorException: System.PlatformNotSupportedException: 이 플랫폼에서는 작업이 지원되지 않습니다.
System.Net.SystemWebProxy.GetProxy(Uri 대상)에서
System.Net.ServicePointManager.ProxyAddressIfNecessary(Uri& 주소, IWebProxy 프록시)에서
System.Net.ServicePointManager.FindServicePoint에서(Uri 주소, IWebProxy 프록시)
System.Net.HttpWebRequest.get_ServicePoint()에서
RestSharp.Http.ConfigureWebRequest(문자열 메서드, Uri URL)
RestSharp.Http.PostPutInternal(String 메서드)에서
RestSharp.Http.AsPost에서(문자열 httpMethod)
RestSharp.RestClient.DoExecuteAsPost(IHttp http, String 메서드)에서
RestSharp.RestClient.Execute(IRestRequest 요청, 문자열 httpMethod, Func`3 getResponse)에서

나는 그들이 초과 시간에 많은 IsXYZ 메서드를 추가했다는 것을 알고 있습니다. 아마도 이러한 메서드를 호출하거나 래핑하기 전에 해당 메서드를 확인해야 합니까?

Windows에서보다 훨씬 더 많은 문제를 찾을 수 있다고 생각하므로 Linux에서 이러한 테스트를 실행하는 것이 좋습니다.

@ maciek12305 예외를 복사하여 붙여넣는 것만으로는 충분하지 않습니다. 어떻게 해서 거기에 도달했는지 알 수 없기 때문입니다.

@niemyjski Linux에서 테스트를 실행하는 데 동의하지만 새 CI 빌드를 설정해야 합니다. 나는 다음 주에 잘하면 나중에 Travis를 볼 것입니다.

프록시 https://github.com/Azure/azure-iot-sdk-csharp/issues/140에 문제가 있는 것 같습니다.

좋습니다. 문제는 기본 프록시에 대한 설정이 레지스트리에서 로드되기 때문에 .NET Core가 기본 프록시를 지원하지 않는다는 것입니다.

따라서 프록시를 사용하지 않으면 작동해야 하며 프록시를 사용하는 경우 .NET Core에서 충돌합니다. 지금은 모든 것을 우회하고 직접 이동하는 "기본 프록시" 클래스를 추가했습니다. 프록시를 사용해야 하는 경우 ConfigureProxy 메서드를 사용하여 제공해야 합니다.

최신 패키지를 사용해 보십시오: https://www.nuget.org/packages/RestSharp/106.0.0-alpha0281

@niemyjski 실제로 통합 테스트는 Mac에서 잘 통과합니다. 따라서 Linux에서도 작동해야 합니다.

@alexeyzimarev 최신 패키지는 Win 10에서 작동하지 않았습니다. 작동하게 하는 유일한 방법은 코드에 다음을 포함하는 것이었습니다.

C# //https://github.com/dotnet/corefx/commit/6acd74dda7bc4f585d2c4006da4a8b2deb0261ad var proxy = WebRequest.DefaultWebProxy; WebRequest.DefaultWebProxy = null;

@mguinness 그래서 proxy 변수에 이전 값(무엇인지 확실하지 않음)을 유지하는 이유는 무엇입니까? 차이를 만들 수 있는 유일한 라인은

WebRequest.DefaultWebProxy = null;

도움이 된다면 쉽게 추가할 수 있습니다.

@alexeyzimarev "WebRequest.DefaultWebProxy: Set가 이전 Get 없이는 작동하지 않습니다" 수정 사항을 커밋하는 프레임워크에 버그가 있었습니다.

지금은 이해. 기본 속성을 조작하는 대신 요청 프록시 속성을 null로 설정하여 패키지를 만들 수 있습니다.

@mguinness 새로운 패키지가 출시되었습니다. 도와주셔서 감사합니다!

@mavanmanen UWP로 이것도 시도해 볼 수 있습니까? https://www.nuget.org/packages/RestSharp/106.0.0-alpha0282

버전 106.0.0-alpha0282에서 "이 플랫폼에서는 작업이 지원되지 않습니다."라는 동일한 오류가 발생합니다.

@remiskaune 코드에 이 줄을 포함시키려고 시도했습니까?

var proxy = WebRequest.DefaultWebProxy;
WebRequest.DefaultWebProxy = null;

감사 해요. 이제 버전 106.0.0-alpha0282의 이 줄에서 작동합니다.

그래서 질문은 내가 RestSharp 코드에 이 줄을 포함했기 때문에 이것이 없으면 작동하지 않는 이유입니다...

아마도 WebRequest에 다른 범위가 있습니까? 정적 클래스입니까 아니면 인스턴스입니까?

샘플 앱을 만들고 샘플 앱에서 다음을 확인하여 알 수 있습니다.

WebRequest.DefaultWebProxy

또한 RestSharp가 (디버깅 목적으로) 보고 있는 값을 보낼 수 있는 몇 가지 방법을 노출합니다. 예:

public IWebProxy GetCurrentProxy() => WebRequest.DefaultWebProxy;

둘이 다른지 보이시죠?

@qJake 누군가 나를 위해 디버깅할 수 있다면 감사하겠습니다 :) 다음 주까지 이 문제에 대해 시간을 할애할 수 없으며 컨퍼런스에서 연설할 예정입니다.

WebRequest.DefaultProxy 를 null에 할당하여 프록시 문제가 "수정된" 경우 새 패키지를 사용할 수 있습니다. 이것은 결과를 초래할 수 있지만 실제 문제는 기대하지 않습니다. 해결 방법은 .NET Standard 어셈블리에만 추가됩니다. .NET Framework 어셈블리는 이전과 같이 작동해야 합니다.
https://www.nuget.org/packages/RestSharp/106.0.0-alpha0284

보고된 문제가 없으면 릴리스 준비를 시작하겠습니다.

상당히 긍정적인 반응입니다. 나는 종속 패키지(Atlassian.JIRA)가 작동하도록 하려고 놀고 있었고 .NET 표준 2.0을 대상으로 했다고 가정하면 모든 통합/단위 테스트가 "그냥 작동"하여 LGTM이 되었습니다.

해당 끝 스레드에 대한 https://bitbucket.org/farmas/atlassian.net-sdk/issues/306/support-for-dotnet-core .

우리 솔루션에 대해 테스트했으며 잘 작동합니다.

.net 표준 2.0 프로젝트 및 .net 4.6.1 프로젝트에서 사용하고 있습니다.

.net에서 사용하는 경우 4.6.1. Visual Studio가 노란색 느낌표로 표시하는 다음 참조를 프로젝트에서 가져옵니다.
시스템.넷.Http
System.Runtime.Serialization.Primitives
System.Security.Cryptography.Algorithms
System.Security.Cryptography.Encoding
System.Security.Cryptography.Primitives
System.Security.Cryptography.X509인증서

이것이 왜 그런지는 모르겠지만 문제를 일으키지 않는 것 같습니다.

우리가 가지고 있는 한 가지 사소한 문제는 clickonce를 사용하여 도구 중 하나를 배포하므로 모든 항목에 강력한 이름을 지정해야 한다는 것입니다. 그러나 시험판 버전은 강력한 이름이 아닙니다. 패키지의 RestSharpSigned 버전을 사용하고 있지만 .net 표준을 지원하는 시험판 버전은 없습니다.

강력한 명명된 버전과 강력하지 않은 명명된 버전을 갖는 것은 강력한 명명된 버전에 의존하는 종속성과 강력하지 않은 명명된 버전에 의존하는 두 가지 종속성이 있는 상황에서 문제가 될 수 있습니다.

이 대신 어셈블리 버전의 주요 버전(SemVer에서 주요 버전은 호환성을 깨뜨릴 때만 변경됨)에 서명하고 고정한 다음 FileVersion에서 전체 SemVer를 사용하는 것이 좋습니다. 이렇게 하면 모든 사람이 사용할 수 있는 하나의 너겟 패키지(강력한 이름이든 아니든)를 갖게 되며 주 버전 고정은 바인딩 리디렉션이 필요하지 않음을 의미합니다. 그리고 SemVer를 사용한다는 것은 모든 사람이 호환성 측면에서 자신의 위치를 ​​정확히 알고 있음을 의미합니다.

.net 표준으로 전환하는 것이 이 변경을 수행하기에 좋은 시기일 수 있기 때문에 여기에서 제안합니다.

기본적으로 패키지에 서명하고 키를 GitHub에 넣어야 합니다. .net 팀은 아무 것도 해치지 않기 때문에 이것을 권장합니다.

변경 사항을 볼 수 있는 PR이 있습니까?

@niemyjski develop 분기가 모두에게 표시된다고 가정합니다. 기본 브랜치로도 만들었습니다.

@niemyjski "Just"는 이 경우에 작동하지 않습니다. 당신이 돕고 싶다면 - 도와주세요. Signed 프로젝트는 너겟의 버그로 인해 전체 솔루션 빌드에 실패했기 때문에 제거해야 했습니다.
https://github.com/dotnet/standard/issues/538
https://github.com/NuGet/Home/issues/6038

따라서 수정될 때까지 기다려야 하거나 별도의 솔루션과 프로젝트를 추가한 다음 모든 파일을 수동으로 포함해야 합니다.

@alexeyzimarev 는 하나의 csproj를 갖고 서명하고 바인딩 리디렉션 문제를 피하기 위해 어셈블리 버전 번호(주 버전으로)를 고정합니다. 너겟 및 파일 버전에 표준 SemVer를 사용합니다. 이것은 모든 문제를 해결할 것입니다.

두 가지 버전을 유지해야 한다고 주장하는 경우(사용자에게 문제가 발생함) 구성을 통해 단일 csproj로 계속 이 작업을 수행할 수 있습니다.

두 가지 버전이 있다는 것이 얼마나 망가졌는지 깨닫기 전에 나는 원래 내 자신의 프로젝트에서 이 작업을 수행했습니다. 기본적으로 StrongName 속성 그룹을 추가했습니다. 그런 다음 dotnet build -c StrongName을 사용하여 빌드합니다.

<PropertyGroup Condition="'$(Configuration)'=='StrongName'">
    <PackageId>Jsonics.StrongName</PackageId>
    <NetStandardImplicitPackageVersion>1.6.1</NetStandardImplicitPackageVersion>
    <PackageVersion>0.1.0-alpha</PackageVersion>
    <Optimize>true</Optimize>
    <AssemblyOriginatorKeyFile>Jsonics.snk</AssemblyOriginatorKeyFile>
    <SignAssembly>true</SignAssembly>
    <PublicSign Condition="'$(OS)' != 'Windows_NT'">true</PublicSign>
</PropertyGroup>

제기한 문제가 해결될 때까지 기다리면 오래 기다릴 수 있습니다.

이것은 모든 문제를 해결할 것입니다.

나 이거 굉장히 좋아.

속성 그룹 제안은 가치가 있습니다. 나는 두 개의 패키지를 유지하려고 노력할 것입니다. 그렇지 않으면 혼란을 일으킬 것입니다. 내가 틀릴 수도 있지만 개인적으로 나는 서명을 피할 것입니다. 그러나 당신이 그것을 필요로하기 때문에 나는 서명 된 어셈블리로 패키지를 만들려고 노력할 것입니다.

@niemyjski ".net 팀에서 추천합니다"에 대한 링크가 있습니까? 나는 결과와 그들이 이것을 하는 것을 제안하는 방법에 대해 더 많이 알아야 합니다.

나는 그들과 이야기를 나눴고 그들이 또한 그것을 공개적으로 말했다는 것을 압니다.
포럼과 여유. 그것은 일종의 농담이며 제거되어야 합니다(
https://twitter.com/terrajobst/status/774752534682402817)..
강력한 이름의 어셈블리... 우리는 모든 어셈블리의 이름을 강력하게 지정하고
농담으로 서명 snk를 repo에 남겨 두십시오. 16진수 편집기가 있는 사람
강력한 이름 서명을 우회할 수 있으며 필요한 사람에게만 피해를 줍니다.
종속성을 취하지 않도록 패키지에 서명합니다. 당신은 강한 참조 할 수 있습니다
서명되지 않은 패키지에서 서명된 패키지를 모두 서명하지 않는 이유는 무엇입니까?
시각.

https://github.com/FoundatioFx/Foundatio/blob/master/src/Foundatio/Foundatio.csproj

감사 해요
-블레이크 니에미스키

2017년 11월 1일 수요일 오후 1시 30분 Alexey Zimarev 알림 @github.com
썼다:

@niemyjski https://github.com/niemyjski "The .net
팀이 이것을 추천합니다"? 결과와 ​​방법에 대해 더 많이 알아야 합니다.
정확히 그들은 이것을 제안합니다.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/restsharp/RestSharp/issues/992#issuecomment-341197289 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AA-So94xh-jiEMniw0D2QaGQPgT9zfBfks5syLjDgaJpZM4PLH2m
.

알겠습니다. 서명만 하겠습니다.

출시됩니다. https://www.nuget.org/packages/RestSharp/106.0.0

여기 github에서 릴리스 태그를 만들어야 합니다. :)

태그가 지정된

106.1.0에 대한 릴리스 정보는 다음을 언급합니다.
".NET Core에서 프록시 문제 수정"

해당 수정 사항이 무엇을 포함하는지 확실하지 않지만 프록시를 사용하는 데 여전히 문제가 있습니다.
.NET Core 2.0 포트(.NET Framework 4.6.1에서 제공) 이전에는 이와 같이 클라이언트를 인스턴스화했으며 매력처럼 작동했습니다.

 _restClient = new RestClient(DanskStatistikApi)
 {
         Proxy = WebRequest.GetSystemWebProxy()
 };
 _restClient.Proxy.Credentials = CredentialCache.DefaultCredentials;

.NET Core 2.0 프로젝트에서 동일한 코드를 사용하면 다음 응답 오류가 발생합니다.

System.PlatformNotSupportedException: Operation is not supported on this platform.

요청을 실행하는 코드는 다음과 같습니다.

var taskCompletion = new TaskCompletionSource<IRestResponse>();
var asyncHandle = _restClient.ExecuteAsync(request, r => taskCompletion.SetResult(r));
var response = (RestResponse)(await taskCompletion.Task);

이견있는 사람?

고마워,
프레드

.NET Core 2.0에 대한 작업 코드가 있습니까?

스택 추적을 확인하면 기본 프록시를 가져오려고 할 때 이것이 우리의 예외가 아니라 .NET 예외임을 알 수 있습니다.

예, 맞습니다 @alexeyzimarev , 예외는 실제로 System.Net.SystemWebProxy.GetProxy에서 발생했습니다. 트리거를 빨리 걸었습니다. :)

동일한 문제가 발생하는 다른 사용자의 경우 다음과 같이 사용할 프록시를 명시적으로 지정할 수 있습니다.

var restClient = new RestClient(DanskStatistikApi)
{
     Proxy = new System.Net.WebProxy("your-proxy-url-goes-here", 8080)
};
restClient.Proxy.Credentials = CredentialCache.DefaultCredentials;

.NET Core 2.0에서 106.1.0에서 106.2.0으로 업그레이드했는데 이 메시지가 나타나기 시작했습니다.

System.PlatformNotSupportedException: Operation is not supported on this platform.

다른 사람들이 언급했듯이 이 메시지는 System.Net.SystemWebproxy.GetProxy에 의해 생성된 것 같지만 제 경우에는 프록시를 명시적으로 구성하지 않고 내부적으로 자체 작업을 수행하고 내가 만드는 모든 요청에 ​​대해 예외가 발생합니다.

나는 106.1.0을 다시 존경했고 이것은 그것을 고쳤습니다. 그래서 프록시 설정이 어떤 식으로든 명시적이어야 하는 106.2.0에서 어떤 변화가 있습니까?

@voicebooth 이것은 #1061에서 보고됩니다.