@atsushieno (coreclr読書会 / Xamarin) using NuGet and PCL with Xamarin

NuGet? 開発者用パッケージマネージャ ライブラリ利用者: パッケージ経由で 参照を追加 ライブラリ開発者: パッケージを作成 して配布可能 https://blog.xamarin.com/xamarin-studio-and-nuget/

Libraries are platform dependent .NET Framework用のライブラリ→Xamarinでは使えない Xamarin環境にはXamarin用のライブラリが必要 var q = new MessageQueue(); mscorlib.dll System.dll System.Core.dll System.Xml.dll System.Windows.dll System.Web.dll ... System.Messaging.dll mscorlib.dll System.dll System.Core.dll System.Xml.dll monotouch.dll !!!

packages/libs for Xamarin ● Component Store ○ 審査アリ / バイナリ、ドキュメント、サンプル / 有償 or 無償 / 公開 ● NuGet ○ 誰でも作れる / 公開 or 非公開 ● Github ○ ソース = 自分でビルド / 修正可能 / IDE統合なし

Glossary: files - packages.config ユーザー プロジェクトで利用するパッケージが列挙されたXMLファイル - *.nupkg NuGetのパッケージ アーカイブ (zip) - *.nuspec ライブラリのビルド（バイナリ）からnupkgを作成するための定義ファイル - NuGet.exe パッケージの取得と作成の両方に使えるコマンドラインツール - packages XSが、ダウンロードしたNuGetパッケージを格納するディレクトリ

