Ссылка на стандарт .NET Standard API

UPDATE:

Теперь это выглядит как открытая проблема. Поэтому я предполагаю, что до тех пор, пока это не будет сделано, мне придется полагаться на . Ссылка на .NET Core API и молиться, я не удалю один из 43 APIs that .NET Framework 4.6.1 doesn't support но официально предполагается, что...

Также, полагаясь на ссылку на .NET Core API и учитывая то же, что и в стандарте .NET, может быть очень неожиданным. Например, когда я смотрю на список пространства имен, я вижу System.Drawing, но при нажатии на него мы понимаем, что это почти пустое пространство имен содержащий только 6 структур.

Есть ли несколько пространств имен? Я не знаю, что мне нужно сравнить .NET core и документацию .NET Framework, чтобы получить ответ.

ОРИГИНАЛЬНАЯ ПОЧТА:

Я пытаюсь найти ссылку стандартного API.NET.

В на этой странице есть только ссылки на .NET Core API reference и .NET Framework API reference.

Да, я искал, и я прочитал другие вопросы. Например этот ответ указывает на ссылку .NET Core API вместо стандарта .NET и то же самое в Подача фида Github

Но .NET Core и .NET Standard отличаются..NET Core в реализации .NET Standard API.

Одна из больших проблем, которую я вижу здесь, например, основана на официальной документации ..NET Framework 4.6.1 реализует .NET Standard 2.0

Хорошо, отлично, за исключением того, что .NET Standard Github readme page также говорит

С другой стороны,.NET Standard 2.0 добавляет много API, которые .NET Framework 4.6.1 уже поддерживает. Дельта выглядит следующим образом:

.NET Standard 2.0 добавляет 14994 API, которые .NET Framework 4.6.1 уже поддерживает

.NET Standard 2.0 имеет только 43 API, которые .NET Framework 4.6.1 не поддерживает Первоначально мы планировали просто исключить эти API из .NET Standard 2.0, чтобы упростить понимание того, что будет работать на .NET Framework 4.6.1.
Однако мы получили много отзывов об этом. Вы сказали нам, что в этом решении очень сложно рассуждать о стандартах .NET Standard. Таким образом, мы решили упростить это:

.NET Standard 2.0 будет строгим надмножеством .NET Standard 1.6. Другими словами, между .NET Standard 2.0 и 1.x не произойдет никаких изменений.

.NET Framework 4.6.1 позволит ссылаться на двоичные файлы, которые скомпилированы против .NET Standard 2.0. Учитывая количество API, которые .NET Framework 4.6.1 не будет поддерживать, является низким и что все это совершенно новые API с низким уровнем принятия, мы считаем, что это намного лучший компромисс.
Вы можете использовать порт API для сканирования данного приложения, чтобы убедиться, что код в приложении не зависит от этих API.

И что? Их решение этой проблемы to scan a given application? Поэтому, если я начну новый проект, учитывая тот факт, что у меня еще нет кода, я бы нацелился на .NET Standard и молился, чтобы я не получил неподдерживаемые API, которые должны быть?

Также есть другие случаи, подобные этому в других средах, таких как Xamarin или UWP? Что это значит vNext точно в столбце 2.0? Должен ли я беспокоиться о других неподдерживаемых API в других рамках, потому что Considering the number of APIs that [Framework name] will not support is low and that these are all brand-new APIs with low adoption we believe this is a much better trade-off?

Самый близкий ответ, который я могу найти на этот вопрос, - это посмотреть зависимости NETStandard.Library NuGet. Однако это дает мне зависимости версии 1.3 (не 1.6 или я не очень понимаю этот раздел), и это не дает мне ссылку на API следующего 2.0, которые должны быть уже определены.

Нельзя ли иметь полный документированный список API действительно для каждой версии .NET Standard? Единственная цель .NET Standard - предоставить разработчикам эту очень важную информацию, поэтому почему я не могу ее найти?

