Autofixture: Поддержка CoreCLR

По крайней мере, пока. Что такое DNX?

Ха-ха .. это новый кроссплатформенный фреймворк asp.net. https://github.com/aspnet/DNX

среда выполнения - "dnx451" вместо "net451" и т. д.

Что в данном контексте означает «поддержка»? Вы говорите, что невозможно протестировать ASP.NET 5 из тестовой библиотеки с зависимостью от библиотеки .NET 4?

ASPNET 5 работает на нескольких платформах. Сейчас мы пишем только ASPNET 5 на платформе dnx, так что это другой набор библиотек времени выполнения. В настоящее время наш код не скомпилирован для "net451", поэтому библиотеки нацелены на несовместимые платформы.

Мои тесты отлично работают с этим project.json:

{
"dependencies": {

     "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. Теперь, когда поддержка xUnit 2 для AF отсутствует, а DNX и xUnit прекрасно работают вместе, это просто работает.

Кажется, идея здесь действительно «поддержка CoreCLR», а не DNX. Все, что работает для .NET Framework 4.5, будет работать и для 4.5 на DNX. CoreCLR, вероятно, потребует некоторых усилий для поддержки, но я не знаю, сколько. Лучший способ узнать это - попробовать собрать его для CoreCLR и посмотреть, что ломается.

Да, я должен был быть ясным. Я имел в виду CoreCLR, а не только DNX.

Просто глядя в репозиторий coreclr , мне трудно

Даже не пробуя его, если CoreCLR чем-то похож на Portable Class Libraries в том, что поддерживаемые функции являются пересечением доступных функций на различных платформах, маловероятно, что будет возможно модифицировать AutoFixture для работы на CoreCLR без нарушения изменений.

Недавно @moodmosaic был так любезен, что провел анализ для AtomEventStore (проект намного меньше, чем AutoFixture), и в результате оказалось, что версия PCL была невозможна .

Совершенно не заглянув в исходники AutoFixture, я согласен с вашей оценкой: критические изменения вероятны. #if DNX_* -стилевые директивы потребуются, если поддержка входит в план.

CoreCLR более или менее работает с Windows Phone 8.

ASP.NET 5 станет RC в ноябре, CoreCLR для Linux и Mac также станет RC в ноябре 2015 года. Наряду с CoreFX. Релиз 1.0 для всего, что запланировано на 1 квартал 2016 года.

Я был бы чрезвычайно удивлен, если бы можно было добавить поддержку CoreCLR без внесения критических изменений, поэтому я добавил в эту проблему _4.0_ веху.

Из любопытства я запустил анализатор переносимости API на сборке Ploeh.AutoFixture и получил несколько интересных результатов:

Подождите, прежде чем открывать шампанское. Эти примерно 3% неподдерживаемых символов, к сожалению, составляют некоторые довольно фундаментальные:

| Тип цели | Целевой член |
| --- | --- |
| System.Console | M: System.Console.get_Out |
| System.Threading.Thread | M: System.Threading.Thread.get_ManagedThreadId |
| System.Threading.Thread | M: System.Threading.Thread.get_CurrentThread |
| System.Reflection.ICustomAttributeProvider | M: System.Reflection.ICustomAttributeProvider.GetCustomAttributes (System.Type, System.Boolean) |
| System.Net.Mail.MailAddress | M: System.Net.Mail.MailAddress. # Ctor (System.String) |
| System.SerializableAttribute | M: System.SerializableAttribute. # Ctor |
| System.Runtime.Serialization.SerializationInfo | T: System.Runtime.Serialization.SerializationInfo |
| System.Reflection.ParameterInfo | M: System.Reflection.ParameterInfo.IsDefined (System.Type, System.Boolean) |
| System.Type | M: System.Type.get_IsGenericTypeDefinition |
| System.Type | M: System.Type.get_IsEnum |
| System.Type | M: System.Type.get_BaseType |
| System.Type | M: System.Type.get_IsPrimitive |
| System.Type | M: System.Type.get_Assembly |
| System.Type | M: System.Type.get_IsGenericType |
| System.Type | M: System.Type.GetTypeCode (System.Type) |
| System.Type | M: System.Type.get_IsClass |
| System.Type | M: System.Type.get_IsValueType |
| System.Type | M: System.Type.get_IsAbstract |
| System.Reflection.MemberInfo | M: System.Reflection.MemberInfo.get_ReflectedType |
| System.Reflection.PropertyInfo | M: System.Reflection.PropertyInfo.GetSetMethod |
| System.Exception | M: System.Exception. # Ctor (System.Runtime.Serialization.SerializationInfo, System.Runtime.Serialization.StreamingContext) |
| System.Reflection.MethodBase | M: System.Reflection.MethodBase.GetCurrentMethod |

Однако есть несколько решений:

• Замените все ссылки на свойства в System.Type соответствующими в System.TypeInfo , доступными через метод расширения GetTypeInfo(Type) .
• Удалите все ссылки на System.SerializableAttribute .
• Удалите все ссылки на System.Runtime.Serialization.SerializationInfo (вероятно, используются только в _exception constructors_).
• Удалите все ссылки на System.Net.Mail.MailAddress .
• Удалите все ссылки на свойство System.Reflection.MemberInfo.ReflectedType и используйте отраженный объект, чтобы определить его тип.
• Вместо этого замените все ссылки на свойство System.Reflection.PropertyInfo.GetSetMethod свойство System.Reflection.PropertyInfo.SetMethod .

Это только первый шаг, и все может измениться, поскольку CoreCLR все еще разрабатывается. По крайней мере, мы получили общее представление о том, что нужно сделать, чтобы сделать AutoFixture совместимым с ним.

Вау, спасибо, @ecampidoglio , за выполнение этого анализа: +1:

Некоторые несовместимые типы (например, MailAddress ) мы можем перенести в дополнительную библиотеку, которая работает только на полной платформе. Я уже собирался вытащить некоторые функции из библиотеки _Ploeh.AutoFixture_ для версии 4 .

Идея замены PropertyInfo.GetSetMethod на PropertyInfo.SetMethod хороша. AFAICT, он будет работать только на .NET 4.5+, но это нормально, потому что ветка _v4_ уже находится на .NET 4.5.

Не уверен, что метка «Перейти» подходит для этой проблемы. Обычно он используется для обозначения небольших, изолированных, незначительных проблем, которые довольно просты и удобны для новых участников. Похоже, эта проблема потребует довольно хорошего понимания значительной части кодовой базы и ее истории.

@chaitanyagurrapu , возможно, ты прав.

Причина, по которой я добавил метку _jump in_, заключалась в том, что я считаю эту работу несколько не связанной с деталями AutoFixture. Да: нужно будет принять решение о том, как устранить различные несовместимости, но также предстоит большая работа, просто выясняя, как работает вся инфраструктура кода / сборки, связанная с CorCLR, и эта часть полностью не связана с AutoFixture.

На данный момент у меня нет этих навыков, поэтому я хотел бы получить помощь с этим. Решения, которые необходимо принять по вопросам совместимости, мы можем обсудить здесь или в специальных выпусках Github.

Я начал над этим работать. Еще вопросы :)

Мне нравится: +1:

@lbargaoanu Звучит хорошо: +1: Помните, если это вообще возможно, держите его маленьким .

Я хотел бы переместить MailAddressGenerator в другой проект, ориентированный на полную структуру в ветке v4, чтобы я мог создать AutoFixture для .NET Core. Я мог бы также объявить тип-заполнитель для .NET Core, но до сих пор избегал условной компиляции. И всегда будет то, что поддерживается только в полном объеме.

Это в разработке . А пока ...

Для дальнейшего использования
https://blogs.msdn.microsoft.com/dotnet/2016/02/10/porting-to-net-core/

Хороший пост! Он также распространяется на библиотеки? (Я искал _library_, но не нашел ...)

:) Это все о библиотеках, но этого поста и ссылок на него должно хватить.

