Autofixture: CoreCLR 지원

아직, 적어도. DNX는 무엇입니까?

하하.. 새로운 크로스 플랫폼 asp.net 프레임워크입니다. https://github.com/aspnet/DNX

런타임은 "net451" 대신 "dnx451" 등입니다.

이 맥락에서 "지원"은 무엇을 의미합니까? .NET 4 라이브러리에 대한 종속성이 있는 테스트 라이브러리에서 ASP.NET 5를 테스트하는 것이 불가능하다는 말씀이신가요?

ASPNET 5는 여러 플랫폼에서 실행됩니다. 우리는 지금 dnx 플랫폼에서만 ASPNET 5를 작성 중이므로 다른 런타임 라이브러리 세트입니다. 우리 코드는 현재 "net451"용으로 컴파일되지 않았으므로 라이브러리는 호환되지 않는 플랫폼을 효과적으로 대상으로 합니다.

내 테스트는 이 project.json으로 잘 실행됩니다.

{
"종속성": {

     "xunit.runner.dnx": "2.1.0-*",
     "xunit":"2.1.0-*",
    "AutoFixture.Xunit2":"3.30-*",
    "NSubstitute": "1.8.0",
    "ManagementWeb": "",
    "Microsoft.AspNet.Mvc": "6.0.0-beta4",
    "AutoFixture": "3.30.4-*",
    "AutoFixture.AutoNSubstitute": "3.30.4-*",
    "Microsoft.Azure.Documents.Client": "0.9.2-preview",
    "WindowsAzure.Storage": "4.4.1-*",
    "DeepEqual": "1.1-*"
},
 "frameworks": {
    "dnx451": { }
},
"commands": {
    "test": "xunit.runner.dnx"
}

}

흥미로운. 차이점이 무엇인지 알아보기 위해 이 작업을 하고 있는 사람을 도청해야 합니다.
작업을 수행하기 위해 특별한 조치를 취했습니까?

아니요. IIRC Autofixture는 항상 aspnet 5와 함께 작동했지만 과거에는 xUnit 확장에 문제가 있었습니다. 이제 AF에 대한 xUnit 2 지원이 종료되고 DNX와 xUnit이 함께 잘 작동하므로 작동합니다.

여기서 아이디어는 DNX가 아니라 실제로 "CoreCLR에 대한 지원"인 것 같습니다. .NET Framework 4.5에서 작동하는 모든 것은 DNX의 4.5에서 작동합니다. CoreCLR은 지원하기 위해 약간의 노력이 필요할 것 같지만 얼마나 하는지는 모르겠습니다. 알아내는 가장 좋은 방법은 CoreCLR용으로 빌드하고 무엇이 중단되는지 확인하는 것입니다.

예, 분명히해야했습니다. DNX뿐만 아니라 CoreCLR을 의미했습니다.

coreclr repo 만 보면 프로젝트 현황을 파악하기 어렵습니다. 미리보기인가요? 베타? 출시 된?

전혀 시도하지 않고 지원되는 기능이 다양한 플랫폼에서 사용 가능한 기능의 교차점이라는 점에서 CoreCLR이 Portable Class Libraries와 같은 경우 변경 사항을 변경하지 않고 CoreCLR에서 실행되도록 AutoFixture를 개조하는 것은 거의 불가능합니다.

최근에 @moodmosaic 은 AtomEventStore(AutoFixture보다 훨씬 작은 프로젝트)에 대한 분석 을 할 정도로 친절했고

AutoFixture 소스를 전혀 보지 않고 귀하의 평가에 동의합니다. 주요 변경 사항이 있을 수 있습니다. #if DNX_* - 지원이 계획에 있는 경우 스타일 지시문이 필요합니다.

CoreCLR은 Windows Phone 8 이후로 어느 정도 실행되고 있습니다.

ASP.NET 5는 11월에 RC가 될 것이며 Linux 및 Mac용 CoreCLR도 2015년 11월에 RC가 될 것입니다. CoreFX와 함께. 2016년 1분기에 계획된 모든 것을 위한 릴리스 1.0.

주요 변경 사항을 도입하지 않고 CoreCLR에 대한 지원을 추가할 수 있다면 매우 놀랄 것이므로 이 문제에 _4.0_ 이정표를 추가했습니다.

호기심에 Ploeh.AutoFixture 어셈블리에서 API 이식성 분석기 를 실행하고 몇 가지 흥미로운 결과를 얻었습니다.

샴페인을 열기 전에 기다리십시오. 불행히도 지원되지 않는 기호의 대략 3%는 다음과 같은 다소 기본적인 기호를 설명합니다.