Ответ 1

Существует прекрасная веб-страница, поддерживаемая PM для BCL (Immo Landwerth). Он показывает все API, их текущие реализации на всех воображаемых платформах (.NET Framework,.NET Core, UWP, Mono,...) и их статус в .NET Standard Versions, включая план для 2.0.

http://apisof.net (образец для списка)

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

Дельта от 1,4 до 1,5: https://github.com/dotnet/standard/blob/master/docs/versions/netstandard1.5_diff.md

Дельта от 1,5 до 1,6: https://github.com/dotnet/standard/blob/master/docs/versions/netstandard1.6_diff.md

Не беспокойтесь о проблеме 4.6 и версии 4.6.2. Когда я правильно помню, они будут решать эту проблему.

Об озабоченности касается рисования: действительно самая неприятная проблема. System.Drawing основан на GDI и, следовательно, недоступен везде. Существуют альтернативы для общей задачи. Не забывайте, что большинство рендеринга - это клиентский материал и, следовательно, не совсем используемый вариант стандарта, а скорее конкретная модель приложения.

Ответ 2

Я пытаюсь найти ссылку стандартного API.NET.

Это здесь. Например, все API-интерфейсы для netstandard1.0. Это не так хорошо, как документы MSDN. Они работают над этим. Но если вам нужен список конкретных API, он там.

Их решение этой проблемы заключается в сканировании данного приложения?

Ну, я думаю, это намного проще, чем изучение каждой строки исходного кода и поиск его в документе...

Итак, если я запустил новый проект, учитывая тот факт, что у меня еще нет кода, я бы нацелился на .NET Standard и молился, чтобы я не получил неподдерживаемые API, которые должны быть?

Если вы нацелились на netstandard, вы не сможете вызывать какие-либо API-интерфейсы, которые не находятся в вашей версии netstandard. Как правило, вы должны начать с таргетинга netstandard1.0 и только двигаться вверх, если вам нужны дополнительные API.

Что касается "неподдерживаемых API", это совершенно другой вопрос. В этом случае вы говорите о платформе (например, Xamarin.Android 7.0 или .NET 4.6.2), которая объявляет поддержку данной версии netstandard, но бросает NotSupportedException во время выполнения для некоторых из API. К сожалению, эта часть истории очень много. Какой вид инструмента у нас будет пока неизвестен. Сегодня ничего нет.

Также есть другие случаи, подобные этому в других средах, таких как Xamarin или UWP?

Да. У Xamarin всегда было это - они никогда полностью не поддерживали .NET API. UWP будет иметь по крайней мере те же ограничения, что и .NET 4.6.2.

Что это значит vNext точно в столбце 2.0?

Это означает, что netstandard2.0 не будет поддерживаться текущими версиями этих платформ, но они ожидают выпуска будущей версии тех платформ, которые будут поддерживать netstandard2.0.

Должен ли я беспокоиться о других неподдерживаемых API-интерфейсах в других рамках

В этот момент я не стал бы волноваться. В конечном итоге будет какая-то история вокруг обнаружения неподдерживаемых API. Вы можете получить довольно далеко сегодня, просто запустив APIPort как шаг после компиляции.

Ответ 3

netstandard2.0 в основном определяется как netstandard1.6 плюс те методы в mscorlib.dll, System.dll или System.Core.dll как в .Net Framework 4.6.1, так и в текущей версии Xamarin. Все еще происходят небольшие изменения, которые можно увидеть через историю фиксации и PR в https://github.com/dotnet/standard/

Методы, существовавшие в netstandard1.6, но не в .NET 4.6.1, были отмечены как невидимые для intellisense, чтобы предотвратить путаницу у новых разработчиков. Но они существуют, поэтому вы можете успешно скомпилировать, если будете писать код в любом случае. Это был компромисс, достигнутый для "но он не будет работать на netfx" и "но я не могу обновить свою библиотеку netstandard1.6".