Мне бы очень хотелось, чтобы AutoFixture также работала над CoreCLR и была готова помочь там, где это необходимо. Глядя на последние PR Лучана Баргаоану (# 511 и # 513), похоже, что эта проблема устарела из-за некоторых нерешенных дискуссий.

Я хотел бы сдвинуть дело с мертвой точки, но не знаю, каков был общий план для этого и как справиться с некоторыми деталями, которые блокировали обсуждения. Так что, возможно, было бы полезно добраться до чего-то подобного, прежде чем вдаваться в подробности.

Некоторые вопросы, которые я видел плавающими вокруг, или которые возникают у меня самого:

• нужно ли конвертировать AutoFixture в PCL или использовать что-то вроде общих проектов?
• какие платформы определенно необходимы или желательны в долгосрочной перспективе? (.NET, CoreCLR, UWP?)
• нежелательны ли условные компиляции для такого проекта?

@ploeh Я могу представить, что не на все эти вопросы вы можете дать ответ, но, возможно, основные участники внесут свой вклад в этот вопрос. @lbargaoanu Может быть, у вас есть какие-нибудь поводу ? Спасибо!

Я вижу, что забыл ответить на эту тему; примите мои извинения

Любая работа, которую мы можем выполнить для подготовки базы кода AutoFixture для .NET Core, приветствуется, если она не ухудшает базу кода и не вносит критических изменений.

Критические изменения все еще возможны, но они должны быть внесены в ветку _v4_.

В любом случае, мне нужно хорошее обоснование для любых изменений, которые кажутся неоправданными как есть. Хотя я не могу сказать, что внимательно слежу за ситуацией с .NET Core, похоже, что все еще много проблем, и я не стремлюсь вводить спекулятивные изменения, пока цель все еще движется.

Я не удивлюсь, если условная компиляция окажется необходимой, и я не против, пока мы можем поддерживать ее в здравом уме. Если я все еще могу запустить сценарий сборки, чтобы собрать все, что нужно опубликовать, вероятно, все будет в порядке. Я должен признать, что у меня нет большого опыта в этом.

Я также не знаю, какие платформы нужны. По сути, если кто-либо из сообщества отправит нам запросы на вытягивание, которые выглядят обслуживаемыми и расширяют возможности AutoFixture, мы рассмотрим их.

AFAICT, нам нужно будет настроить таргетинг на netstandard1.X который представляет собой набор API-интерфейсов, которые будут работать на любой платформе, которая их реализует (включая кросс-платформу netcore и сетевую платформу только в Windows).

См. Https://github.com/dotnet/corefx/blob/master/Documentation/architecture/net-platform-standard.md

В целом, чем выше число, тем больше API, но меньше поддерживаемых платформ. Вероятно, нам следует начать (продолжить) это обсуждение с понимания, на какой X мы должны нацеливаться в netstandard1.X .

Первый абзац этого документа меня немного пугает:

Мы разделяем первые планы на будущее создания библиотек классов .NET.
- https://github.com/dotnet/corefx/blob/master/Documentation/architecture/net-platform-standard.md

@moodmosaic меня тоже пугает, но дело в том, что общая концепция выбора API-интерфейсов, на которые мы будем ориентироваться, по сути, будет необходима в любом случае. netstandard просто дает им хорошо известные имена и согласованные подмножества, а также упрощает их описание. Это предполагает, что мы в первую очередь хотели быть портативными.

Например, если нам нужны API отражения для AutoFixture, список возможных целей будет сокращен. То же самое, если нам нужны параллельные коллекции. Эти платформы уже существуют (net framework full, Windows phone и т. Д.), Поэтому я думаю, что это не то, что может измениться, если мы обсудим, какие API нам нужны.

Я мог бы [повторно] начать разговор ... (отказ от ответственности: я тоже все еще изучаю этот материал)

Я начинаю с самого низкого ( netstandard1.0 ), который уже реализован на самом большом количестве платформ, и ищу причины, по которым мы не можем (или не будем) использовать эту платформу.

Насколько я понимаю, набор API netstandard1.0 довольно старый и ограничительный. В нем нет таких вещей, как:

• 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, здесь ?

Изменить: вот репозиторий инструментов анализатора http://dotnetstatus.azurewebsites.net

Извините за слишком много спама в комментариях, я остановлюсь :)