| 대상 유형 | 대상 회원 |
| --- | --- |
| 시스템.콘솔 | M:System.Console.get_Out |
| 시스템.스레딩.스레드 | M:System.Threading.Thread.get_ManagedThreadId |
| 시스템.스레딩.스레드 | M:System.Threading.Thread.get_CurrentThread |
| System.Reflection.ICustomAttributeProvider | M:System.Reflection.ICustomAttributeProvider.GetCustomAttributes(System.Type,System.Boolean) |
| System.Net.Mail.Mail주소 | M:System.Net.Mail.MailAddress.#ctor(System.String) |
| System.Serializable속성 | M:System.SerializableAttribute.#ctor |
| 시스템.런타임.직렬화.직렬화 정보 | T:System.Runtime.Serialization.SerializationInfo |
| System.Reflection.ParameterInfo | M:System.Reflection.ParameterInfo.IsDefined(System.Type,System.Boolean) |
| 시스템.유형 | M:System.Type.get_IsGenericTypeDefinition |
| 시스템.유형 | M:System.Type.get_IsEnum |
| 시스템.유형 | M:System.Type.get_BaseType |
| 시스템.유형 | M:System.Type.get_IsPrimitive |
| 시스템.유형 | M:System.Type.get_Assembly |
| 시스템.유형 | M:System.Type.get_IsGenericType |
| 시스템.유형 | M:System.Type.GetTypeCode(System.Type) |
| 시스템.유형 | M:System.Type.get_IsClass |
| 시스템.유형 | M:System.Type.get_IsValueType |
| 시스템.유형 | M:System.Type.get_IsAbstract |
| System.Reflection.MemberInfo | M:System.Reflection.MemberInfo.get_ReflectedType |
| System.Reflection.PropertyInfo | M:System.Reflection.PropertyInfo.GetSetMethod |
| 시스템 예외 | M:System.Exception.#ctor(System.Runtime.Serialization.SerializationInfo,System.Runtime.Serialization.StreamingContext) |
| System.Reflection.MethodBase | M:System.Reflection.MethodBase.GetCurrentMethod |

그러나 몇 가지 솔루션이 있습니다.

• System.Type 의 속성에 대한 모든 참조를 GetTypeInfo(Type) 확장 메서드를 통해 사용할 수 있는 System.TypeInfo 의 해당 참조로 바꿉니다.
• System.SerializableAttribute 대한 모든 참조를 제거합니다.
• System.Runtime.Serialization.SerializationInfo 대한 모든 참조를 제거합니다(_예외 생성자_에서만 사용됨).
• System.Net.Mail.MailAddress 대한 모든 참조를 제거합니다.
• System.Reflection.MemberInfo.ReflectedType 속성에 대한 모든 참조를 제거하고 반사된 개체를 사용하여 해당 유형을 유지합니다.
• System.Reflection.PropertyInfo.GetSetMethod 속성에 대한 모든 참조를 대신 System.Reflection.PropertyInfo.SetMethod 속성으로 바꿉니다.

이것은 첫 번째 단계일 뿐이며 CoreCLR이 아직 개발 중이므로 상황이 변경될 수 있습니다. 적어도 우리는 AutoFixture가 그것과 호환되도록 하기 위해 무엇이 필요한지에 대한 일반적인 아이디어를 얻었습니다.

와우, 이 분석을 수행해 주셔서 감사합니다. @ecampidoglio :+1:

일부 호환되지 않는 유형(예: MailAddress )은 전체 프레임워크에서만 작동하는 추가 기능 라이브러리로 이동할 수 있습니다. 나는 이미 버전 4용 _Ploeh.AutoFixture_ 라이브러리에서 일부 기능 을

PropertyInfo.GetSetMethod 를 PropertyInfo.SetMethod 로 바꾸는 아이디어는 좋습니다. AFAICT, .NET 4.5 이상에서만 작동하지만 _v4_ 분기가 이미 .NET 4.5에 있기 때문에 괜찮습니다.

"Jump In" 레이블이 이 문제에 적합한지 확실하지 않습니다. 일반적으로 상당히 쉽고 새로운 기여자 친화적 인 작고 고립 된 한입 크기의 문제를 나타내는 데 사용됩니다. 이 문제는 코드 기반과 그 역사의 상당 부분을 상당히 잘 이해해야 하는 것 같습니다.

@chaitanyagurrapu , 아마도 당신이 옳을 것입니다.

내가 _jump in_ 레이블을 추가한 이유는 이 작업이 AutoFixture 세부 정보와 다소 관련이 없다고 생각하기 때문입니다. 예: 다양한 비호환성을 해결하는 방법에 대한 결정을 내려야 하지만 CorCLR과 관련된 전체 코드/빌드 인프라가 어떻게 작동하는지 파악하는 것만으로도 많은 작업이 필요하며 그 부분은 AutoFixture와 전혀 관련이 없습니다.

현재로서는 이러한 기술이 없으므로 도움을 받고 싶습니다. 호환성 문제와 관련하여 내려야 할 결정은 여기 또는 전용 Github 문제에서 논의할 수 있습니다.

이 작업을 시작 했습니다. 앞으로 나올 질문들 :)

나에게 좋은 소리 :+1:

@lbargaoanu 좋은 소리:+1: 가능 하면 작게 유지하십시오 .