Find packages for Xamarin from nuget.org あんまり簡単ではない… - plat.指定検索→できない(!) - キーワードで探す - FooBar + {Xamarin / Android / PCL} etc. - DLしたnupkgの内容を確認 - unzip -l packages/FooBar/FooBar.nupkg → lib/MonoAndroid403/*.dll

依存関係で破綻 X.dll -> Xamarin.Android.Support.v7.AppCompat 22.2.2 -> Xamarin.Android.Support.v4 22.2.2 Y.dll -> Xamarin.Android.Support.v4 21.0.0 Dependencies Hell

Why so... NuGetは.NETの一級市民ではない ● もともとASP.NET MVC3のついで ● MSBuildサポートがない ● 後付けのIDE統合 ○ NuGet.exe とIDEの間で一貫性を もたせるには調整が必要 ○ ファイルの同期なども微妙 ● パッケージ情報にplat.指定なし ○ 標準ディレクトリ構造もなし .NET Coreでは一級市民 cf.: NuGet: in the platform

Platforms? - Windows - .NET Framework { 2.0 ... 4.6.x } - Windows RT - Windows Phone { 7, 7.5, 8, 8.1 } - Windows Mobile 10 - Universal Windows Platform - Silverlight (まだ消耗してるの?) - Xamarin.iOS - Xamarin.Android - "Cross Platform" ... PCLs

PCL (Portable Class Libraries) ? とは? ● プラットフォーム間コード共有 (.NET Framework, Xamarin iOS/Android, Silverlight, UWP...) どうやって作るの? ● XS/VSでPCLプロジェクト (C#/F# [new in XS6.0]) ○ 他の言語? 依存dllも必要

PCL Versions and Profiles …標準化と平易化が必要

.NET Platform Standard 「プラットフォーム」の標準化 ● 標準APIの定義 ● 標準のバージョン策定 ● プラットフォーム「が」それを実装 ○ サブセットでも良い (「ガードレール」がある) ● 新しいプラットフォームは標準を実装する だけ ○ dotnet (fdn.) に追加してもらう必要はない profileXXX => dotnet => netstandard1.x Japanese Translation available

how about Shared Project? PCLs ● 単一のdllをどこでも使う ● 対象plat. APIの狭い部分集合 ● PCL(互換profile)のみ参照可能 Shared Projects ● ソースをplat.間で共有 ○ #if WP/IOS/ANDROID ● 全plat.用にビルド ○ PCLでは参照不可 ● plat.全APIが利用可能

PCLs vs. Shared Projects? Okay so thats a bit strong but in general if you don’t know what you should do, go PCL. If you have a strong reason to use a shared project, sure, but otherwise go PCL, your lack of #ifdef and spaghetti code will thank me later. Among other things, PCL will ensure that code you write is going to be portable not just to all current platforms, but any future platforms we might support as well. For me, the PCL is just too cumbersome for most uses. It is like using a canon to kill a fly. It imposes too many limitations (limited API surface), forces you to jump through hoops to achieve some very basic tasks. PCLs when paired with Nugets are unmatched. Frameworks and library authors should continue to deliver these(...)

Modern PCL development Dudes, that's an old discussion. PCLs can do more. Oh, how?

Bait and Switch: reference vs. implementation 参照アセンブリ 実装アセンブリ System.Xml.ReaderWriter.dll System.XML.dll System.Xml.XmlDocument.dll System.Xml.XmlSerializer.dll System.Xml.XPath.dll System.Xml.XPath.XmlDocument.dll System.Xml.XDocument.dll System.Xml.Linq.dll System.Xml.XPath.XDocument.dll App.cs App.dll 参照 実装 コンパイラ ランタイム cf. インサイドXamarin#13(BuildInsider)

TypeForwardedToAttribute: PCL Facades 参照アセンブリ (PCL) ファサード 実装 PCLにコンパイル plat.用にコンパイル plat.上で実行 public class XmlText { public override string Value { get { return default (string); } } ... [assembly: TypeForwardedTo( typeof(XmlText))] public class XmlText { public override string Value { get { // actual implementation } } ...

DroidApp .cs DroidApp .dll コンパイラ Stub.cs Lib.dll コンパイラ Droid.cs Lib.dll コンパイラ FormsUI. cs PortableUI. dll Lib.dll コンパイラ Bait and Switch: Forms app PortableUI. dll Lib.dll DroidApp .dll X.F.dlls X.F.dlls X.F.dlls X.F.dlls

Building PCLs using Bait and Switch technique 実装アセンブリはプラットフォーム別にビルド...? ... !!

Building PCLs using Bait and Switch technique ● 参照アセンブリ ○ 単なるAPIスタブを作るだけ ○ プロパティ - return default (T); ○ メソッド - throw new (InvalidOper/NotImpl/NotSupp/...)Exception(); ● 実装アセンブリ ○ コード共有 - Shared Projectでコードを共有可能 ■ もちろんPCLでも良い ■ プラットフォーム専用ライブラリを参照したい時に便利 ○ プラットフォーム固有コードはそれぞれに実装

using NuGet to easily resolve PCLs "bait and switch"ベースのPCLをどう参照する? ● iOSアプリ開発者はiOS実装dllを参照 ● Androidアプリ開発者はAndroid実装dllを参照 ● PCL開発者はリファレンス アセンブリを参照 ● ... (以下プラットフォームごとに異なる) ある程度再利用するならNuGetパッケージに NuGetなら全てまとめてパッケージ可能 / 参照のやり方は統一的 NuGet Serverはプライベートでも立てられる / myget.org etc.

Xamarin Plugins (Bait and switch) PCLをXamarinに応用。 NuGet / Github でDL可

Xamarin Plugins 作るなら? VSテンプレートが利用可能 (「Xamarin Pluginのコード」はない) 実装のabstractionもPCL Xamarin.Formsには依存しない

create nuspec and nupkg - 自作pluginのsamples - Xamarin.Plugin...びっくりするほど無い - PCLアプリケーション (X.Forms) - PCL Plugin dllはCopyLocalにしない - bait dllだから - プラットフォーム別実装 dllを参照する - create nuspec - 通常のプロジェクト用 - nuget spec FooBar.csproj - Xamarin.Plugin - solution item template - create nupkg - nuget pack your.nuspec

That's all, sir. Questions?