К вашему сведению, я запустил последний анализатор переносимости на локально созданном Ploeh.AutoFixture.dll из v4 4a7d415, и в итоге я получил следующее:

Вот некоторые изменения, которые он в настоящее время рекомендует:

Полный вывод здесь .

@ploeh Для многих широко используемых компонентов Asp.Net Core требуется как минимум netstandard1.3 . Примеры включают EntityFrameworkCore (использует 1.3) и Mvc (использует 1.6).

Если бы Autofixture использовал любой из них в качестве основы, я думаю, это было бы хорошо.

Есть ли сроки, когда может быть доступна поддержка .Net Core?

Мне удалось сделать сборку на .NET Core на базе ветки v4. Однако я не пробовал создавать тестовые проекты. Загляните в эту ветку, если хотите создать пакет.

FWIW, вот сравнение между AutoFixture / AutoFixture v4 и uhaciogullari / AutoFixture net-core . Выглядит хорошо 👍

На самом деле это не так просто. Существование project.json вызывает ошибку при сборке обычных проектов csproj прямо сейчас. Мы могли бы перенести все проекты в формат project.json, но я не уверен, что это хорошая идея для других проектов. Я не проверял их подробно, но подозреваю, что это плагины для некоторых других фреймворков для тестирования. Не знаю, поддерживают ли они и .NET Core.