.NET Core용 AutoFixture를 빌드할 수 있도록 MailAddressGenerator를 v4 분기의 전체 프레임워크를 대상으로 하는 다른 프로젝트로 이동하고 싶습니다. .NET Core에 대한 자리 표시자 유형을 선언할 수도 있지만 지금까지는 조건부 컴파일을 피했습니다. 그리고 항상 전체 프레임워크에서만 지원되는 것들이 있을 것입니다.

작업중 입니다. 하지만 그동안...

향후 참조를 위해
https://blogs.msdn.microsoft.com/dotnet/2016/02/10/porting-to-net-core/

좋은 게시물! 라이브러리도 포함되나요? (_library_를 검색했지만 많이 찾지 못했습니다...)

:) 이것이 라이브러리에 관한 것이지만 이 게시물과 링크로 충분해야 합니다.

AutoFixture가 CoreCLR에서도 작동하는 모습을 보고 싶고 필요한 경우 기꺼이 도울 것입니다. Lucian Bargaoanu(#511, #513)의 마지막 PR을 보면 이 문제가 일부 해결되지 않은 토론에서 진부한 것처럼 보입니다.

나는 공을 굴리고 싶지만 이에 대한 전반적인 계획이 무엇인지, 토론을 방해하는 일부 세부 사항을 처리하는 방법을 모릅니다. 따라서 모든 세부 사항에 들어가기 전에 이와 같은 정보를 얻는 것이 유용할 수 있습니다.

내가 주위에 떠 다니는 것을 보았거나 나 자신이 가지고있는 몇 가지 질문 :

• AutoFixture를 PCL로 변환해야 합니까, 아니면 공유 프로젝트와 같은 것을 사용해야 합니까?
• 어떤 플랫폼이 확실히 필요하거나 장기적으로 원합니까? (.NET, CoreCLR, UWP?)
• 이와 같은 프로젝트에 조건부 컴파일이 필요하지 않습니까?

@ploeh 이 모든 질문에 답할 수는 없지만 핵심 기여자가 이에 대한 정보를 제공할 수 있습니다. @lbargaoanu 이에 대한 의견이 있으신가요? 감사 해요!

이 스레드에 답장하는 것을 잊었습니다. 내 사과를 받아주세요 :플러시:

.NET Core용 AutoFixture 코드 기반을 준비하기 위해 할 수 있는 모든 작업은 코드 기반을 저하시키거나 주요 변경 사항을 도입하지 않는 한 환영합니다.

주요 변경 사항은 여전히 ​​가능하지만 _v4_ 분기로 이동해야 합니다.

어쨌든, 정당하지 않은 것처럼 보이는 변경 사항에 대해서는 정당한 근거가 필요합니다. .NET Core 상황을 면밀히 따르고 있다고 말할 수는 없지만 여전히 많은 스래싱이 있는 것 같고 대상이 계속 움직이는 한 추측적인 변경 사항을 도입하고 싶지 않습니다.

조건부 컴파일이 필요하게 되더라도 놀라지 않을 것이며 제정신을 유지할 수 있는 한 반대하지 않습니다. 게시해야 하는 모든 것을 빌드하기 위해 빌드 스크립트를 계속 실행할 수 있다면 아마 괜찮을 것입니다. 그러나 나는 이것에 대한 경험이 많지 않다는 것을 인정해야 합니다.

나는 또한 어떤 플랫폼이 필요한지 모릅니다. 기본적으로 커뮤니티의 누군가가 유지 관리가 가능하고 AutoFixture의 범위를 확장하는 pull 요청을 보내면 수락을 고려할 것입니다.

AFAICT, 우리는 netstandard1.X 를 목표로 삼아야 합니다. 이는 API를 구현하는 모든 플랫폼(Windows의 넷코어 크로스 플랫폼 및 넷 프레임워크 포함)에서 실행되는 API 세트입니다.

https://github.com/dotnet/corefx/blob/master/Documentation/architecture/net-platform-standard.md 참조

일반적으로 숫자가 높을수록 API는 더 많지만 지원되는 플랫폼은 적습니다. netstandard1.X 에서 어떤 X를 목표로 삼아야 하는지 이해함으로써 이 토론을 시작(계속)해야 합니다.

그 문서의 첫 번째 단락은 저를 약간 두렵게 합니다.

.NET 클래스 라이브러리 구축의 미래에 대한 초기 계획을 공유하고 있습니다.
-- https://github.com/dotnet/corefx/blob/master/Documentation/architecture/net-platform-standard.md

@moodmosaic 저도 두렵지 만, 우리가 목표로 삼을 API를 선택하는 일반적인 개념은 본질적으로 어느 쪽이든 필수적입니다. netstandard는 단지 그들에게 잘 알려진 이름과 합의된 부분집합, 그리고 그것들을 설명하는 더 쉬운 방법을 제공합니다. 그것은 우리가 처음부터 휴대하기를 원했다고 가정합니다.

예를 들어 AutoFixture용 리플렉션 API가 필요한 경우 가질 수 있는 대상 목록이 줄어듭니다. 동시 수집이 필요한 경우에도 마찬가지입니다. 그런 플랫폼은 이미 존재하기 때문에(net framework full, Windows phone 등), 어떤 API가 필요한지 논의한다고 해서 바뀔 수 있는 부분은 아니라고 생각합니다.

대화를 [다시] 시작할 수도 있습니다... (면책 조항: 저도 아직 이 내용을 배우고 있습니다)

가장 많은 수의 플랫폼에 이미 구현되어 있는 가장 낮은 것( netstandard1.0 )부터 시작하여 해당 플랫폼에 커밋할 수 없는(또는 하지 않을) 이유를 찾습니다.

내 이해에 따르면 netstandard1.0 API 세트는 꽤 오래되고 제한적입니다. 다음과 같은 사항이 없습니다.

• System.Linq.Parallel ( netstandard1.1 부터 시작)
• System.Console( netstandard1.3 부터 시작)
• System.Collections.Concurrent( netstandard1.1 부터 시작)
• System.ComponentModel.Annotations( netstandard1.1 부터 시작)
• System.Collections.Specialized ( netstandard1.3 부터 시작)

이것은 AutoFixture가 netstandard1.0 를 대상으로 하는 것이 실용적이지 않다고 생각하게 합니다.

여기서 @ecampidoglio 가 언급한 분석기를 기다리는 것이 더 나은 전략인지 궁금합니다.

편집: 여기에 .NET API 이식성 분석기 도구 리포지토리가 있으며 여기에 웹 사이트 http://dotnetstatus.azurewebsites.net이 있습니다.

댓글 스팸이 너무 많아 죄송합니다. 이제 그만할게요 :)

참고로 저는 v4 4a7d415에서 로컬로 빌드된 Ploeh.AutoFixture.dll에서 최신 이식성 분석기를 실행했으며 요약은 다음과 같습니다.

현재 권장하는 몇 가지 변경 사항은 다음과 같습니다.

전체 출력은 여기에 있습니다 .

@ploeh 널리 사용되는 Asp.Net Core 구성 요소에는 최소 netstandard1.3 합니다. 예를 들어 EntityFrameworkCore(1.3 사용) 및 Mvc(1.6 사용)가 있습니다.

Autofixture가 이 중 하나를 기준선으로 사용했다면 좋은 위치에 있을 것이라고 생각합니다.

.Net Core 지원을 사용할 수 있는 일정이 있습니까?

v4 브랜치를 기반으로 .NET Core에서 빌드를 만들 수 있었습니다. 하지만 테스트 프로젝트를 만들려고 하지는 않았습니다. 패키지를 만들고 싶다면 이 브랜치를 확인하세요.

FWIW, 다음 은 AutoFixture/AutoFixture v4와 uhaciogullari/AutoFixture net-core 간의 비교 입니다. 잘 보고 갑니다 👍

글쎄, 그것은 정말 간단하지 않습니다. project.json이 존재하면 현재 일반 csproj 프로젝트를 빌드할 때 오류가 발생합니다. 모든 프로젝트를 project.json 형식으로 마이그레이션할 수 있지만 다른 프로젝트에 적합한지 잘 모르겠습니다. 자세히 확인하지는 않았지만 다른 테스트 프레임워크용 플러그인으로 의심됩니다. .NET Core도 지원하는지 알 수 없습니다.

또 다른 사실은 Microsoft 가 것이라고 발표 했다는 것입니다. 그들은 쉬운 마이그레이션을 약속하지만 이 임시 형식을 사용하는 데 시간을 할애하시겠습니까? 그것은 모두 당신에게 달려 있습니다. 현재 브랜치에서 패키지를 푸시할 수 있지만 v4가 진행 중인 것 같습니다.

오류 없이 빌드하는 방법이 있습니다. #712

실제로 지점에서 빌드를 시도했지만 dll을 생성하지 않습니다. 일부 구성이 누락되었을 수 있지만 각 프로젝트에 추가 폴더를 만드는 것은 미학적으로 저에게 매력적이지 않았습니다.

이에 대한 업데이트가 있습니까?

.net 핵심 도구가 RTM 상태에 도달할 때까지 기다리는 것이 현명하다고 생각합니다. 업데이트된 csproj 도구는 VS2015로 이식되지 않으므로 VS2017에서만 사용할 수 있습니다. https://twitter.com/TheCodeJunkie/status/822048014172880900 참조

https://blogs.msdn.microsoft.com/dotnet/2017/03/07/announcing-net-core-tools-1-0/

@hoetz 당신은 여전히 ​​vs2017 커뮤니티 에디션을 설치할 수 있습니다.

이 문제를 검토할 계획이 있습니까?

AitoFixture 없이 .NET 표준 어셈블리에 대한 테스트를 작성하는 것은 정말 나쁜 일입니다...