Другое дело, что Microsoft объявила, что скоро откажется от project.json и вернется к csproj. Они обещают легкую миграцию, но хотите ли вы не торопиться, чтобы использовать этот временный формат? Это все зависит от вас. Я мог бы отправить пакет из моей текущей ветки, но, похоже, работа над версией 4 продолжается.

Есть способ построить без ошибок: # 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.

Есть ли какие-нибудь планы по рассмотрению этого вопроса?

Очень плохо писать тесты для стандартных сборок .NET без AitoFixture ...

Привет всем, это требует, чтобы кто-то из сообщества вмешался и внес свой вклад. Очевидно, что сейчас это сложно, потому что проблемы с моделью управления еще не решены (№703). Кто-то тоже должен вмешаться в этот фронт.

Играюсь с проблемой. Сейчас я сосредотачиваюсь только на Src \ AutoFixture.sln.

Моя стратегия - преобразовать Src \ AutoFixture \ AutoFixture.csproj в новый формат проекта (VS 2017), чтобы он мог поддерживать как .NET Framework, так и .NET Standard.

Я провел тест на переносимость .NET, и лучшей целью должен быть .NET Standard 1.5 (см. Прикрепленный файл).

Для начала я не буду преобразовывать тестовые проекты, хотя предполагаю, что в будущем мы, возможно, захотим запустить тест также в среде выполнения .NET Core.

AutoFixtureNetPortabilityTest.zip

Привет, @Kralizek - Просто к сведению - я добился успеха с netstandard1.3 в # 712

@Kralizek, моя ошибка, похоже, я начал планировать netstandard1.3 но на самом деле закончил с netstandard1.5 👍

Почти готово. В .NET Framework все тесты зеленые. Сборка в .NET Standard окрашена в красный цвет. : D

Встречал только эти категории проблем:

Генератор не нужен
Только один случай, MailAddressGenerator , потому что System.Net.Mail.MailAddress недоступен в .NET Standard. Решение: весь файл был "удален" с помощью #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 .

Использование Reflection для получения текущей сборки
Хорошо, это было непросто, потому что я не очень хорошо знаю макет проекта. Я использовал 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 , вы заметили, что мы намерены настроить таргетинг на> = net45 в ветке v4 ?

@adamchester нет ... Это не должно иметь большого значения, но я изменю целевую структуру. Спасибо за внимание! 👍

Кстати, я обнаружил, что System.Threading.Thread доступен в виде пакета .

Это открыло совершенно новый уровень ошибок компилятора ... приятно: P

.NET Standard 2.0 Надо добавить много api обратно, может стоит подождать?

Нет, это не так. .NET Standard 2.0 должен выйти в третьем квартале 2017 года. Мы находимся на расстоянии одного коммита от поддержки .NET Standard 1.5, почему мы должны ждать версии 2.0? Ведь генерация почтовых сообщений во время выполнения никогда не поддержит?

Кроме того, 2.0 в основном будет прокладкой фреймворка 4.6 с большим количеством исключений NotSupportedException.

@Kralizek Достаточно

FWIW, я являюсь участником, который добавил поддержку генератора почтовых адресов, и хотя приятно, что AutoFixture имеет поддержку для этого из коробки, это ни в коем случае не является жизненно важным аспектом AutoFixture и стоит усилий, направленных на то, чтобы ждать его.

ИМХО, наличие AutoFixture на минимально возможном стандарте .NET должно иметь наибольший приоритет. Продолжайте в том же духе, и если вам нужна помощь или поддержка в тестировании, я определенно могу вмешаться.

@Kralizek материал TypeInfo также присутствует в .NET 4.5, так что это поможет.

Укусила ошибка «Пакет AutoFixture 3.50.5 несовместим с netcoreapp1.1 (.NETCoreApp, Version = v1.1)» сегодня, когда начинал добавлять тесты в ряд проектов .NET Core.