안녕하세요 여러분, 이를 위해서는 커뮤니티에서 누군가가 참여하고 기여해야 합니다. 거버넌스 모델 문제가 아직 해결되지 않았기 때문에 지금 당장은 분명히 어렵습니다(#703). 누군가도 앞장서야 합니다.

문제를 가지고 놀고 있습니다. 지금은 Src\AutoFixture.sln에만 집중하고 있습니다.

내 전략은 .NET Framework와 .NET Standard를 모두 지원할 수 있도록 Src\AutoFixture\AutoFixture.csproj를 새 프로젝트 형식(VS 2017)으로 변환하는 것입니다.

.NET 이식성 테스트를 실행했으며 최상의 대상은 .NET Standard 1.5여야 합니다(첨부 파일 참조).

우선 테스트 프로젝트를 변환하지 않겠지만 향후 .NET Core 런타임에서도 테스트를 실행할 수 있다고 가정합니다.

AutoFixtureNetPortabilityTest.zip

안녕하세요 @Kralizek - 참고로 저는 #712에서 netstandard1.3 성공했습니다.

@Kralizek 내 실수, netstandard1.3 계획을 시작한 것 같지만 실제로는 netstandard1.5 끝났습니다 👍

거의 다 왔어. 테스트는 .NET Framework에서 모두 녹색입니다. 빌드는 .NET Standard에서 모두 빨간색입니다. :디

다음 범주의 문제만 만났습니다.

발전기가 필요하지 않음
System.Net.Mail.MailAddress 는 .NET Standard에서 사용할 수 없기 때문에 MailAddressGenerator 한 가지 경우만 있습니다. 솔루션: 전체 파일이 #if NET40 ... #endif에 의해 "제거"되었습니다.

직렬화
SerializableAttribute, SerializationInfo 및 StreamingContext는 .NET Standard에 존재하지 않습니다. 또한 Exception에는 이 두 가지 유형을 사용하는 생성자가 없습니다. 컴파일러 지시문을 사용하여 모든 예외에서 속성과 해당 생성자를 제거했습니다. 특히 속성을 제거하는 것은 정말 아름답지 않습니다.

유형에 대한 정보를 얻기 위한 리플렉션 사용
.NET Standard에서는 Type 가 훨씬 나쁩니다. 모든 것은 사용되는 모든 속성을 포함하는 TypeInfo 개체에 위임됩니다. 문제는 .NET Framework가 여전히 이전 Type 클래스를 사용한다는 것입니다.
해결책:
동일한 Type 개체 public static Type GetTypeInfo(this Type type) => type; 를 전달하는 확장 메서드를 만들고 이 확장 메서드를 컴파일러 지시문을 통해 .NET Framework에서만 사용할 수 있도록 했습니다. 이 트릭은 파일을 그대로 둔 채로 많은 비호환성을 해결했습니다. 참고: 확장 메서드는 internal 로 표시됩니다.

리플렉션을 사용하여 현재 어셈블리 가져오기
좋아, 이것은 프로젝트 레이아웃을 완벽하게 알지 못하기 때문에 어려운 것이었습니다. ReSharper를 사용하여 클래스 계층 구조를 빠르게 확인했지만 다시 확인해야 합니다.
파일은 TerminatingWithPathSpecimenBuilder 이고 행은 var thisAssembly = MethodBase.GetCurrentMethod().DeclaringType.Assembly; 입니다. 우리가 속한 어셈블리를 찾고 있는 것 같습니다. 이 클래스에는 상속자가 없으므로 typeof(TerminatingWithPathSpecimenBuilder).DeclaringType[.GetTypeInfo()].Assembly 가 동일한 결과를 반환한다고 가정하는 것이 안전하지만 다시 말하지만 제가 틀릴 수도 있습니다. (저는 가짜 확장 방법을 괄호 안에 넣었습니다). 내 가정이 맞다면 이 클래스를 sealed 하여 상속되어 손상될 위험을 피하는 것이 좋습니다.

어쨌든 새로운 프로젝트 파일을 소개하겠습니다.

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFrameworks>net40;netstandard1.5</TargetFrameworks>
    <GenerateAssemblyConfigurationAttribute>false</GenerateAssemblyConfigurationAttribute>
    <GenerateAssemblyCompanyAttribute>false</GenerateAssemblyCompanyAttribute>
    <GenerateAssemblyProductAttribute>false</GenerateAssemblyProductAttribute>
    <GenerateAssemblyVersionAttribute>false</GenerateAssemblyVersionAttribute>
    <GenerateAssemblyFileVersionAttribute>false</GenerateAssemblyFileVersionAttribute>
    <GenerateAssemblyTitleAttribute>false</GenerateAssemblyTitleAttribute>
    <GenerateAssemblyDescriptionAttribute>false</GenerateAssemblyDescriptionAttribute>
  </PropertyGroup>
  <ItemGroup Condition=" '$(TargetFramework)' == 'net40' ">
    <Reference Include="System" />
    <Reference Include="System.Core" />
    <Reference Include="Microsoft.CSharp" />
    <Reference Include="System.ComponentModel.DataAnnotations" />
  </ItemGroup>
  <ItemGroup Condition=" '$(TargetFramework)' == 'netstandard1.5' ">
    <PackageReference Include="System.ComponentModel.Annotations" Version="4.1.0" />
  </ItemGroup>
</Project>

예, 이것은 전체 프로젝트 파일입니다.

@Kralizek 당신은 우리가 v4 브랜치 에서 >= net45 를 목표로 삼으려는 것을 알아차렸습니까?

@adamchester nope... 별로 중요하지 않지만 대상 프레임워크를 변경하겠습니다. 감사합니다! 👍

Btw, System.Threading.Thread 패키지 로 사용할 수 있다는 것을 알았습니다.

그것은 완전히 새로운 수준의 컴파일러 오류를 잠금 해제했습니다... 멋지네요 :P

.NET Standard 2.0 많은 API를 다시 추가해야 합니다. 기다릴만한 가치가 있습니까?

아니, 그렇지 않다. .NET Standard 2.0은 2017년 3분기에 출시될 예정입니다. .NET Standard 1.5 지원이 한 번 남았습니다. 왜 2.0을 기다려야 합니까? 런타임에 메일 메시지를 생성하기 위해 지원하지 않습니까?

또한 2.0은 대부분 프레임워크 4.6의 shim이 될 것이며 NotSupportedException이 많이 발생합니다.

@Kralizek 충분히 공정합니다. 물론 더 빨리 릴리스된 autofixter를 좋아할 것이므로 더 일반적인 질문이었습니다.

FWIW, 저는 메일 주소 생성기에 대한 지원을 추가한 공헌자입니다. AutoFixture가 기본적으로 이를 지원하도록 만든 것은 좋지만 AutoFixture의 중요한 측면은 아니며 노력할 가치가 있습니다. 좀 기다려.

가능한 가장 낮은 .NET Standard에서 AutoFixture를 사용하는 것이 가장 우선순위가 높은 IMHO여야 합니다. 계속해서 좋은 일을 하세요. 도움이 필요하거나 테스트에 대한 지원이 필요하면 제가 확실히 참여할 수 있습니다.

@Kralizek TypeInfo 항목도 .NET 4.5에 있으므로 도움이 될 것입니다.

오늘 여러 .NET Core 프로젝트에 테스트를 추가하기 시작할 때 "Package AutoFixture 3.50.5 is not compatible with netcoreapp1.1 (.NETCoreApp,Version=v1.1)" 오류가 발생했습니다.

이 매우 유용한 nuget 패키지를 이 플랫폼에서 사용할 수 있는 시기에 대한 지침을 제공하는 ".net core의 autofixture 상태" 종류의 응답을 요청하고 있습니다(.net core 2.0은 이미 rtm이고 릴리스 보류 중입니다.) .

무엇이 그것을 막고 있습니까? (미리 감사합니다)

현재 작업 중이며 #773에서 진행 상황을 추적할 수 있습니다. 이 PR은 AutoFixture 프로젝트 자체에 관한 것입니다. 마이그레이션해야 할 다른 프로젝트가 9개 더 있지만 이 프로젝트에 대한 작업을 마친 후에만 수행해야 합니다.

.NET Core 지원은 v4로 출시될 예정이며 여기 에서 전체 범위를 찾을 수

그 동안 Dev NuGet 피드(#762)도 작업 중이므로 초기 제품 테스트에 참여할 수 있습니다 😉

@zvirja 자세한 업데이트에 감사드립니다. 다른 개발자에게도 유용할 것이라고 확신합니다. 초기 제품 테스트에 참여하고 싶습니다.

@zvirja 그래서 명확히 하기 위해 - .NET Core 애플리케이션/라이브러리에 대한 단위 테스트를 작성하는 현재(임시) 접근 방식은 AutoFixture 를 .NET 4.7 테스트 프로젝트에서 사용하고 테스트 프로젝트를 마이그레이션하는 것입니다. 나중에 .NET Core로?

이것이 당분간 제안된 해결 방법입니까? (내가 작성하는 앱이 완전히 .NET Core가 되도록 허용되는 한, 실제로 일반 .NET 4.7 환경에서 테스트를 작성하는 것은 큰 문제가 되지 않습니다.)

@andersborum 임시 해결 방법에 대해 생각한 적이 없습니다. v3에서 사용하는 모든 API(NuGet에 게시된 패키지)가 .Net Standard 2.0과 호환되는지 확신할 수 없습니다(.NET Standard의 새로운 기능을 사용하기 위해).

v3와 .Net Core를 모두 결합하는 방법을 찾으면 알려주십시오. 그래서 다른 사람들에게 조언할 수 있습니다 😉

모두에게 알리기 위해 - AutoFixture PR(#773)에 대한 .Net Standard 지원이 v4 분기에 병합되었습니다. 당신은 우리의 개인 피드 에서 패키지를 사용할 수 있습니다.

AutoFixture 라이브러리만 마이그레이션되었습니다. 다른 글루 라이브러리는 나중에 후속 조치를 취할 것입니다.

알파 버전이라도 v4를 nuget.org로 이동할 수 있습니까? 지금까지 .netstandard를 지원하는 autofixture와 비슷한 것을 찾을 수 없었습니다.
v4의 출시일은 이미 결정되었나요?

@RomanKernSW 지금은 아닙니다. 아직 프로젝트의 절반도 마이그레이션하지 않았으므로(예: xUnit, NUnit, NSubstitute 지원) 너무 이릅니다. 또한 우리는 네임스페이스 를 변경하는 것을 선호합니다. 릴리스 사이에 주요 중단이 될 것이기 때문입니다. 반면에 master 를 v4 지속적으로 병합하기 때문에 가능한 한 나중에 네임스페이스를 변경하고 싶습니다. 변경 후에 그렇게 하는 것은 지옥이 될 것입니다.

비공개 피드에 문제가 있습니까? 꼭 필요한 경우 NuGet.config 를 통해 피드를 추가할 수 있습니다.

흠 nuget 복원(.Net Core 2 - VSO에서 작업 미리보기)에 nuget.config를 사용할 수 있는지 확인해야 합니다. 현재 nuget.config 파일이 없는 nuget.org가 포함된 비공개 피드(VSO)가 하나 있습니다. 테스트할 시간이 필요합니다...

.Net Standard 2.0에는 .Net Framework NuGet에 대한 호환성 모드가 있습니다.
AutoFixture 3.50.x를 사용하여 .Net Core 테스트를 작성했으며 문제가 없습니다.
멀리.

@roarwrecker 굉장합니다, 공유해 주셔서 감사합니다! NuGet에 대한 공식 지원을 출시할 때까지 더 큰 시간 버퍼가 있음을 의미합니다.wink:

@roarwrecker 감사합니다... 이것은 .netstandard 1.6의 문제가 아니었습니다. 너겟을 설치할 수 있지만 오류 없이 컴파일되지 않습니다.

여러분, .NetCore 작업이 얼마나 진행되었는지 잘 모르겠지만 NuGet에서 알파 버전을 얻을 수 있습니까?

@selmendorfFrontline 여기 에서 답장 복사:

시험판 버전을 NuGet에 게시하는 것은 나에게 약간 고통스러운 질문입니다. 대부분의 프로젝트에 대해 .NET Core를 지원하기 시작했지만 기본 네임스페이스 를 있습니다 . 이것은 우리 클라이언트에게 엄청난 변경이 될 것이며 모든 클라이언트 코드는 컴파일을 멈출 것입니다. 혼란이 나타나는 지점은 다음과 같습니다.

• 기존 네임스페이스가 있는 alpha 를 릴리스하고 alpha 와 RTM 사이에서 네임스페이스를 변경하면 클라이언트가 기존 네임스페이스가 있는 v4를 이미 보았기 때문에 혼동을 줄 것입니다. 거버넌스 모델이 변경됨에 따라 v4가 항상 새로운 네임스페이스로 출시되었음을 고객이 느끼기를 바랍니다.
• 네임스페이스가 변경된 alpha 를 릴리스하면 더 이상 고통 없이 master 를 v4 분기에 병합할 수 없습니다. 현재 우리는 두 가지 모두에 커밋하고 있으므로 네임스페이스 변경을 끝까지 미루고 싶습니다. 또 다른 요점은 우리 문서가 현재 준비되지 않았기 때문에 사람들이 왜 모든 네임스페이스 가져오기가 유효하지 않고 단순히 텍스트 바꾸기를 실행해야 하는지 이해하지 못할 수도 있다는 것입니다. 그것은 그들을 무섭게 만들고 경험이 내가 원하는 만큼 순조롭지 않을 것입니다.

이 상황을 해결하는 가장 좋은 방법은 alpha 를 출시하지 않고 RTM만 출시하는 것입니다. 불행히도 정확한 ETA는 제 능력(저는 여가 시간에 이 프로젝트를 진행 중입니다)과 다른 기여자의 가용성(내 PR을 검토해야 합니다 😉)에 따라 다르기 때문에 여러분에게 정확한 ETA를 제공할 수 없습니다. 내 머리로는 한 두 달 안에 출시될 것이라고 상상하고 이 범위 내에서 일어나기를 바랍니다. 이 프로젝트는 거버넌스 모델 변경으로 인해 약 9개월 동안 중단되었습니다. 이것이 지원이 지연되는 주된 이유입니다.

그동안 미리보기 피드에서 패키지를 사용하세요. 위에서 언급한 대로 Nuget.config 를 조정할 수 있으므로 이것이 문제가 되어야 합니다.

#857이 최종적으로 병합된 후 이 문제를 종료하겠습니다. 최종 .NET 호환성 테이블은 다음과 같습니다.

| 제품 | .NET 프레임워크 | .NET 표준 |
| ------------------ | ------------------------ | ------------------------ |
| 자동 고정 장치 | :heavy_check_mark: 4.5.2 | :heavy_check_mark: 1.5 |
| AutoFixture.xUnit | :heavy_check_mark: 4.5.2 | :heavy_minus_sign: |
| AutoFixture.xUnit2 | :heavy_check_mark: 4.5.2 | :heavy_check_mark: 1.5 |
| AutoFixture.NUnit2 | :heavy_check_mark: 4.5.2 | :heavy_minus_sign: |
| AutoFixture.NUnit3 | :heavy_check_mark: 4.5.2 | :heavy_check_mark: 1.5 |
| AutoFakeItEasy | :heavy_check_mark: 4.5.2 | :heavy_check_mark: 1.6 |
| 오토포크 | :heavy_check_mark: 4.5.2 | :heavy_minus_sign: |
| 오토모크 | :heavy_check_mark: 4.5.2 | :heavy_check_mark: 1.5 |
| 자동 대체 | :heavy_check_mark: 4.5.2 | :heavy_check_mark: 1.5 |
| AutoRhinoMock | :heavy_check_mark: 4.5.2 | :heavy_minus_sign: |
| 관용구 | :heavy_check_mark: 4.5.2 | :heavy_check_mark: 2.0 |
| Idioms.FsCheck | :heavy_check_mark: 4.5.2 | :heavy_minus_sign: |
| 의미 비교 | :heavy_check_mark: 4.5.2 | :heavy_check_mark: 1.5 |

Idioms.FsCheck 제외한 모든 지원되지 않는 라이브러리는 해당 종속성이 .Net Standard를 지원하지 않고 업데이트될 가능성이 낮으므로 업데이트할 수 없습니다(대부분 사용되지 않음). .NET 452 및 .NET Standard 2.0 (기술적으로 가능함)를 모두 지원하기 위해 Idioms.FsCheck 포트를 시도했지만 작동하지 못했습니다. F# SDK는 여전히 매우 거칠고 새 릴리스를 기다려야 합니다. TargetFrameworks 노드를 정의한 후 컴파일 및 프로젝트 로드가 실패합니다.

다른 비전이 없는 한 저는 이 계획을 따를 것입니다 😃저도 출시가 얼마 남지 않았는지, 얼마나 뒤쳐져 있는지 느끼고 있습니다 😊

가 가 가!

.NET 452 및 .NET Standard 2.0 모두 지원하기 위해 Idioms.FsCheck 포트를 시도했습니다.

해당 버전에서 최신 F# 버전으로 전환해 보셨습니까? IIRC, F# 3.1에 있으며 이것이 사실일 수 있습니다.

멋진 작품 @zvirja. 우리가 v4를 얻을 수 있다고 생각합니까? 가까울수록 설레는 기분 :)

맥주 한 잔 드리고 싶어요 :)

해당 버전에서 최신 F# 버전으로 전환해 보셨습니까? IIRC, F# 3.1에 있으며 이것이 사실일 수 있습니다.

@moodmosaic 네. FsCheck 2.9.0 을 확인하면 FSharp.Core (>= 4.1.17) 에 의존한다는 것을 알게 될 것이므로 다른 선택이 없었습니다 😅 문제는 SDK에 있습니다. 두 프레임워크를 동시에 대상으로 지정하기 시작하면 VS에서 솔루션을 로드할 수 없습니다.
프로젝트:

<PropertyGroup>
  <TargetFrameworks>net452;netstandard2.0</TargetFrameworks>
  .....
</PropertyGroup>

<ItemGroup>
  <PackageReference Include="FsCheck" Version="[0.9.2,3.0.0)" Condition=" '$(TargetFramework)'=='net452' " />
  <PackageReference Include="FSharp.Core" Version="3.1.2" Condition=" '$(TargetFramework)'=='net452' " />

  <PackageReference Include="FsCheck" Version="[2.9.0,3.0.0)" Condition=" '$(TargetFramework)'=='netstandard2.0' " />
  <PackageReference Include="FSharp.Core" Version="4.1.17" Condition=" '$(TargetFramework)'=='netstandard2.0' " />

  <PackageReference Include="FSharp.NET.Sdk" Version="1.0.*" PrivateAssets="All" />
</ItemGroup>

VS에서 열려고 시도:

모든 것이 프로젝트에 문제가 없습니다. 문제는 F# SDK의 어딘가에 있습니다. 그렇기 때문에 FsCheck의 .NET Core 지원을 더 나은 시기까지 연기하고 싶습니다.

@Kralizek 위의 몇 가지 답변을 참조하십시오.

VS 2017.4에서 방금 체크인했지만 여전히 F# 프로젝트의 여러 프레임워크를 대상으로 지정할 수 없습니다. 따라서 다른 모든 프로젝트에 대해 .NET Core를 지원하므로 지금은 이 문제를 종료합니다.

JFYI: NuGet에 v4 rc1을 출시 했으므로 사용자 지정 피드로 재생할 필요 없이 소비하고 테스트할 수 있습니다.