Я прошу ответ типа «состояние автофиксации для ядра .net», который указывает, когда этот чрезвычайно полезный пакет nuget будет доступен для этой платформы (а .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 и .Net Core, чтобы мы могли посоветовать это другим людям 😉

Просто чтобы уведомить всех - поддержка .Net Standard для AutoFixture PR (# 773) была объединена с веткой v4 . Вы можете использовать пакет из нашей частной ленты .

Обратите внимание, что была перенесена только библиотека AutoFixture. Другие библиотеки клея появятся позже.

Можно ли переместить v4 на nuget.org, даже альфа-версию? Не удалось найти ничего похожего на autofixture, поддерживающего .netstandard.
Дата выхода версии 4 уже определена?

@RomanKernSW Не сейчас - мы еще не перенесли даже половину проектов (например, поддержка xUnit, NUnit, NSubstitute), так что еще рано. Также у нас есть план по изменению пространства имен , поэтому я бы предпочел сделать это _до_ того, как мы выпустим что-то публично, поскольку это будет серьезным перерывом между выпусками. С другой стороны, я хочу изменить пространство имен как можно позже, поскольку мы постоянно объединяем master с v4 и после изменения будет ужасно делать это.

У вас есть проблемы с приватным фидом? Вы можете добавить фид через NuGet.config если это сильно необходимо.

хм, я должен проверить, можно ли использовать nuget.config для восстановления nuget (.Net Core 2 - предварительный просмотр задачи в VSO). Прямо сейчас у нас есть один частный канал (VSO) с nuget.org без каких-либо файлов nuget.config. Нужно время, чтобы проверить это ...

.Net Standard 2.0 имеет режим совместимости с .Net Framework NuGets.
Я написал тесты .Net Core с AutoFixture 3.50.x и никаких проблем, так что
далеко.

@roarwrecker Замечательно , спасибо, что поделились! Это означает, что у нас есть больший буфер времени до тех пор, пока мы не развернем официальную поддержку NuGet: wink:

@roarwrecker, спасибо ... проблема не в .netstandard 1.6. Я мог установить nuget, но он никогда не компилируется без ошибок

Привет, ребята, не знаете, как далеко продвинулась работа над .NetCore, но можно ли получить альфа-версию на NuGet?

@selmendorfFrontline Копирование ответа отсюда :

Публикация предварительной версии в NuGet для меня немного болезненный вопрос. Хотя мы начали поддерживать .NET Core для большинства проектов , у нас есть план изменить пространство имен по умолчанию . Это было бы огромным изменением для наших клиентов, и весь клиентский код перестанет компилироваться. Вот тут-то и возникает путаница:

• если мы выпустим alpha с существующим пространством имен и изменим пространство имен между alpha и RTM, это запутает наших клиентов, поскольку они уже видели v4 с существующим пространством имен. Я хочу, чтобы наши клиенты чувствовали, что версия 4 всегда выпускалась с новым пространством имен по мере изменения модели управления.
• если мы выпустим alpha с измененным пространством имен, мы больше не сможем безболезненно объединить master с v4 веткой. В настоящее время мы фиксируем обе ветки, поэтому я бы хотел отложить изменение пространства имен до конца. Другой момент заключается в том, что наша документация в настоящее время не готова, поэтому люди могут просто не понять, почему весь импорт пространства имен недействителен и что им нужно просто выполнить замену текста. Это сделает их пугающими, и опыт будет не таким гладким, как хотелось бы.

Лучший способ решить эту ситуацию - не выпускать alpha и выпускать только RTM. К сожалению, я не могу предоставить вам точное ETA, так как это зависит от моих способностей (я работаю над этим проектом в свободное время) и наличия других участников (мои PR должны быть пересмотрены 😉). В голове я представляю релиз через месяц или два и надеюсь, что это произойдет в пределах этого диапазона. Этот проект был мертв около 9 месяцев из-за смены модели управления - это основная причина такой задержки поддержки.

Пожалуйста, пока что используйте пакет из канала предварительного просмотра. Вы можете настроить свой Nuget.config как было упомянуто выше, так что это должно быть проблемой.

Я собираюсь закрыть этот вопрос после того, как # 857 будет окончательно объединен. Наша окончательная таблица совместимости с .NET будет следующей:

| Продукт | .NET Framework | .NET Standard |
| ------------------ | ------------------------ | ------------------------ |
| AutoFixture | : 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 |
| AutoFoq | : heavy_check_mark: 4.5.2 | : heavy_minus_sign: |
| AutoMoq | : heavy_check_mark: 4.5.2 | : heavy_check_mark: 1.5 |
| AutoNSubstitute | : 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, и маловероятно, что они будут (большинство из них устарели). Я пытался перенести Idioms.FsCheck для поддержки как .NET 452 и .NET Standard 2.0 (насколько это технически возможно), но не смог заставить его работать. Похоже, что F # SDK все еще довольно груб и нам нужно дождаться новых выпусков. Компиляция и загрузка проекта просто терпят неудачу после того, как я определил узел TargetFrameworks .

Если ни у кого нет другого видения, я буду следовать этому плану 😃 Я также чувствую, насколько мы близки к релизу и сколько еще осталось позади 😊

Давай, давай, давай!

Я пытался портировать Idioms.FsCheck для поддержки как .NET 452 и .NET Standard 2.0

Вы пробовали перейти на более новую версию 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. Поэтому я бы хотел отложить поддержку .NET Core со стороны FsCheck до лучших времен.

@Kralizek Пожалуйста, посмотрите ответ несколькими ответами выше .

Только что проверил в VS 2017.4 и по-прежнему не может настроить таргетинг на несколько фреймворков для проекта F #. Поэтому я пока закрываю этот вопрос, поскольку мы поддерживаем .NET Core для всех других проектов.

JFYI: я выпустил v4 rc1 для NuGet, чтобы вы могли использовать и тестировать без необходимости играть с настраиваемым фидом.