Runtime: System.Xamlを.NETCoreに移植する

ホレイ！ 公式の承認/承認！ そして、はい、私はそれらの言葉が「コミットメント」と同等ではないことを理解していますが、これは私がこれまでに見たものよりも間違いなく優れています。 @terrajobstあなたは私のヒーローです。 ：heart ：： heart ：： heart：

@cwensleyと@SuperJMN 、ここにいる全員の間で対話をするのは素晴らしいことです。 理想的には（私の観点から）、誰もが最終的に新しいXamlライブラリの1つのポート/バージョンを使用し、Xamlの異なるバージョン/方言を使用しないようにする必要があります。 これはリモートでも可能ですか？ そうでなければ大丈夫ですが、可能かどうかを確認したいと思います。 :)

また、私は現在「作業中のサバティカル（偉そうなクライアントLOLから）」を行っており、クロスプラットフォームのXamlだけで3〜4か月の予定があります。 私は文字通りフルタイムで働き、必要に応じてその時間中にこれを手伝うことができました。 原因のために何でも（そしてまた、私は良いタイミングの日和見主義者です！）

System.Xamlがオープンソースになった場合、コミュニティはこのプロジェクトの要件と設計目標に従って.netコアに移植できると確信しています。プロジェクトのメンテナは、コミュニティをガイドするだけで済みます。 .netコミュニティの力を活用しましょう。

@ Michael-DST、xamlの方言を1つ持つことが重要であることに同意します。 ただし、その実装は完全に異なる場合があります。 単一の実装での標準化は、実際にはコミュニティに依存します。

多くのバグ修正を含む、Monoの優れたSystem.Xaml（MITライセンス）実装のPCL259 / 136ポートであるPortable.Xamlの場合。 アイデアは、同じAPIを使用してMSのSystem.Xamlが実行するすべて（読み取り/書き込みを含む）をサポートすることですが、必ずしもそれに限定されるわけではありません。

拡張機能の例として、Portable.Xamlは、リスト内のアイテムでの型コンバーターの使用をサポートします。System.Xamlは、さまざまな型をサポートするためにカスタムコレクションを使用して実装する必要があるIList.Add（object）を使用します。

@cwensley私はこれについて無知だと主張しています...しかし、.NET CoreとPCLの違いは何ですか？ 同じだと思いましたか？ つまり、特定のPCLプロファイルで設計した場合、それが.NET Coreに引き継がれることを理解していました...これは少し前のことです（正直なところ、.NETCoreからRTM / Wを待っていました）。さあ、リフレッシュするのに良い時期です。 ：P

Portable.Xamlは確かにmonoのSystem.Xamlの移植版であり、OmniXamlはゼロから書き直されたものであり、解析の分野で新たな注目を集めていることを理解/印象しています。 理想的には（私自身の観点から）2つを何らかの形でマージするのは素晴らしいことですが、それが2つの拠点間で実現可能であるか、あるいは望ましいかどうかさえわかりません。 私の考えでは（洞窟探検/分析を行わずに）、基本的に一方の成熟度（Portable.Xaml）ともう一方の新しい辛さ（OmniXaml）をマージしています。

@ Michael-この投稿によると、DST PCL259は確かに.NETCoreと互換性があります。 Portable.Xamlのnugetパッケージにターゲットとして\lib\dotnetを既に含めているので、テストはしていませんが、.NETCoreではそのまま使用できるはずです。

OmniXamlを調べる時間がありませんでしたが、それが実際にゼロから書き直されたものである場合、2つのプロジェクトをマージすることは意味がないかもしれません。これは、まったく異なる方法で行われたと確信しているためです。 また、Portable.Xamlがほとんどそのままで完成している場合、そのようなものの利点もわかりません。 私は間違っている可能性があります（;

:)はい、私はここでオプションを模索しています。また、実際にオープンソースの世界にいることで私の無知に対処しています。 複数のコードベースが同じことをするという考えは嫌いです。 そして、特にXamlコミュニティが小さい場合、最初から断片化されてしまうのは残念です（何かが成功しすぎて、それ自体がうまくいかない場合は、そうなるはずではありませんか？！笑）。 とにかく、 @ SuperJMNがこれを引き受けるのを聞くのは素晴らしいことです。 私は彼が彼の新しい修正にかなりしっかりしているように見えたことを知っています。 たとえば、マークアップ拡張機能にIServiceProviderの代わりにMarkupExtensionContextを使用することは、既存のコードをこの新しい世界に移植したい人にとっては重大な変更になります。

明確にするために、すべてのPCLプロファイルは.NETCoreと互換性があります。 現在の契約セットとファクタリングは、PCLプロファイルの進化形です。 これは、.NET Coreとすぐに互換性がない「古いスタイル」のポータブルライブラリ（mscorlibなどに対してコンパイルされたもの）には適用されません。

@ Michael-DST

@terrajobstあなたは私のヒーローです。 ：heart ：： heart ：： heart：

あなたの熱意に感謝しますが、誰でもこのようなリクエストを提出できることを明確にしたいと思います。 問題を提出し、仕事を依頼するために、私たちからのスポンサーや承認は必要ありません:-)時間を節約するために自分で提出しただけで、非常に怠惰ではありません（「バグを自由に提出してください」）:-)

笑@terrajobstそれは大丈夫です、私の熱意は半分冗談で半分深刻です... MSFTは、多数の投票と広範な会話にもかかわらず、この問題について基本的に1年近く沈黙しています。

それで、あなたがほぼ一年の間独房に閉じ込められた誰かのドアの下で食事を滑らせるのと同等のことをしたと考えてください。 ：stuck_out_tongue：

[編集：そのアナロジーを読んだ後（そしてそれが以下に引用されているのを見た後）、それはひどいものであり、おそらく私がその時に読んでいた記事に影響されていると言わなければなりません-いまいましいニュース、なぜあなたは私に影響を与えなければならないのですか？！ より良い/関連性のあるものは、おそらく、1年間の煙霧で走った後、エンジェルラウンドから非常に必要な現金の注入を受けることでしょう。]

cc： @ Harikm86 、System.Xamlの所有者

XAMLが大好きです。 これは、Silverlight（はい、私は言った）からWindowsワークフロー、そして今では新しいユニバーサルアプリプラットフォームに至るまで、あらゆるものに対応する優れた宣言型言語です。 Coreに移植すると、XAMLに依存する他のテクノロジーを移植できるようになります。 これが必要です！

@rschieferのサポートを聞いてうれしいです！ ご意見ありがとうございます。 このスレッドに参加し、会話/方向付けを手伝ってくれることを知っている他のXaml開発者がいることを確認してください。

私はSilverlightのファンでもあり、2011年から次の化身を追いかけています（恥知らずなプラグイン：Visual Studioチームに、次のよりスマートな形式のSilverlightを見たいことを知らせたい場合は、投票して知らせてくださいここで知っている）。

少し時間を取って、「Xaml」と言うときは、.NET 4.x +（または「System.Xaml」）にあるXamlシステム/機能セットを目指す必要があることを確認したいと思います。 Silverlight5のXamlでさえ実際に機能します。

（もちろん、 OmniXamlに見られる新しい改善を追加することも望まれます。）

それ以来、私たち全員が苦しんでいるので、インターンのチームによって移植されたに違いない、UWPの「新しい」、ろくでなしのバージョンでない限り（上記の私の投稿で言及した投票を参照してください）。

私はそれを「Xaml」システムと呼ぶことさえ躊躇します。なぜなら、それは幸運のためにいくつかの追加のトークン解析を備えた実際のXMLです（これは明らかに必要です）。 おもしろい事実：UWPのXamlシステムは、最終的にビルドプロセス中にSystem.Xamlアセンブリを使用します。 うーん...＃アイロニー。

理想的には、このポートが配置されると、UWP Xamlシステムは完全に非推奨になり、代わりにこれを使用します。 次に、恥ずかしいXamlの歴史の章を私たちの後ろに置くことができ、多くの開発者が喜ぶでしょう。

Silverlightをより新しく、より良い形式に戻すことも悪くはありません。 :) :) :)

@ Michael-DST

それで、あなたがほぼ一年の間独房に閉じ込められた誰かのドアの下で食事を滑らせるのと同等のことをしたと考えてください。 ：stuck_out_tongue：

十分に公平：smile：

@ Michael-DST

私は実際にこの時点までUWPを避けてきましたが、多くの変更があり、UWPが独自の「バージョン」のXamlを使用していることを忘れていました。 思い出させてくれてありがとう。

私は完全に同意します。System.Xamlを移植する必要があります。そうすれば、実際のXamlを使用するようにUWPを修正できます。

私は完全に同意します。System.Xamlを移植する必要があります。そうすれば、実際のXamlを使用するようにUWPを修正できます。

申し訳ありませんが@ terrajobst 、@ rschieferに新しいヒーローがいます。 ：smile ：： smile ：： smile：

議論してくれてありがとう。 これは私にとって非常にクールです（しかし、私は簡単に感動することができました！）。

@ Michael-DST @rschiefer

@helmsbはい！ 笑ハハ！

FWIW、ウェブ（Angular.js）、アプリ（Android）などの競争力のあるGoogleの人気のマテリアルデザイン技術もオープンソースで利用できます。 この議論が上司や上司のような実体を説得するのに役立つことを願っています。

@dsafどういう意味ですか？

FWIWこの問題については、本日投稿された「 Is the Tide Turning onproject.json？ 」というタイトルの記事で参照しました。 、Xamlが、技術的およびMSFTビジネス/ IPの両方の観点から.NETオブジェクトを記述するための推奨メカニズムである方法を見てください。

みなさん、Xamarinの取引はどうですか？ この問題は今後数か月で非常に忙しくなるだろうと何かが私に教えてくれます。 ：笑顔：

必ずしも。 UWPのXamlまたはXamarinのXamlのフレーバーがクロスプラットフォームライブラリになる可能性は十分にあります。 これは、System.Xamlの移植も、純粋に管理されたXamlの実装も行われない可能性があることを意味する場合があります。

XamarinのXamlシステムはクローズド/内部ですが、System.Xamlほど成熟していません。 コード自体はかなり薄っぺらです（彼らの側で認められた懸念-実際にそれを使用することは、それが閉じられている/内部である理由の1つです）。 さらに、これはBindingObjectと緊密に結合されており、POCOシリアル化などを実行する場合は禁止されています。

そして、上で概説したように、UWPのXamlシステムはひどいものです。 私が知らないことをあなたが知っている何かがない限り。 ：stuck_out_tongue：

「純粋に管理されたXaml実装」とはどういう意味ですか？ FWIW、ここでの私の期待は、System.Xamlの直接の1：1ポートではなく、System.Xaml、Xamarin.Core.Xaml、そして...まあ、私はUWPのXamlと言うでしょう、しかし...：wink：

内部的には、WPFやそのようなXamlよりもUWPのXamlが優先されると聞いていますが、Microsoftのチームが異なれば意見も異なる可能性があります。 DotNetのXamlは間違いなくより強力で柔軟性がありますが、これらの記述子を使用する場合と同様に、UWPが非常に縮小される理由である欠点が伴う可能性があります。
また、純粋に管理されていないということで、DotNet専用ではないという点でUWPのXamlの優れた点の1つに言及しています。 したがって、将来のMicrosoft.Xamlは、管理されたファサードを備えたクロスプラットネイティブ実装である可能性があるため、DotNetの外部で使用できます。 （これは、この将来のライブラリがCoreFXのコンポーネントとして出荷されることが決定されない限り、dotnet / corefxに含まれることも除外します）

わかりました、私は混乱しています。 あなたが.NETと言うとき...あなたは4.6を話しているのですよね？ 私の理解では、これは.NET Core Xamlライブラリ用であり、その性質上、クロスプラットフォームで.NET（4.6）専用ですか？ 「DotNetを含まない」とは、「DotNetを含む」という意味ですか？ 二重否定。 ：stuck_out_tongue：.NET4.6ではUWPXamlを使用できないため、これは明らかに当てはまりません（：stuck_out_tongue：も使用しないでください）。

ここで私が間違っていることを教えてください。 さらに、ここでの良い目標は、XamlをCoreFXの一部として出荷することです。 しばらくの間、これについていくつかの議論が行われてきました。 -そして確かに、私が@ RichiCoder1と間違えていなければ、あなたはそのスレッドでこれを正確に行うための投票権を持っています...私は以前にあなたのタグをどこで見たのか疑問に思いました！ ：笑顔：

また、UWPのXamlに対する内部的な傾向も聞いたことがあると思いますが、それは、そのスレッドの前後でコミュニティの議論が始まる前のことでした（ ala Tim HeuerのTwitterディスカッション）。 それ以来、針は確実に動いています。 少なくとも、もっと良かったです！ 笑。 「XamlはUI用である」と誤解している人もいれば、それがどのように機能するかを理解している人もいます。 ：stuck_out_tongue：

DotNetとは、コアとフレームワークを含むDotNetを意味します。 また、UWPアプリの外部ではUWP Xamlを使用できないことに気付きました。私は、C ++ UWPアプリで使用できることについて言及していました。 つまり、DotNet専用ではないと言うときは、C ++（または潜在的に他の言語）から使用しようとしていることを意味します。 また、XAMLを所有するチームがUI以外のユースケースを真剣に検討しない理由は、それがまれであるか、場合によってはMicrosoftやパートナーと積極的に悪意を持っているためだと思います。 私の個人的な意見ではありませんが、表現力と力に感謝しています。

OK、素晴らしい@ RichiCoder1ご説明ありがとうございます。 私は今_ほぼ_完全にあなたをフォローしていると思います...あなたが「フレームワーク」と言うとき、あなたは4.6を意味しますか？

私の見解では、内部チームがUIの外部でそれを使用することは珍しいと感じる理由の一部は、Timの投稿が示すように、開発者とのエンゲージメントが不十分であることに関係していると言えます。 私はまた、約1年ほど前まで、MSFTを利用することについて本当にうんざりしていなかったので、これについても罪を犯しています。 実際、Timのツイートは、Windows 8.0以降、Xamlシステムが完全に異なり、本来あるべきものとは異なることをすべての人に個人的/個人的に不平を言った後、私が行った投票に関するものでした。 UWP（Windows 10）Xamlは基本的に同じであるといううなり声を聞いたとき（3年間革新や改善がなかった後）、それが私がステップアップしたときです。 後から考えると、もっと早いはずでした。

それは主要な学習の教訓だったと言っても過言ではありません。 私は今、生態系にはるかに統合されており（または少なくとも私がそうであるように感じています）、聞いているように感じています。 実際、私が4か月ちょっと前に行った_非常に重要な_投票は、今週初めに権威あるVisualStudioチームによってレビュー中としてマークされました。 私の世界が揺らいでいると言うのは控えめな表現です。 ：笑顔：

フレームワークでは、デスクトップ.N​​etを参照するために使用しています。 これは、コアとフルフレームワークを区別するための一般的な方法のようです。

同意します。 マイクロソフトの最近のすべての動きの良いところの1つは、開発者とのより良いエンゲージメントをほぼ強制することです:)。

それについて自分自身がとても興奮しています！ 今、それがどのように再生されるかを確認するだけです。 これは、共有プロジェクトを使用してUWPアプリを除いてXamarinツールをファーストクラスにすることから何かを意味する可能性があります。あるいは、それよりも高いレベルの何かを意味する可能性があります。 時間（そして私が推測する//ビルド）だけが教えてくれます。

OKかっこいい...情報ありがとうございます。 ：+1：

// build ...は確かに。 :)個人的には、UWPに基づいた（大まかに？）新しいモデルをすべて見て、新しいXamarinの良さを利用してiOS / Droidに移行したいと思います。 より強力なXamlモデルも問題ありません。 結局のところ、このスレッドは4月28日以降まで静かにしておくべきだと思います。 ：stuck_out_tongue：

私はあなたたちがそれをすることができることを願っています！ :)

UWPの人たちは、.NETコードをプルインしないXAML実装をより簡単に採用するだろうと思います（そのコードが.NET Coreのものであったとしても）。

自己完結型のブラックボックスのように（またはUWPにのみ依存しますが、UWPは[まだ]クロスプラットフォームではないため、それは望ましくありません。それがあったとしても、.NET /で実行できるマネージドバージョンを見逃すことになります。 Silverlight [アプリをWin10ターゲットだけにロックすることはできません]）。

ただし、抽象化レイヤーと、XAMLのさまざまなアプリケーション（UWP UI、ワークフロー、WPF / .NET、Silverlightなど）用のプラガブル/ドライバーを使用しない限り、これは多かれ少なかれユートピックだと思います。 DirectXがHAL（Hardware Abstraction Layer）を介したマシンのように見えるように、HEL（Hardware EmulationLayer-http：//www.developer.com/net/asp/article.php/968461/Whatの言及を参照）の可能性も開きます。 -is-DirectX.htm）。 もちろん、注意しないと、パフォーマンスに関して地獄への扉が開かれる可能性もありますが、DirectXがそれを引っ張ることができるので、そのようなアーキテクチャは悪くないと思います

System.Xamlを.NETCoreに移植するための+1。
将来的には、単一の統合XAMLダイアレクト（.NET Xaml、UWP Xaml、Xamarin Xaml）がすべてのプラットフォームで使用されることを期待しています。
これを実現するには、System.Xamlの.NETCoreバージョンが必要であると考えています。

+1

大量の通知アラートを回避するために、GitHubの個々のコメントを+1して、目前のトピックに対する関心/反応を示す新しい方法があります。

Haha @ jasonwilliams200OK私は、強力なクロスプラットフォームのSystem.Xamlソリューションへの基本的な関心を表明するコミュニティメンバーからの大量通知アラートを気にしません。 ：angel：多分他のトピック私はあなたの痛み/不快感/欲求不満を共有します。 ：ウィンク：

いずれにせよ、有効な（そして価値のある）ポイント。 原因として：+ 1：を追加しました。

@ jasonwilliams200OK

これを呼んでくれてありがとう！

FWIW、Xamarin.Formsチームをここでの会話に招待しました。
https://bugzilla.xamarin.com/show_bug.cgi?id=26740

または、どちらかといえば、全員に会話を_ここ_に_認識させます_。 ：笑顔：

この投稿のコメントでいくつかの素晴らしい議論がありました：
https://blogs.msdn.microsoft.com/dotnet/2016/05/06/net-core-rc2-improvements-schedule-and-roadmap/

基本的に、Visual Studioで進行中のように見える新しいプロジェクトシステムのJSONとXaml（やったー！）。 気軽に参加してください。:)これが別の見方をしているのを見てとてもうれしいです。

@ Mike-EEE、このロードマップもご覧ください： https：//github.com/dotnet/roslyn-project-system/blob/master/docs/Roadmap.md。 Roslynを利用した新しいプロジェクトシステムは貴重なものになるでしょう。

おっと...私が今これについて聞いているのはクレイジーです。 これは、今後の投稿で予定されている詳細情報に関して、前述のブログ投稿でスコットハンターが言及していたものである必要があります。 見て良かった。 Roslynの力が成長します。 ただし、Xamlでシリアル化されたプロジェクト定義に関するいくつかの問題を確認する方が快適です。 ：ウィンク：

そのリポジトリのreadmeを参照してください： https ：//github.com/dotnet/roslyn-project-system#welcome -to-the-roslyn-c-and-visual-basic-project-system（およびVSMSDNブログへのリンク）、MEFを使用してさまざまなコンポーネントを置き換えることができるようです。これにより、XAMLで記述されたプロジェクト定義を解析するための追加のシリアライザーを挿入できるようになります。 個人的には、JSONのノイズが少ないため、プロジェクトのプロパティや依存関係などを記述する場合は、XAML / XMLよりもJSONを好むようになりました（YAMLはJSONよりもノイズが少なく、lang標準はstd-​​JSONとは異なりコメントをサポートしています。しかし、ドットネットの世界では、YAMLやインデント対応の構文を持つ他の言語はまだ牽引力を獲得していません）

個人的には、XAML / XMLよりもJSONを好むようになりました

安全！ この男を削除します!!! ええと、つまり... :)

私はすべて、両方の世界の長所を生かしてくれています。 @SuperJMNと@Grokysはこれについてもっと話すかもしれませんが、OmniXamlでは、冗長でおしゃべりにならないように努力していると思います。

JSONを使用した私の問題は、JSON自体を使用したものではありませんが、.NET構成の基礎でもあったその設計アプローチ（私はそのインスピレーションであると思います）、つまり、オブジェクトのスキーマは「さらに別のアーティファクト」です。開発者は、クラス定義を管理/維持し、_しない_必要があります。 つまり、Xamlプログラミングでは（ご存知のとおり）、クラス定義はドキュメントスキーマです。 結果として、これはドキュメントの開発に非常に自然な感触を与え、ツールの作成にも役立ちます。

開発者の正気は言うまでもありません。 ：smile：あいまいなスキーマドキュメントを追跡し、それをインストールして最も単純なインテリセンスを機能させる方法を理解する必要があることほど、私を怒らせることはありません。

私がJSONで抱えているもう1つの問題は、JSON固有ではなく、Webの考え方の多くであり、それが命名規則です。 .NET構成もこれに悩まされていました。 つまり、次のようなPOCOを定義している可能性があります。

public class MyPoco {
    public string Property {get; set;}
}

そして、そのJSON（またはapp.config）は次のようになります（これが間違っている場合は、これについて教えてください！）：

{
 { "property": "Hello world I have inconsistent naming conventions!" }
}

ここでも、Xamlはクラス定義とそのシリアル化された対応物の間で調整されているため、私はそれを好みます。

.NET構成は、その設計がすべての構成エンティティに対して4つのアーティファクトを生成したため、最悪だったと言わざるを得ません。

1. web /app.configの要素
2. どういうわけか魔法のようにweb / app.configにリンクしなければならなかった.xsdファイル（私はそれを機能させることができませんでした！）
3. app / web.configから値を取得した（そして一貫性のないキャメルケースをPascalCaseにマップしたConfigurationElementおよび/またはConfigurationSection要素-ああ、狂気！）
4. 最終的に構成要素から配線されたPOCO。 （WHEW！）

.JSONドキュメントでシリアル化されているPOCOオブジェクトがあるかどうか、または上記で概説した無関係なマッピングも発生しているかどうかを知るために、JSONのプロジェクト設計を十分に研究していません。 あなたがこれに対する答えを知っているなら、私は聞きたいです。

いずれにせよ、Xamlは、2つのアーティファクトのみを必要とすることにより、この設計を改善します。

1. クラスファイル（.cs）
2. データファイル（.xaml）

最後に、readmeへのリンクに感謝します。 私はもう一度、ファイルが求めることをまったく行わない「あの男」です。 ：笑い：

.JSONドキュメントでシリアル化されているPOCOオブジェクトがある場合、または上記で概説した無関係なマッピングも発生している場合。 あなたがこれに対する答えを知っているなら、私は聞きたいです。

[DataContract]属性と[DataMember]属性を考慮すると、.NET Framework（BCLレベル）がJSONやその他のデータセライライザーを支援していると思います。 ただし、ネイティブ/低レベルのJavaScriptオブジェクトリテラル<-> JSONからJavaScript（および他の多くの言語）またはCSONからCoffeeScriptとしてのコンパイラによるC＃POCO遷移のサポートはありません。 ただし、すべてのXPATH XQUERY XSLTタイを使用するXMLとは異なり、JSONにはデータを検証するスキーマの概念があり、JSON.netはそれをチャンピオンのようにサポートします。

C＃6以降については、これらの問題/提案をご覧くださいhttps://github.com/dotnet/roslyn/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+author%3Agafter+辞書、特にhttps://github.com/dotnet/roslyn/issues/6949で、その中のリンクをたどってください。 新しいC＃6ディクショナリ初期化構文とこれらの提案により、C＃は意味的にJSONに適したものになっているようです。

.NET構成が最悪だったと言わざるを得ません

同意します。ASP.NETチームによってプラグアンドプレイパッケージとして導入された「構成」および「IOption」パターンもお楽しみいただけます： https ：//github.com/aspnet/Configuration、https：//docs.asp.net/ en / latest / Fundamentals / configuration.htmlは、古い悪名高いXMLバウンド構成マネージャーに取って代わります。

JSONにはデータを検証するためのスキーマの概念があり、JSON.netはそれをチャンピオンのようにサポートします。

スキーマとしてのクラス定義のように聞こえます。 :) :) :)

C＃は意味的にJSONに適したものになっているようです。

確かに、_any_オブジェクトはすでにJSON対応です。 JSONは、意図されていることを実行するのに最適です。つまり、オブジェクト定義を簡潔で人間が読める形式で表記します。 そして、JSON.netがこの目的を達成するのに素晴らしい仕事をしていることは間違いありません。 _applications_の説明に入ると、より良い言葉がないために、この会話が巻き込まれ始める領域に入り始めます。 ：笑顔：

最後に、ここには2つのシナリオがあります（少なくとも私にとっては）。サービス境界間で転送されることを意図したオブジェクトの説明（軽量）と、それらのオブジェクトを作成するアプリケーションの説明（重要）です。 私は個人的に、可能な限り一貫性を保ち、コンテキストの切り替えを最小限に抑えるよう努めたいと思っています。 オプション（ IOptions ？： laughing :)を開いたままにして、開発者が自分にとって最も意味のある形式を選択できるようにする（そして、開発者が最も効率的に感じるツールを使用できるようにする）限り。 ）そして、私たちは皆ここで勝ちます。 ：+1：

UWP XAMLは、従来の.NET WPFXAMLと比較して機能が少なくなっています。 私が最も見逃している機能の1つは、TypeConvertersです。

https://msdn.microsoft.com/en-us/library/bb546926（v = vs.90）.aspx（この記事はWPF TypeConverters用です）で提案されているように、独自のTypeConverterを作成しようとしました。

UWPでは、この「不明なタイプ 'car' in XML namespace'using ：App2TypeConverters '」を使用します。

        <ListBox>
            <local:car></local:car>
        </ListBox>

UWPにカスタムTypeConverterを追加することは本当に不可能ですか？ または、回避策はありますか？ XamlCompilerが内部IServiceProviderを使用してTypeConverterを登録していることをどこかで読みました。 多分それはどういうわけかそれに登録することができますか？
また、XAMLコンパイルに関する背景についてもっと知りたいと思っています。 XAMLは引き続きBAMLに生成されますか？ どういうわけかXAMLコンパイルにフックできますか？
したがって、System.Xamlを開いてください。

Sooooooo ...これは、System.Xamlが最終的にパーティーに参加することを意味しますか？ ：smile ：： smile ：： smile：
https://blogs.msdn.microsoft.com/dotnet/2016/05/27/making-it-easier-to-port-to-net-core/

ここにパイプを入れて、次のように言います。
a）.NetCoreで実行されているXAMLと
b）その場合、UWPフレーバーを使用するのが最も理にかなっています。これは、すでに他のアーキテクチャーに移植されているためです（たとえば、Raspberry PiでのIoTプッシュ）。

WPF XAMLを取得することは、可能であれば驚くべきことです。

過去10年間の学習に基づいて、.NET Coreが基本的にゼロから再構築されたのと同じように、XAMLについても同じことを行う必要があると思います。 進化したWPF / Silverlight / WinRt-XAMLは、完全な大失敗でした。 一歩前進、2後退（1つは横向き）。 XAML、ExpressionBlendなどの約束は実現していません。

先日、ScottHunterがDotnetCoreでクロスプラットフォームUIを使用しないことを正当化するのを聞いた。 申し訳ありませんが、彼は過去5年間どこにいましたか？ 現在、WebはUIデザインを完全に支配しており、Webには「標準ボタン」のようなものはありませんが、何を推測しますか？ ユーザーはなんとかそれを解決することができました。 その議論は単にすべての証拠に反している。 これらのWebUIは、現在、地球上の商取引を支配しています。 しかし、どうやらそれはDotnetCoreには十分ではありません。 [架空の]「標準的なプラットフォームのルックアンドフィール」の願望に甘んじることなく、クロスプラットフォームのXAMLを使用できないのはなぜですか。

私が推測する主な技術的障害は、「XAML」（または次世代UIプラットフォームと呼ばれるもの）をクロスプラットフォームの3D APIとインターフェースする方法です。MacOSなどでDirect3D / Direct2Dに依存することは明らかにできないためです。この問題は、その目標を達成することに成功したUnityなどによって解決されました。

XAMLファミリのテクノロジのオープンソーシングに関して、Microsoftは非常に多くの足を引っ張ってきました。その中に隠されているのは、ビットコインの秘密のキャッシュなのか、microsoft.comへの秘密鍵なのか疑問に思う必要があります。

MSFT：オープンソースのWPF / Silverlight / WinRT-XAMLを使用して、UXの次の黄金時代を始めましょう。

スコットハンター、@ JackUklejaについてあなたが言うことを聞くのはかなり驚くべきことです。 そのためのソース/リンクはありますか？ あなたの言うことが真実なら、あなたの言うことに加えて、これはいくつかの面で（驚くべき）無知を示しています：

1. これはまさにXamarin.Formsが取り組んだことです。
2. プラットフォーム固有の（または、いわば模倣する）UX /インタラクション/スタイルは、テーマによって対処できる、または対処する必要がある懸念事項です。 これは、WPFが非常に優れていた点です（ただし、あなたのポイントでは、改善することができ、改善する必要があります）。
3. 何よりも悪いことに、これは、間違いなく史上最高のプレゼンテーションフレームワークであるWPFの作成に成功した人材プールに自信を与えません。 彼らはもはやこの問題を解決できないと言っていますか？ または、少なくとも、クロスプラットフォームの方法でWPFを成功させたのと同じ魔法を働かせますか？

優れたUXは優れたUXです。 ご指摘のとおり、Webはこれを明確に示しています。 ネイティブアプリケーションのユーザーは、ネイティブインターフェイスの特定のルックアンドフィールに確実に条件付けられていますが、これもテーマから解決できるはずです。

iOSデバイス上のアプリケーションをDroidの「スキン」（動作を備えたもの）で表示できることを想像してみてください。その逆も同様です。 これはWPFで可能であり、可能であり、まさに今後も実行されるべき考え方です。 つまり、ルック/フィール/エクスペリエンスがアプリケーションの開発と設計の邪魔にならないようにする必要があります。 あなたはテーマを適用することができるはずです、そしてwhalah、「それはうまくいく」。 残念ながら、これはXamarin.Formsの欠点であり、さまざまなプラットフォームを考慮していますが、各ターゲットプラットフォームですべてが期待どおりに機能することを確認することには多くの摩擦が伴います。

@ Mike-EEEスコットハンターがこのドットネットロックのエピソードにその影響を与える言葉を言ったと確信しています： https ：//www.dotnetrocks.com/？show = 1291

再：

「WPFの作成に成功した人材プール、間違いなく史上最高のプレゼンテーションフレームワーク」

...私の理解では、元のアーキテクトの多くは、 WPFに関係する人の一部がMSFTを離れてGoogleに行き、Angularに関係してきました。 WPFからの多くのアイデアが、Angularおよびテンプレートなどの関連フレームワークに表示されています。 しかし、これらのWebフレームワークをどのようにスライスしても、バックグラウンドで常にHTML / CSSの匂いがすることになると思います。 すべてのUIがドキュメント/セマンティックベースであることを意味するわけではありません。それがHTMLの性質であるため、世界でも「XAMLコア」を利用できると思います。

[ジャック...グーグルとWPFアーキテクトに関するデータが正しいとは思わない]

@rrelyeaそれは私の理解でしたが、私は間違っているかもしれません。 WPFチームの一部がAngularに取り組んでいることを読んだことを誓ったかもしれませんが、.... Ian Ellison-Taylorなどですか？ （彼は今MSFTに戻っているように見えますが...）

バックグラウンドでHTML / CSSのにおい

統一されたHTMLCSS標準またはその点に関するあらゆる種類の標準（C、C ++、JavaScript）への適合性と収束性が高いほど、この世界はより良い場所になります。 代わりに、独自の機能を備えたXAMLは、HTML + CSSスタックなどのスーパーセットフレームワークとして、またはASPNETのRazorの代替フロントエンドエンジンとしてレンダリングできます。https ：//github.com/aspnet/Razor/issues/78：バルブ：

@ jasonwilliams200OK FWIW / FYIJSILにはすでに.NETのHTML / CSS「標準」ポートがあります。 その出力はすべて100％HTML5に準拠しており、最新のブラウザで実行されます。 もちろん、これは私たちが目指すべき考え方です（そして、2011年にSilverlightが消滅して以来、そうすべきだったのですが、私は逸脱します）。

つまり、（あなたの意見では）理想/質問は、.NET開発者は.NET / C＃/ F＃/ VB.NETのみを処理する必要があり、CSS / HTML / JSに触れる必要はないということです。 Xamarin .NET開発者は、iOS / Droidの基盤に触れる必要はありません（_they_が何であれ。：wink :)。

@ Mike-EEE、スーパーセット言語（TypeScriptからJavaScript、またはLessからCSS）では、同じファイル内のスーパーセットでサブセットlangコードを使用できますが、その逆はできません。 したがって、スーパーセットの概念は、phonegap、cordovaなどの機能を少し超えています。 :)

ハハええ@ jasonwilliams200OK .NETをブラウザに戻すというアプローチ/戦略のために、特別なケースを作らないようにしたいと思います。 CSS / JSに触れることは、バイナリに触れることと同じ軽蔑で見る必要があります。 ：stuck_out_tongue：

例として、Xaml（yay）を使用しているが、TypeScript（boo）に依存している別のプロジェクトFaydeもあります。 これは、最終的に2つの互換性のないコードベース（1つはクライアントコード用のTypeScript / JS、その他すべての場合は.NET）になり、時間とリソースの両方で非常にコストがかかるため、これを行わない方法です。

ASPNETのRazorの代替フロントエンドエンジン

私の意見では、Razorは単なるテンプレートエンジンです。 実際、そのリンクで、「...コーディングするフロントエンドテンプレートエンジンの長いリストから選択できる」と述べています。

代わりにカスタムタグを使用するフレームワークを支持して、HTMLページ内のRazorのような特別なC＃のような構文に対してMSからコメントを聞いたことさえあります。

ところで、FaydeのようなXAMLソリューションと組み合わせることができるBridge.net（http://bridge.net）やその他のC＃からJavascriptへのコンパイラもあります。

HTML5 / JS / etcでXAMLを再実行します。 WPFを再実装している興味深いプロジェクトGranularがあります。 Saltarelleを使用してJSにコンパイルします。 実例はここにあります。

そのグラニュラーはかなり素晴らしいです、@ ethanhs。 それは私が知らなかったものでした。 CSHTML5 、JSIL、Bridge.net（ @birbilisが言及している）と同じアプローチを採用しているため、PCLを使用してサーバーとクライアント間でコードを共有できないという同じ問題が発生します。これは、実際に実行可能な唯一の方法です。最近そうする方法。

そして実際、そのプロジェクトは見た目と同じくらい素晴らしいものですが、Silverlightの終焉以来.NET開発者が耐えなければならなかった地獄のような風景をほぼ要約しています。 それと他の約12は、ブラウザーで.NETを機能させるという「ある程度」の仕事をしますが、Silverlightの経験を持つ人が期待するすべての経験ではありません。

開発者がSilverlightを忘れる原因となる、単一の単独の統合ソリューションはまだありません。 しかし、私たちは近づいています。 少なくとも願っています。 WebAssemblyは有望なようですが、私はしばらくの間、重要な進展を見たり聞いたりしていません。 JSIL主導のポート/イニシアチブはやや遅くなっているようで、昨年10月以来チェックインされていません。

近い将来、ここでブレークスルーが発生することを願っています。 来年の//ビルドでそのように述べられた発表を見たいです。 ：heart ：： + 1：

これは、XAMLで発生した過去数年間の最高の出来事の1つです。
ここに投票してください！

かっこいい@bbougot。 そもそもひどいXamlシステムを認識しなかった3年近くを数えずに、15か月近く存在した後、_最後に_注目を集めたという別の投票もあります（しかし私は逸脱します！）：
https://wpdev.uservoice.com/forums/110705-dev-platform/suggestions/7232264-add-markup-extensions-to-and-improve-winrt-xaml

（真剣に、最も明白な問題への投票を認識するために15か月もかかりますか？UWPチームはそこで何をしていますか？Visual Studioまたは.NETチームが船を引き継いで正しくするのはいつですか？それは何ですか？ ..おっと、その通り、私は逸脱していました...）

また、このスレッドに賛成することを忘れないでください。 特に、GitHubリアクションなどの豪華なアメニティが登場する前にこの問題が発生したことを考えると、現在60でかなりうまくいっています。 ：笑顔：

Xamlは、クライアントエコシステム全体を統合する可能性がある唯一のものです。
DirectXを削除してください。OpenGLをハグしてください。
UWPは、PC、電話、Webサイトで実行されます。
Viva Xaml！

ですから、ここでの市民の質問@ terrajobst 、 @ harikmenon 、および@karelz （最近タグを追加したようですので、おめでとうございます。これに引き込みます！）。 単純な好奇心から、私は少し冒険して、このリポジトリの高度な（またはそうでないかもしれない）GitHubフィルタリングをチェックすることにしました。 たくさんの票があったと思って、別の問題では何もありませんでした。

これが私が使用しているURLです：
https://github.com/dotnet/corefx/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc

この問題には現在82の賛成票があるようです。私が正しければ、リスト内で次に近い項目は17です。これにより、この問題は、このリポジトリで最も要求/投票された問題になります。

もしそうなら、これがあなたの優先順位や計画に関係があるかどうか私は興味がありました。 明らかに、これは今では_非常に_人気のある質問/アイテムのようです（これも、私が正しく理解していれば）ので、作成の進捗に向けて会話を開始する可能性について、更新またはチェックインを聞くのはおそらく良いことだと思いますこの問題の可能性。

ここで何らかの視点/コンテキストを取得すること、および/または顧客の要求に関して完全に誤解されていることがあれば、それは素晴らしいことです。 それは起こります。 😄

当社の.NETCoreエンジニアは、.NET Standard 2.0（顧客の需要も高い）に重点を置いています。詳細については、こちらとこちらをご覧ください。 .NET Coreを最新の標準にした後、そのリストにない他のライブラリを調べます。

賛成票のクエリを指摘していただきありがとうございます。

返信ありがとうございます@karelz！ とても有難い。 👍

👼👼👼誰かがいいね/リツイートしたい場合に備えて、これをここに残しておきます。 👼👼👼
https://twitter.com/MikeEEE76/status/776769805722521600

.netのバージョン3からxamlを使用していますが、Silverlightのサイズが小さくなり、その死さえも感じました。 私は物事をより良く、より便利にするための改善のための変化を愛する人です。 しかし、UWPを使用すると、前進するのではなく、後退することになります。 素晴らしいと感じた場合でも、デスクトップアプリのように完全なxamlサポートがないため、すべての新機能を気にする必要はありません。 私はUWPで新しいアプリを作成しようとしていましたが、学んだことすべてが再び変わったという難しい方法を学びました。xamlライブラリが移動した場所のように、オンラインで多くのサポートを見つけることができません。 たとえば、フレームワークの下にあった装飾者はもう存在しません。機能しないプロパティのx：staticは、例や何をすべきかを見つけるために何時間も検索する必要があります。 古いxamlから新しいUWPへのリンクを表示するリンクはありません...

@giworking MSがクライアント開発に注意を払う必要があることは明らかです！ Satya Nadellaが引用しているように、アズールはMSのコアであり未来です。アズールを後押しする最も強力なエネルギーは、.netエコシステム全体です。 Javaと比較すると、クライアント側は、コーダーやビジネスにMSのクラウドを採用するように説得するためのほぼ唯一の武器です（中国では、.netは本当に壊滅的な状態にあり、人々はJavaについて話し、「f k s t xamarinとは何ですか？」と反応します。 ....）。 したがって、中国のコーダーとして、xamarin、uwp、typescript、およびcshtml5を見ると、クライアント側全体をxaml + C＃モードに統合することが可能であることがわかりますが、MSの友人が取得する機会を見つけられないのはなぜですかifで中国の市場シェアを取り戻す？

うわー、この問題は現在100以上の賛成票です！ 応援してくださった皆様、本当にありがとうございました。 誰かが興味を持っているなら、ここのコメントに彼の途方もない商標開発者の関与を備えた@terrajobstによる本当に（本当に！ ）素晴らしい記事があります：
https://blogs.msdn.microsoft.com/dotnet/2016/09/26/introducing-net-standard/

（真剣に、会社ベースのブログ投稿を投稿するすべてのMSFT従業員は、その後に発生する避けられない、無数の、そして無数のコメントを投稿してフォローアップする方法について、Landwerth氏のリードに従う必要があります。あまりにも多くのMSFT作成者のように、単に投稿を乾かして質問を死者に任せます。これはもちろん、視聴者を治療するためのひどい方法です！）

とにかく、特にコメントをまだ読んでいない場合は、間違いなく読む価値があります。 これにより、私が今投稿している理由がわかります。_この問題が、System.Xamlを.NET標準/クロスプラットフォームの時代に持ち込みたいという情熱/願望とともにコメントに記載されているのを見てとてもうれしく思います_。 👍

154の賛成票...そして数えます。 😎次に高い問題は、参考のために25です。 #squeakywheel

これを行う必要があります。 乗って！

WPFを対象とする@ReactWindowsアプリケーションがあり、.NET Nativeを使用して、数万人のWindows7ユーザーの初回のダウンロード/インストールエクスペリエンスを劇的に向上させたいと考えています。 また、React NativeをLinuxに導入し、 @ ReactWindows共有コードを再利用する可能性がありますが、Xamarin.Formsをターゲットにする計画もあります。

System.Xaml（およびWindowsBase、PresentationCore、Xamarin.Formsの他のタイプ/メソッド/アセンブリの依存関係）をNETCore vNextで使用できるようにすることは、この戦略にとって重要です。 この欠陥を回避するには、既存のアセンブリを再オーサリングして再ターゲットするか、MonoのSystem.Xamlに不足しているタイプ/メソッドを入力して、.NET Core用にビルドしますが、Microsoftがステップアップして提供することを強く望んでいます。プラットフォームに必要です../cc @rozele @ pre10der89

@matthargettこれで頑張ってください。 ワークフローを.netCoreに導入することを検討していたときに、この問題を打ち負かしました。 xamlチームに連絡するところまで行った。 彼らは、System.Xamlを開くことにリモートでさえ興味がありません。 理由はわかりません。確かに、保護する価値のあるものは何もありません。

これは、4月末の2.0リリース後に検討される可能性があります。

繰り返しになりますが、WFをnetstandard1.xに移植するためにSystem.XAMLは必要ありません... WFのコアが機能する@dmetzgarからの優れた作業がすでにあります。 主な欠落している部分は、最終的にnetstandard2.xで戻ってくると私が信じているトランザクションです。

@dmetzgarポートの主なガイドラインは、コアに関連付けられた設計言語を持たず、基本的なプリミティブを使用して、ワークフローを好きなようにシリアル化し、後でその上にデザイナーを作成できるようにすることです。

もちろん、このアプローチは現在のXAMLベースのワークフローとの下位互換性を損なうことになりますが、私を信じてください。.NetCoreは大きな重大な変更であるため、人々はそれを理解する必要があります。

XAML設計者が利用できるOminiSharpがありますが、ここでも、設計/シリアル化はWFコアの一部です。 .NetCoreの他のすべてと同じようにスリムである必要があります。

この問題は、人々がWFを.Net Coreに移行することを望んでいることを明らかにし、大声で言ったと思います。System.XAMLチームにOSSを要求することは、生産的ではないと思います。 XAMLチームには他の優先事項があり、Windows / UWP / Xamarinビジネスの中核であるため、すぐにOSSになるとは思わないでください。 その代わりに、 @ dmetzgarに、.Net Foundationの下でWFリポジトリを公式に公開し、タイムラインを設定したり、 netstandard2.xのリリースを約束したりせずに、コミュニティをガイドして稼働させるように依頼します。 それは彼のチームによって推進されている進行中の作業であり、明らかにそれを助け、それを実現したいと望んでいるコミュニティによって主に助けられました。

Orleansプロジェクトで物事がどれほど速く進化するかを見てください...昨年OSSされたのはMicrosoftResearchであり、.Net Foundationで最大かつ最もアクティブなリポジトリの1つであり、ほとんどがコミュニティの取り組みによって推進されています（まだMSFTチームがフルタイムで作業しています）。

とにかく、私見、私たちはヤムをやめて何かを始める必要があると思います。 @dmetzgarチームには、それに取り組むための帯域幅がないことは明らかです。彼らの主な関心事は、基本的に.netコアに到達する予定のないSharepointの大規模な展開であるWFの主要なユーザーをサポートすることです。 したがって、それはコミュニティ主導の（ @dmetzgarのチームによって監督された）取り組みでなければなりません。

繰り返しになりますが、WFをnetstandard1.xに移植するためにSystem.XAMLは必要ありません...

@galvesribeiroは本当かもしれませんが、この問題はSystem.Xamlを.NET Coreに移植することです。これは、.NETチームがフィードバックを求めているリポジトリで最も要求されている機能です。 あなたがあなたのフィードバックに耳を傾けないのなら、なぜそれを求めるのですか？ とにかく、WFは、System.Xamlポートが満たすシナリオの1つにすぎません。 ご存知のように（またはそうすべきです！）System.Xamlははるかに多くの機能を備えています。

XAMLチームには他の優先事項があり、Windows / UWP / Xamarinビジネスの中核であるため、すぐにOSSになるとは思わないでください。

ええ、それはここでの問題の一種であり、私たちが変更を求めているものです。 :)また、最近は「Xamlチーム」があるかどうかさえわかりませんね。 このテクノロジーが閉鎖されたと本当に感じており、私たちはそれを回避し始めています。

とにかく、私見、私たちはヤムをやめて何かを始める必要があると思います。

100％同意します。 FWIW、 @ SuperJMNはOmniXamlv2.0をリリースしたばかりなので、MSFTがこの問題に関するエネルギーと取り組みを優先している間、活用できるコミュニティの取り組みがいくつか進行中です（ちなみに、これは約11か月間続いています-そして数えています）。

そういえば、 @ terrajobstからの引用とともに、まさにそれに関する素晴らしいスレッド（つまり、これに対するMSFTの非アクティブ）があります。

明確にするために、System.Xamlをクロスプラットフォームにすることができない、またはすべきではないと言っているのではありません。 私が言っているのは、System.XamlはWPFとWF以外ではあまり有用ではなく、NuGetはそのステートメントの賢明なプロキシメトリックであるということです。 もちろん、System.XamlはUIレルムの外で意味のあるものにすることができますが、それは2番目のステップです。 私はむしろ、私たちのリソースを今すぐ使用して、基本的な部分がうまく機能し、完全になるようにしたいと思います。 さらに、ベースを統合することで、System.Xamlなどの高レベルのコンポーネントの移植もはるかに簡単になります。

したがって、それはどちらか一方のステートメントではありません。 それは実行の順序のステートメントです。

System.XamlがWPF / WFの外部では役に立たないという非常に誤った記述はさておき、これはすべてプロジェクトマネージャーのように聞こえますが、この問題を回避するつもりはありません。 私はImmoと彼がここで行っている素晴らしい仕事を全面的に支持しているので、私の目的はその声明に批判的ではありません。 しかし、私はその種の言語が私に一時停止を与えて、この問題に関して私を待って見る（またはむしろ「私がそれを見るときそれを信じる」LOL！）スタンスに置くことを可能にするのに十分なブロックの周りにいました。

それまでの間、私は.NET Standard 2.0での現在の取り組みをサポートし、それがもたらすものを楽しみにしています。 多分それは予想よりも良いかもしれません。 少なくとも、Windowsプラットフォームで動作する.NET CoreプロジェクトのSystem.Xamlを再利用できるように思われます。これは、私にとって十分なスタートです。 👍

@ Mike-EEEまず最初に申し訳ありません...私はこれに返信していましたが、 https：//github.com/dotnet/corefx/issues/2394 oOこれらの2つの問題は何度も相関しすぎて、混乱しました。

第二に、XAMLがUIにのみ役立つと言っているわけではありません。 私はこれをTFSビルド、WF自体、そして最近ではUIで長年使用していました。 Azure MLのようなDSLや、XAMLを活用できるDSLがたくさんあります。

私が言いたかったのは、XAMLが.NetCoreにすぐに移植されるのを見ていません。 Immoが言ったように、彼らは現在のプラットフォームで最初にそれを正しくする必要があります。 .Net Coreには、ネイティブの画像操作ライブラリすらありません。

完全な機能を備えたWPFから、UWPには弱く、多くの機能が不足しているものまで、複数のXAML実装があります。 そのようなものがOSSになる前に、それは統一され安定化されなければなりません。 私はそこで働いているチームによって話しません。 リソースを優先する必要がある場合は、それらよりも差分をとらないと思います。

WFに関しては、申し訳ありませんが、私の以前のコメントは、この問題がWFのコアへの移植がそれほど速く行われない理由であると期待している人を対象としていましたが、これは真実ではありません。

これらの2つの問題は何度も相関しすぎて、混乱しました。

ハハ@galvesribeiro私もそれが何回噛まれたかをあなたに言うことはできません（または認めることを恐れています）。 心配ありません。 私は、関係なく入力に感謝します！

FWIW、@ cwensleyは@ Portable.Xamlに対しても素晴らしい仕事を続けているようです。最近、System.Xamlのモノベースの適応にパフォーマンスの改善を加え、元のバージョンよりも高速にしています。 そこにあるすべてのフレーバー/オプションの元のSystem.Xamlエクスペリエンスにおそらく最も近いので、それがここでの取り組みの良い出発点になる可能性があるように思われます。 ちょうど私のカフェインによって誘発された朝の2セント。

System.Xamlを.NetCoreに移植してください

FWIW、この問題への200票以上、現在202に座っています。次に高い問題は、47に座っているdotnet / corefx＃13526です。まあ、47でした...私の投票から48になりました。 ：）（愛を示してください、それは良い考えです。）＃squeakywheel

リマインダー@ Mike-EEEをありがとう;-)。 期待を設定するために：私たちはまだ深く掘り下げる準備ができていません-個人的には、3月までに次の公式ステップについてもっとコメントできるようになることを願っています。 （免責事項：私は自分の最善の個人的な推測を伝えようとしています。公式のチームの約束として扱わないでください！）

前回この問題について少し話し合ったとき、飛び出した重要な質問は、200以上の投票のうちどれが本当にSystem.XamlとWPFについてだけであるかを判断することでした。 多くの人が2つを区別しないという仮定。 それについてどのように最善を尽くすかについての提案はありますか？ （たとえば、2つの特定の問題を作成し、WPFと「WPFではなく純粋なXaml」に投票するように人々に依頼します）

また、System.Xamlのシナリオの要約リストと、いくつかの優先度の見積もりを用意しておくと役立ちます（現在、それらは長い議論に散らばっています）。 @ Mike-EEEは、私たちがまとめるのを手伝ってくれるものですか？ （あなたはその地域に強い関心と深い知識を持っているようです）

間違いなくSystem.Xamlは人々が@karelzを望んでいるものです。 ここで誰かがWPFについて考えている場合、それは私見では適切な場所ではありません。 WFやTFSビルドなどのXAMLを活用するフレームワークは他にもたくさんありますが、それらはまだSystem.Xamlを使用しており、大きなメリットがあります。

@karelzここでの返信に本当に感謝しています。 お時間を割いていただきありがとうございます。 @galvesribeiroが言及しているように、System.Xamlは単なるUIではありません。これは、残念ながら、多くのMSFTが見逃している重要な理解のようです。 これは強力なシリアル化パラダイムであり、他のどのシリアル化ソリューションよりも優れています。特に、アプリケーションの記述に関しては、これが最も優れています（結局のところ、そのモニカの「A」）。 残念ながら、「アプリケーション」は「UI」と混同されているため、ここでの摩擦があります。

この側面を見落とすことはUWPの重要な失敗であり、誰もUWPでの作業を本当に好まない理由の一部です。 逆に、XamarinはXamlのフレーバーでこの重要な側面を理解しているようですが、これは内部的なものであり、ファーストクラスの信頼できるオファリングとして公開されるべきではありません（これは、この問題の後に続くものです）。

TBH、 Portable.XamlのSystem.Xamlの@cwensleyのポートは、現時点では最有力候補のようです。 彼はMonoのSystem.Xamlを移植した（全体的に使い慣れたAPIを維持している）だけでなく、新しい機能を追加し、実際にそのパフォーマンスをSystem.Xamlよりも_優れた_ものに改善しました。

私の見解では、この問題は@cwensleyと協力して、彼が今後使用する信頼できるクロスプラットフォームXamlライブラリを作成するのと同じくらい簡単である可能性があります。

これ以外では、それがトリッキーになり、この問題の（当然のことながら）複雑な見方に追加される可能性があります。 System.Xamlは、アプリケーションを記述するための表現力豊かで強力な言語を提供します（ここでも、ユーザーインターフェイスだけでなく）、Visual Studio（およびもちろんBlend）に組み込まれた優れたツールサポートも備えています。 したがって、理想的には、同じ素晴らしいエクスペリエンスを継続し、クロスプラットフォームの方法でXamlのデザイナーエクスペリエンスを維持することは素晴らしいことですが、個人的には、ここで説明している素晴らしいケーキの上にチェリーを求めています。 :)

また、ここで繰り返しますが、Xamlの約束（および配信）は、デザイナーと開発者の間の開発ワークフローの改善でもありました。 最終的にはこれをさらに一歩進めて、開発と_devops_の間のプロセスを改善できると思います。 つまり、devopsが美しく設計されたアプリケーション構成エディター（Xamlを搭載）で動作して、デプロイされたアプリケーションを管理および保守する世界を見たいと思います。

_ここでの全体的なアイデアは、コーディングからデプロイメントまでのアプリケーション開発の全体的なコストを削減することです。 かわいらしい編集者やデザイナーと仕事をすることは、魔法を起こすためにコード（および/またはスクリプト）を手に入れなければならない人を見つけて雇うよりも（リソースの観点から）安価です。_

私はこれをビジョンの観点としてあなたと共有します、あなたが気づいているように。 しかし、あなたがこれを聞くことにどれほど興味を持っているかはわかりません。 😉それで、これが単に「この問題を閉じてあなたを去らせるには何が必要でしょうか？」 ウェンズリー氏と一緒に仕事をする可能性を探り、彼の素晴らしい仕事をこれまでに活用できるかどうか（または彼がそうすることに積極的であるかどうか）を確認することをお勧めします。 .NET Core Wave 2のリリース（5月頃かそこら？）の信頼できるクロスプラットフォームXamlパッケージになるようにこれを調整する方法があれば、さらに良いでしょう。 :)

情報をありがとう、私は間違いなく興味があります。 また、前の質問が意図したとおりに出てこなかったと感じたので、いくつか指摘してみましょう。

はい、私は間違いなく詳細に興味があります。 Xaml！= MSFT側のWPFに異議を唱えている人はいないと思います。 私は絶対にそうしようとはしませんでした。 私は自分が完全に理解していないことを知っているだけで、ギャップを埋めようとしています。つまり、「純粋なXaml」のシナリオの動機と必要性を完全に理解しています。
（ところで、私はあなたのdevopsシナリオと、Xamlがそこで役立つ唯一の/最良のものである方法を完全には理解していませんか？またはシナリオで実際にどのように使用されているのですか？）

私はこの問題を解決しようとはしていません。 お願いします！ それも私の心を越えませんでした。 私は、コミュニティが質問を要約して、適切な人々（この場合は取締役と考えてください）と話し合うことができるように支援するためにここにいます。 はい、その一部は、私（および/または他のいくつかのMSFT）がそれをより高い位置に表すための質問を完全に理解する必要があることを意味します-したがって、私の質問です。

確かに、私はこの問題を見る前にXamlとWPFを区別していなかった人の良い例です。 .NETチームの他のメンバーとのランダムなチャットから、多くの人がXaml！= WPFを知っていますが、ここで売り込まれている純粋なXamlを持つことの「巨大な価値」はわかりません。したがって、シナリオに関する上記の質問です。 シナリオは、私/私たちが動機をよりよく理解し、物語をよりよく伝え/販売するのに役立ちます。 （明確なストーリーがない場合、誰もそれに資金を提供することを切望していないことは驚くことではないことを願っています：）-ストーリーは資金提供の前提条件です）
それでは、エレベーターピッチを考えて前進させましょう。

@cwensleyの仕事に関して-それほど高価ではない解決策があるかもしれないと聞いてうれしいです。 しかし、繰り返しになりますが、解決策に取り掛かる前に、まず背景と理由を理解することが本当に役立ちます。 私はそれが理にかなっていることを願っています。 （私は否定的なことや何かをしようとしているのではありません-なぜ理解され合意されたときに物事を前進させる方が簡単であることを繰り返すだけです）

@galvesribeiro誰かがここでWPFについて考えている場合、それは適切な場所ではありませんIMHO

投票した200人以上のすべての人がXaml！= WPFをそのような詳細に本当に理解しているというあなたの自信を共有しません。 また、少なくともいくつかはそれを見てみようと思います-ええ、最初にXamlを入手しましょう。そうすれば、WPFを要求するのが簡単になります。 したがって、常に念頭に置いているシナリオはWPFですが、「純粋なXaml」はそれに向けた最初のステップにすぎません。
そして多分私は間違っています（少なくとも私はこれらの疑問を持っている.NETチームの唯一の人ではありませんが）...
もう1つの角度は、「純粋なXaml」をシナリオのリスト（WPF、上記のdevops、おそらく2つ以上？）に分解し、人々に投票するように依頼することです。ここで投票した人にとって本当に重要なのはどれですか。 彼らが本当に望んでいるのは何ですか？
（これは遅延戦術や悪ではありません。ここで「顧客」を理解しようとしています。それが理にかなっていることを願っています。そのようなデータを取得する方法についてより良い提案があれば、声を上げてください。私は別のアプローチを受け入れます。 ）。

編集：いつものように、私が問題に正しい方法で取り組んでいないと思うなら、そう言ってください。 私はここで最善を尽くして支援しようとしています-最善の意図を持って。 私は、すべてを知っているという幻想や、自分が他の誰よりも賢いと思っているという幻想に悩まされることはありません。

@karelz WPFがまったく好きではない場合でも、XAMLがクロスプラットではないという理由だけで、車輪の再発明を行い、独自のマークアップ言語を作成しているUIフレームワークがたくさんあります。 アバロニアはトップのものの1つです。 代わりにネイティブXAMLを利用できる場合は、Omnisharpを使用します。

ワークフローファウンデーションはXAMLの大規模なユーザー/顧客であり、ポートWFから.NetCoreスレッドのユーザーは常にそれについて質問します。

そうです、私はあなたに同意します。たとえば、UIやWFなどの望ましい使用法とともに、クロスプラットSystem.Xamlから期待されるものに期待を確立するか、生の機能セットを描画する必要があります。

@karelz

また、少なくともいくつかはそれを見てみようと思います-ええ、最初にXamlを入手しましょう。そうすれば、WPFを要求するのが簡単になります。 したがって、常に念頭に置いているシナリオはWPFですが、「純粋なXaml」はそれに向けた最初のステップにすぎません。
そして多分私は間違っています（少なくとも私はこれらの疑問を持っている.NETチームの唯一の人ではありませんが）...

それで...それの問題は何ですか？ WPFのようなクロスプラットフォームソリューションは非常に良いことかもしれません。 XamarinはクロスプラットフォームのデスクトップGUIを実行できません。

@ jnm2悪くはありませんが、それがメイン（90％以上）のシナリオである場合は、両方を実行することを計画する必要があります。 WPFなしでXamlを使用しても、そのような場合には役に立ちません（少なくともそれほど多くはありません）。 また、WPFがコミットされ、すぐに実行されるという（潜在的に）無効な錯覚を引き起こす可能性があります。

WPF / GUIを.NETCoreに組み込むことは、現在主にサーバーシナリオとコンソールアプリを対象としている.NETCoreにとって大きな一歩となるでしょう。

@ jnm2にSystem.Xamlがあると、WPFのようなものを他のプラットフォーム（https://github.com/AvaloniaUI/Avalonia）に持ち込もうとしている（私のような）人々を大いに助けます。

合理的なシナリオのように聞こえる@ grokys-もう少し詳しく説明していただけますか？ 助けはどれほど大規模になるでしょうか？ それなしで何が挑戦的ですか？

また、（WPFに似ていない）クロスプラットフォームデスクトップUIフレームワークであるEto.FormsにもXamlを使用しています。 これが、私が最初にPortable.Xamlプロジェクトを作成した理由であり、これまでのところ、私とユーザーにとってはうまく機能しています。

私はこれを「信頼できる」クロスプラットフォームのxaml実装にするのを手伝うことに反対していません（@ Mike-EEEが言うように）。 ただし、私は暇なときにのみこれに取り組んでいることを覚えておいてください（;

@karelz
UIフレームワークだけでなく、XAMLからHTMLまでの多くのシーンで使用できます

@Kationは、正確に何を意味するのか、詳細を共有できますか？

ところで：私は一番上の投稿でシナリオの要約を始めました-あなたのシナリオがそこにない場合は、それを説明してください、そしてそれが理解されたら、そこに追加します。

@karelz
Visual Studioの強力なXAMLエディターを使用すると、カスタムコンポーネントコンテンツをすばやく作成できます。
次に、XAMLを使用して、特別なシナリオでHTMLコンテンツ、さらに多くのSVGコンテンツを生成できると思います。
これは、.Net4.5用の半完成のXAMLからXMLへのフレームワークです。 https://github.com/Kation/WebPresentation

XAMLからHTMLまたはSVGを生成する理由がわかりません。 ここでのXAMLの価値は何ですか？
それが素晴らしいVSエディターを持っているという価値はありますか？ HTMLエディタもありますが、それらを直接使用してみませんか？
それとも私は完全に要点を逃していますか？

@karelz
一部のプロジェクトでは、テンプレートとスタイルを使用してWPFのようなコンテンツを生成したいからです。

@karelz対話に改めて感謝します。 とても感謝しています。

私は、すべてを知っているという幻想や、自分が他の誰よりも賢いと思っているという幻想に悩まされることはありません。

ああ、うらやましいです。 😉

したがって、常に念頭に置いているシナリオはWPFですが、「純粋なXaml」はそれに向けた最初のステップにすぎません。

ええ、これも私が言った混乱です。 Xamlは、純粋でシンプルなシリアル化パラダイムです。 アプリケーション（およびそのアプリケーションを含むコンポーネント）を定義および記述できます。 まず、Xamlで説明されている_コンソールアプリケーション_の例を次に示します。
https://github.com/DevelopersWin/VoteReporter/blob/master/DevelopersWin.VoteReporter.Application/Program.xaml

Xamlで説明されているコマンドがあり、コンソールの入力と出力を使用してユーザーに何を提示するかを指示していることがわかります。 これは、WPFまたは「UI」とは関係ありません（技術的には、これはCLIがUIであるという意味でのUIですが、違いを見つけることができれば幸いです）。 さらに、ファイル内でマークアップ拡張機能と静的メンバー宣言を使用していることがわかります。 これは、JSONやその他のデータ形式では見たことがないものです。 これはまさにXaml、IMOの力です。

「PureXaml」シナリオの別の例として、新しい形式に依存しないMSBuild用に提案しているファイルを次に示します。
https://github.com/Mike-EEE/Stash/blob/master/MsftBuild.Model/SampleFormats/Xaml/Processor.xaml

（レベルを上げると、同じことを行う他の形式を見ることができます。これはたまたまXamlバージョンです）

これもプロセッサフ​​ァイルであり、理論的なビルドプロセスで実行する手順を説明する（ System.Windows.Input.ICommand ）コマンドのセットです。 繰り返しになりますが、WPFやUIはありませんが、コンソールにメッセージを送信していることがわかります。

ここで指摘したい機能の1つは、このファイルから取得したVisualStudioの組み込みツールです。

Visual Studioは、作業を行ったり外部スキーマを定義したりすることなく、単に「ライトアップ」し、作業中のファイルのクラススキーマに基づいて、ドロップダウンやその他のデザイナーインターフェイスを備えたプロパティエディターを提供します（これにより、devopsシナリオが簡単になります）理解するために）。

プロセッサフ​​ァイルに加えて、プロセッサへの送信に使用できる理論上のプロジェクトまたは入力ファイルは次のとおりです。
https://github.com/Mike-EEE/Stash/blob/master/MsftBuild.Model/SampleFormats/Xaml/Project.xaml

ここでは、バージョンを提供するために使用される_markupextensions_（おそらく外部ファイルから）と、ビルド用に収集されたファイルを提供するためのクエリを使用して、ポイントホームに到達しようとします（実際にこれを実行したくない場合があることに注意してください最終的なビルドシステムですが、その可能性を示したかったのです）。

ところで、このサンプルコードは完全に機能しているため、そのリポジトリからSLNを取得してXamlバージョンを実行できるはずです。結果は、次のようになります。

（注：マイマシンで動作するため、マイレージが異なる場合があります。😄）

ところで、私はあなたのdevopsシナリオと、Xamlがそこで役立つ唯一の/最良のものである方法を完全には理解していませんか？ または、シナリオで実際にどのように使用されているのでしょうか。

ええ、私の投稿が少し長くなっていると感じたので、私はそれに入るかどうかについて議論しました。 うまくいけば、上記のビジュアルデザイナーコンポーネントが、私がここで何をしているのかを説明するのに役立つことを願っています。

私にとってこれは究極のエンドゲームであり、なぜ私がこれらすべてについてとてもガンホーであるかを知って、注意してください。 _その理由は、アプリケーションの総所有コストをその存続期間にわたって削減することになるためです。_

したがって、ここで中心となるのは、POCOベースの開発です。ここでは、アプリケーションプロセス内で使用されるPOCOで編集と設計が行われます。 ご存知のとおり、開発者と設計者は、UIドメインを処理するPOCO要素を記述したXamlファイルで作業します（これは、「Xaml」の従来の「WPF」です）。

私の世界では、このプロセスを拡張して、開発がDevOps用のXamlファイルを提供し、ライブ環境にデプロイされたアプリケーションを管理/保守するために使用できるようにしたいと考えています。

これは、ライブ構成ファイルと考えることができます。 それらがどのようにロードされるかを解決する必要がありますが、最終的な結果は、上記のVisualStudioのスクリーンショットに表示されるもののようになります。 エンド（devops）ユーザーがコードに手を入れることを余儀なくされる（または、組織に必要な高価なタレント/スキルセットを雇うことを余儀なくされる）代わりに、制約された検証済みのビジュアル編集コントロールを使用して構成し、アプリケーションを保守します。

_ここでの考え方は、コードを知って理解する必要があるのではなく、これを行うために必要な労力（およびスキル）のために、展開後にアプリケーションを維持するコストが大幅に削減されるということです。_

これについて私が言及していない1つの側面は、これらのコントロールが実際にカスタマイズ可能であるということです。 Visual Studioには、これらのPOCOプロパティにアタッチされたビジュアルエディターを定義するための（古くなっていますが）広範なAPIがあります。
https://msdn.microsoft.com/en-us/library/microsoft.windows.design.model.designmodevalueprovider(v=vs.90).aspx

これは、追加の作業、オーバーヘッド、または労力なしで、現在VisualStudioですべて利用できます。 したがって、ここでの最終的なアイデアは、開発プロセスだけでなく、最終的にはdevopsプロセスを支援する強力なエディターとデザイナーのスイートを作成することです。

繰り返しますが、これはすべて先見の明があり、実際の現実の基盤はありません（まだ）。 確かに、これは完全に私の考えではありませんが、 Windowsフォームベースの構成エディターを使用したパターンとプラクティスのグループに触発されています。 私は単にこの吸盤をさらに一歩進めて、Xamlの力を通してそれを使用するのを見てみました。

この@karelzについて他にご不明な点がありましたら、お知らせください。 再度、対話に感謝します。 それは共有する機会を提供するだけでなく、私の考えや信念を検証する機会も提供します。 そして、それをすべて知っているという考えに戻って（はい、私は有罪です👼）、私は物事についてオープンマインドを保ち、すべての答えを持っているわけではないことに気づきます。 これは間違いなく、私が継続的に上手くやろうとしているプロセスです。 再度、感謝します！

@ karelz -Avaloniaは現在OmniXamlをXAMLエンジンとして使用しており、これは非常にうまく機能しますが、まだバグや不足している機能があります。 Portable.Xamlと同様に、OmniXamlはボランティアによって保守されており、ボランティアは常にそれに取り組む時間があまりありません。

実際にSystem.Xamlを開かないことにした場合は、テストスイートをリリースすることは良い妥協案になるでしょう。少なくともその方法で、OmniXamlやPortable.Xamlなどのサードパーティの実装が可能な限り準拠していることを確認できます。

.netエコシステムに必要なのは、人間が読める形式のデフォルトのシリアル化形式であると思います。これは、Javascriptの世界ではJSONのようなものです。 この形式では、donetデータ型を使用し、スキーマとしてPOCOを直接使用する必要があります。 次に、その形式を使用してPOCOオブジェクトを記述できます。 これらの説明は、強力かつ静的に型指定されています。 これは、UIレイアウト、ランタイムアプリ構成、プロジェクト/ワークフローの説明、または2つの.netプログラム間の通信用です。 また、他のエコシステム（web / Javascriptなど）との通信も可能です。 ただし、.netエコシステムを中心に設計する必要があります。 そのため、JSON / BOND / Protobuf / XMLでは不十分です。

歴史的に、XAMLはある程度責任を果たしていました。 ここで問題となるのは、この役割にとってどれほど優れているかということです。 それで十分であれば、XAMLをnetstandardにしてから、.net実装にする必要があると思います。 ただし、可能であれば、他の形式も考慮に入れる必要があります。 先週、 http：//www.ammyui.com/が出たと思います。 シンプルさに焦点を当てたUI記述形式ですが、XAMLに変換されます。 なぜなら、XAMLは十分に単純ではなかったからです。 私自身、（オブジェクト、コレクション、インデックス）イニシャライザーに基づいてroslynリポジトリ/ roslyn＃16648で1つのフォーマットを提案しました。 そして、私の提案は、Entity Frameworkチームの@bricelamによるこのブログ投稿から実際に取得されました（その後、わずかに変更されました）。 彼の投稿と私の提案スレッドの両方にいくつかの例があります。

私の言いたいことは、XAMLであろうとなかろうと、.netにはデフォルトの形式があるはずだということです。

@grokys OmniXamlについて言及したかったので、ここでの会話に@SuperJMNを招待しましたが、彼が参加したいと思ったことはないようです。 それが設定なのか、それとも何なのかわからない（私もまた、彼と一緒に仕事をしているので、ここに彼をドラッグすることで幸運を得ることができるかもしれません😄）。 もちろん、OmniXamlもこの会話に大歓迎です。

@gulshan +💯👏👏！ ハハ。 このすべての交絡部分の一部は、XamlがMSFTフォーマットおよびテクノロジーであるということです。 MSFTと企業の両方で、すべての投資とツールが構築されているため、既存の取り組みと投資を活用できるように継続性を確保することにギャップがあるように見える理由は、確かに理解できません。

そうは言っても、私はAmmyで見たものが好きで、これについてはオープンマインドを持ち続けています。 または1つ持ってみてください。 👼

そもそもなぜデータファイルに煩わされるのかを繰り返すことが重要だと思います。データ形式を使用する主な価値は次のとおりです。

• 命令型言語にとらわれない。 ファイルを使用するために、プログラミング言語を知っている必要はありません。
• デザイナー/ツールに優しい。 _ビジュアルデザイナーを使用したり、製品でビジュアルデザイナーのエクスペリエンスを有効にしたりすると、 TCOが低下します_。

そうは言っても、私にとって個人的に重要なのは次のとおりです。

• 開発者/設計者の統合ワークフロー
• ファイルを手動で編集するためのビジュアルデザイナーの経験。
  
  
  
  • 上記の拡張可能なエディターAPIを備えたPropertyGrid（プロパティウィンドウ）。
  
  
• マークアップ拡張機能
• Cherry-on-the-cake of awesome：開発以外のシナリオで上記のすべてを活用する機能（上記のdevopsの例）。

これらすべてが満たされている場合は、「別の.NET形式」を検討したいと思いますが、明らかにXamlをその形式として維持および拡張したいと思います。 結局のところ、これはMSFTテクノロジであり、したがって知的財産です。

@ Mike-EEE形式をPOCOに逆シリアル化できる場合は、これらの機能がすべて機能している必要があります。VSのプロパティウィンドウは、非XAMLシナリオでも表示されます。 しかし、私が懸念していることの1つは、エディターのサポートがなくても読みやすさです。 場合によっては、リモートサーバーで構成ファイルを編集する必要があり、vimしかありません。 JSONと比較すると、XML（およびXAML）は、この点ではそれほど優れていません、IMHO。

ただし、XAMLには、アタッチされたプロパティなど、単純なシリアル化形式で模倣するのが難しいいくつかの固有の機能（実際には非XML機能）があります。

最初にWPFに投票し（最終的にxamarin.fromsに別れを告げることができます）、次にxamlに投票します。

VSのプロパティウィンドウは、XAML以外のシナリオでも表示されます

正解ですが、Xamlの場合のように、完全にカスタマイズ可能な編集コントロールなどを使用して、ほとんど「ライトアップ」されていません。ここで間違っている場合は、訂正してください。 これらの形式のプロパティにカーソルを置いて、列挙型フィールドのドロップダウンレンダリングを行うことはできません（たとえば）。 このエクスペリエンスは、基本的にWinFormsの次のフォームとバージョンであり、これが非常に優れている理由の1つです（WinFormsは今でも人気があります！）。

JSONと比較すると、XML（およびXAML）は、この点ではそれほど優れていません、IMHO。

ええ、私は同意します、Xamlは正確に簡潔ではありません、そしてあなたはそれがどれほど冗長であるかについての不満を聞くでしょう。 これは、OmniXamlがフォーマットの改善を提供することによってそのマークを付けているところです。 また、TOMLやYAMLなどの他のフォーマットと完全に競合しています。

非XML機能）添付プロパティなど...

そしてマークアップ拡張。 😄これらはそのビジョンの特徴です。

ここで@gulshanが足を踏み入れているのは、本質的には「データAST（抽象構文木）」です。 Xaml（または.NETデータ形式）を真剣に改善することについて話している場合は、これが最善の方法です。 Roslynからも電力を供給できます。 実際、私はこのアイデアにユーザーの声で投票しました（対応するブログ投稿と一緒に）。 残念ながら、説明するのが難しいのであまり人気がありません、ハハ。 基本的に、任意の数の形式で書き込むことができるAST（データ）ツリーがあります。 そうすれば、開発者（およびツール）は、（美的またはその他の方法で）最も意味のある形式に従ってそれを操作できます。

だから私はついにxamarin.fromsに別れを告げることができます

その側面についてあなたと同意して@groege。 😎

@ Mike-EEE以前にDataASTプロポーザルをチェックアウトしたことがありません。 はい、概念的には.netのデフォルトのシリアル化/オブジェクト表記の提案に似ています。 そのアイデアはその抽象性のために理解するのが難しいです。 😄

XAMLに関しては、.netベースの強く型付けされたデータシリアル化形式により、多くのXAMLマークアップ拡張機能の必要性が軽減されます。 それでも、いくつかの式（コンストラクターなし）では初期化できないものが残ります。 これらのマークアップ拡張機能のいくつかがC＃自体の一部であったらいいのにと思います。

@karelzからの返信はないので、Xamlでコンソールアプリケーションを定義できることを知ったとき、彼はモニターの前に腰掛けていたと思います。

（悪い）冗談はさておき、他に質問があれば教えてください。

また、今週の.NETからは、.NETCoreで作成されているかなりクールなエンジンのように見えます。 この投稿の最初のコメントはそれをすべて言います。 :)

@ Mike-EEE私はあなたに答えを借りていることを知っています（それは私の受信トレイで重要とマークされ、ブラウザで開かれています）。
これまでのところ、私は返信をざっと読むことしかできませんでしたが（すべての詳細と洞察に感謝します！）、Xamlについて自分自身を教育し（あなたが指摘するように）、すべての返信を完全に読んで答えることができます...申し訳ありませんが、現在進行中の火災と高額の高額が多すぎます:(、後で取得します、約束します！

すべての良い@karelz！ ここでのあなたの努力と対話に感謝します。

これがオープンソーシングWPFへの投票です。XAMLの他のすべてのバージョンは比較するとゴミです。 そして、真剣にみんな、これでループを完了し、UNIXとMacOS用の.netコア/ XAMLストアを持っています。

@ Mike-EEE大変申し訳ありませんが、まだこの問題に戻る時間がありませんでした:(

ああ、心配しないでください、 @ karelz私は誰もが今忙しいことを知っています。 何よりも会話に感謝しています。 私は頭から多くを得ました。 そこにそれを見て、そのようにそれを反省するのは良いことです。 その上、私たちはすでにこれまでに1年以上待っています...あと数か月かそこらですか？ :)

彼らはsilverlight5をオープンソースにする必要があります..html5が動くので、win8はmove / winrt ...＆今はuwp＆win10とxamarin .... COMMON !! ハリウッドのようなラ・ラ・ランドで失われた哀れなものか...

どうすればSilverlight5からそれらすべてのがらくたに移行できますか？ どうやって？ アセンブリインターフェイスを常に壊すときにユーザーを尊重していると言うにはどうすればよいでしょうか。独自のnugetパッケージの名前を変更し、nugetで古いパッケージから新しいパッケージに自動的に移動する方法を提供しないでください。ベータテスターは、アイデアを作成してコーディングする前に明確に考えるにはあまりにも愚かだからです。

xamarin形式のios / android / uwpプロジェクトの必要性を取り除く必要があります。プラットフォームごとにプロジェクトを用意するよりも、マルチプラットフォームをサポートするためのはるかに優れた方法があると思います。

今、すべてを1つのfの下に持ってきてください。 ワイプするフレームワーク（wpf / silverlightカバレッジとxaml言語をお勧めしますが、すべてをxamarinに取り込みたい場合は、スタイル/テンプレートにデータ型を追加できますか？多くのような奇妙な省略と、f。nucrapgetが機能することを確認してくださいA1一度だけ..なぜ私はすべての依存アセンブリにnugetパッケージをインストールする必要があるのですか？参照されたdllと同じです..？あなたにはビジョンがありません...ニートなし...キャップアウト...この間ずっとmsがらくたで立ち往生しています..私は自分のf。ワールドクラスのsdkを構築できたはずです。

私はMSが私の道に糞を捨てずに1日を過ごすことはできません..私はscala-jsを真剣に考えているか、ただ迅速に..家を出る時間です！ 私はうんざりしています

2年近くかかりましたが、UWPはついにXamlモデルのマークアップ拡張機能を指定しています。
https://wpdev.uservoice.com/forums/110705-universal-windows-platform/suggestions/7232264-add-markup-extensions-to-and-improve-winrt-xaml

また、Noesisは先週v2.0製品を発売しましたが、かなり印象的です。 そのXamlシステムはすでにマークアップ拡張機能（C ++で、途中でC＃を使用）を備えており、仕様に到達するのに7年もかかりませんでした。 インディーデベロッパーも無料で利用できるようになりました。 AmmyUIのサポートを考慮に入れると、XamlモデルがATMに移行する限り、これが私のリストの一番上にあると言わざるを得ません。

http://www.noesisengine.com/

ねえ@karelzおそらくあなたはこれについてコメントすることができるかもしれません。 しかし、現在発生しているUWP Xamlの「仕様」がこの問題と何らかの相関関係があるかどうかを知っていますか？ そうでない場合、それができるかどうか知っていますか？ ここではクレイジーなアイデアですが、それが助けられれば、1つの価格で2つの問題を解決するのは良いことかもしれません。 UWPの投票にもメッセージを残しましたが、ここでもpingを実行することにしました。

@ Mike-EEE UWP Xaml "spec"は、おそらく別の組織によって推進されています（Windowsではそう思います）-ユーザーボイスの詳細を尋ねるのがおそらく最良のチャネルです。

ええ、私はそれを恐れていました。 😛私はそこで返事をもらったが、正直なところ、それは私にはあまり意味がない。

私が理解できることから、彼らは彼らの仕様プロセスで非公開のアプローチを取り続けるつもりであるように見えます。 これは、前回と同じ結果になり、誰も使用または採用したくないAPIで終わるように思われるため、懸念されます。

たぶん彼らは彼らの仕事について不平を言う開発者を密かに楽しんでいます。 :)

いずれにせよ、これを読んでいて、透過的なオープンソースのコラボレーションと開発の支持者であり、このドメインへのasp / .NET Coreのイニシアチブの成功の一部であることを楽しんでいる場合は、少し時間を取ってください。 WPDev UserVoiceに送信し、同じことを行うように促すメモを送信します。 リンクは前に述べましたが、ここでも電子メールからこれを読んでいる人のためのものです：
https://wpdev.uservoice.com/forums/110705-universal-windows-platform/suggestions/7232264-add-markup-extensions-to-and-improve-winrt-xaml

@birbilisを呼び出して、そこでの彼の以前の貢献に感謝しなければなりません。 私たち全員がここで使用するプロセスを促進するために誰もが貸すことができる追加の親切な言葉をいただければ幸いです。 👍

ため息...ユーザーボイスと同じように、人々に投票してもらい、最終的には人気があったとしても何もしないでください。

アップデート：
https://github.com/microsoft/xaml-standard

@ Mike-EEEはこれで非常に喜ぶと確信しています; P

それは素晴らしい動きです。 @ RichiCoder1を共有していただきありがとうございます

残念ながら、これはUIのみです。 SharepointやWFのようなXAMLの他の使用法はおそらく出ています。

ただし、少なくとも、サポートされているすべてのプラットフォームでXAMLを標準化するのに役立ちます。

いい動きだ！

彼らがそれを層に分割することを願っています

たとえば、UI以外のベースのXAMLレイヤーとは別に、XAML3Dレイヤーが必要です。

@galvesribeiro誰かが問題を作成したようです： https ：//github.com/Microsoft/xaml-standard/issues/23 +1しますが、最終的な標準が分割されない理由はありません。

@ Mike-EEEはこれで非常に喜ぶと確信しています; P

ハハ、そうですね、@ RichiCoder1！ それはすべて間違っていて壊れていて、どこにあるべきかどこにもありませんが、それは始まりです。 ;） 私たちに知らせていただきありがとうございます。 👍

そして、誰かがhttps://github.com/Microsoft/xaml-standard/issues/23を作成しているのを見て、私が作成する必要がないことを非常に嬉しく思います。 ;）;）;）

どうぞ、XAML標準にWF（Workflow Foundation）を含めることを検討してください!!。

@スリマンは賛成してください！
https://github.com/Microsoft/xaml-standard/issues/23

だから私は尋ねるのが嫌いです-そして私は良いレポ/問題の市民になるためにそうします、しかしこの問題はもう必要ですか？ つまり、レポはすでに50以上の問題を記録しており、この問題がこれまでにないほど詳細になっています。 それはすでにそれ自身の人生を持っているように見えます！

この問題をここで開いたままにする理由はありますか？ 私が何かを完全に誤解していない限り（かなり可能です）、Xaml標準を使用してここで目標を達成したと思います。 それはコミュニティ主導であり、私にとって最も重要なことはすべて個人的にです。 :)

@ Mike-EEE2つの問題には微妙な違いがあります。 1つは、XAML自体（厳密にはXAML自体）内で使用可能なAPIを標準化することに関するものであり、もう1つは、System.Xamlと同様の.NET標準コンポーネントとしてXAMLをサポートすることに関するもののようです。

@lokitothは、私がまだすべての新しい部分を手に入れようとしているので、これについての会話に間違いなくオープンです。 新しい.NETStandard2.0で「ちょうど機能する」コードを示す@terrajobstの優れた有益なビデオを視聴することを提案することから始めるのが最善だと思います。 私は個人的に、これがSystem.Xamlにどのように影響するかについて頭を悩ませていません。 私の考えは、それは「うまくいく」べきだということでしたが、おそらく私は今ここで間違っていると思い始めています（あまりにも良すぎて真実ではありません）。

そして正直なところ、Xaml Standardリポジトリでこれらのスレッドのいくつかを読んだ後、私は以前の提案に自分自身を蹴っていました（☕️コーヒーが私にそれをさせた、私は誓います！☕️）。 その外観から、「Xaml Standard」は、そのリポジトリで主に議論されているものであるため、「MSFT UX / UIStandard」という名前の方が適切です。 現状では、強力なシリアル化テクノロジーとしてのXamlは、（そこで努力を重ねてきたいくつかの勇敢な声を除いて）まったく提示/展示/強調されておらず、これもまた、いくつかの切断/混乱につながっています。

私は個人的に、これがSystem.Xamlにどのように影響するかについて頭を悩ませていません。

アセンブリを調べて、依存関係ツリーが.NET Standard2.0コンテキストでロード可能かどうかを確認する必要があります。 純粋な.NETの場合は、機能する可能性があります（ただし、.NET Coreのツールチェーンに組み込まれるBAML、Embedded Resourcesなどのコンパイル時のアイテムセット全体があります）。

その外観から、「Xaml Standard」は、そのリポジトリで主に議論されているものであるため、「MSFT UX / UIStandard」という名前の方が適切です。

これは、UWP / Xamarin.Formsのコンテキストで発表された機能であると思います。つまり、「BigXaml」に触れたことがない可能性のある、これら2つのプラットフォームに焦点を当てた開発者が主に貢献しています。 いくつかの「WPFXAML方言をすべて持ってくる」問題が開かれているのがわかりますが。

チームが行うべきクリーンアップがたくさんあり、現在、新しい問題の発生率が貢献している人々の数に比べてかなり高いことを考えると、チームがそれをどこに持っていくかを確認するためにもう少し時間を与えます。

@ Mike-EEE @terrajobst @terrajobst @cwensley @mellinoe
XamlStandardで問題を作成しました。
https://github.com/Microsoft/xaml-standard/issues/57

頭を上げて会話に貢献してくれてありがとう、@ juepiezhongren！

@lokitoth https://github.com/Microsoft/xaml-standard/issues/23は日光に適さないと判断されたため、この問題をそのままにしておくことができてうれしいです。

ただし、私は新しい問題を作成しました。これは、目前の問題をより適切に説明できると思います。https ：//github.com/Microsoft/xaml-standardに賛成票や投稿を追加しておくと便利です。

明確にするために、あなたが探しているのは実際には_JavaScript_ + HTML5 + CSS3で生成されたアーティファクトです。 TypeScriptは実際にはJSのトランスパイラーです。 MSFTは、.NETトランスパイラーを作成して、ブラウズで効果的に実行される標準準拠のJS（ JSILなど）を作成する代わりに、C＃の作成者の貴重な時間を費やして、効果的かつ最終的に競合するものを作成することにしました。

私はこれを始めないでくださいと言いますが、私は今までにやめたとは思いません。 😛

また、 CSHTML5は@weitzhandlerに非常に近いものですが、クライアント/サーバーアセンブリ（PCLなど）間でコードを共有することはできません。 そのため、2つの別個の互換性のないコードベースを維持することになり、.NETとJS（またはTypeScript😉）の間で同じコスト/ビジネスの問題が発生します。これは、厳密にはNodeJSソリューションには存在しません。

私の夢は、ドットネットコアを備えたデスクトップアプリにandroid xmlui書き込みスタイルを使用することです。 はい、そうです！！

XAMLを.NETCoreに移植するためのあらゆる努力は、私が志願するつもりです。

CoreWf （ネット標準2.0のWorkflowFoundation）の変更では、 XamlからDynamicActivityをロードできるようにするには、System.Xamlまたはより互換性のあるPortable.Xaml実装がおそらく必要になることがわかります。 CoreWfを.netフレームワークで実行し、System.Xamlを使用して基本的なDynamicActivityを読み込んでいますが、Portable.Xamlを使用した.netコアの解析状態が無効であるために失敗します。

1つの質問は、System.XamlのコードがMitライセンスの参照ソースリポジトリに追加されないのはなぜですか？ ライセンス、特許、その他の問題はありますか？ 問題がない場合は、このコードを参照ソースに追加すると、コミュニティである私たちがCoreWfをサポートするために必要な移植を行うことができます。 参照ソースリポジトリは、MicrosoftがSystem.Xamlをサポートすることを確約しません。 System.Xamlを開くように要求する問題をそこに追加する必要がありますか？

System.Xamlが開かれていない場合、WorkflowFoundationのXamlコードを解析およびトークン化するための正しい手順を説明するドキュメント（Xaml仕様以外）またはテスト形式のサポートを入手できますか？

ちょっとFWIW @ karelzここでDevOpsシナリオにいくつかの考えを入れました：
https://visualstudio.uservoice.com/forums/121579-visual-studio-ide/suggestions/31381861-innovate-the-xaml-designer-dawg

Visual Studio Xaml Designerでのいくつかのクールな出来事に基づいて：
https://blogs.msdn.microsoft.com/visualstudio/2017/09/11/a-significant-update-to-the-xaml-designer/

私がそれをしている間、私はここでそれについて言及すると思いました。 👍その上、このスレッドはバンプのために延期されています。 😆

@weitzhandler uを更新する必要があります。mono-wasmはアルファ版であるため、jsを忘れ始める時期が近づいています。

@weitzhandler 2年または3年rが必要ですが、これは単なるフルスタックではなく、.netのユニバーサルスタックです。

CoreRTも搭載されています-https ：//github.com/dotnet/corert/pull/4480 。 来年は、本番環境に対応したHTML + CSS + C＃コンボを期待しています。

提案された.net互換性パックには、おそらくステータスがあり、この問題にリンクされているSystem.Xamlが含まれています。

どうやらこの問題はcompatpack 2.1にリンクされていますか？ 誰かが確認できますか？ netfx-compat-packのタグが付けられているようですが、バージョンは付けられていません。 ただし、これまでに発生したことはすべて引き継ぎます。 😄

がっかりするのは嫌いですが、comaptパックの問題を一括更新しているときに、誤ってこれを2.1とマークしたと思います。 おそらくステータスを提案に反映するために、Futureに移動しました。

@ Mike-EEExamarin.wasmが到着するようです。
https://github.com/mono/mono/pull/5924#issuecomment -343551464

更新の紳士をありがとう。 私のことを考えてくれてありがとう。 :) @terrajobstは本当に残念ですが、チェックインと更新に時間を割いていただきありがとうございます。 あなたがまだこのスレッドを購読しているかどうかはわかりませんでした。 👼

恥知らずにプロジェクトをプラグインするのに時間がかかっているので（そして、公式のXaml修正を取得するまでにはしばらく時間がかかります）、私はこの1年をExtendedXmlSerializerのv2の支援に費やしてきました。最近リリースされました。 マークアップ拡張機能とアタッチされたプロパティ（POCOで機能し、 DependencyObject不要）の実験的なサポートと、 protobufスタイルのパラメーター化されたシリアル化を備えています。

System.Xamlが到着するのを待っている間に、Xaml風の機能を探している（または追加している）場合は、気軽にチェックアウトするか、フィードバックを提供するか、（さらに良いことに）リポジトリでPRを送信してください。 👍

https://blogs.msdn.microsoft.com/dotnet/2018/05/07/net-core-3-and-support-for-windows-desktop-applications/

@danmosemsft 3.0デスクトップイニシアチブの一部としてSDKプロジェクトでWorkflowFoundation xamlがサポートされますか？

@lokki計画はわかりません。 @terrajobst @karelz？

@danmosemsft
「.NETCoreの一部としてUIフレームワークを提供する」という問題がないのはなぜですか？

この問題は、UIフレームワークの欠如について具体的に説明しておらず、ここの人々がそれを認識しているようには見えません。
これを参照してください： https ：//github.com/Microsoft/xaml-standard/issues/232

@weitzhandlerこの問題は、今では私にとって非常に理にかなっています。 説明してくれてありがとう。

.NET標準にSystem.Xamlが含まれていると、特にXAML標準と一緒に役立つことがわかります。

「デスクトップイニシアチブ」を正しく理解していれば、Windowsのみを対象としている限り、過去に使用できた.NETライブラリを使用できるはずです（アプリが環境に動的に適応できるかどうかはわかりません）。メインアプリが実行できない場合（たとえば、Windows OSが見つからない場合は起動しない）、プラットフォーム固有のものを呼び出す複数の.NETCoreアセンブリを作成することで実行できます。アプリが実行されていることを検出したプラットフォームに応じて、オンデマンドでそれらをロードします）

@birbilisでは不十分です。 同じXAMLは、すべてのプラットフォームで等しくレンダリングする必要があります。

デスクトップイニシアチブはXAMLに関するものではなく、.NET Coreが最小公分母のサイロではなく、特定のプラットフォームをターゲットにできる（または理想的には実行中のプラットフォームに動的に適応できる）アプリを可能にすることです。それらを最大限に活用し、プラットフォーム固有の統合などを行います。この機能の上に機能ベースのAPIを構築して、特定の機能の可用性を照会するだけのアプリを作成できるようにすることができます。 また、抽象化/互換性APIをその上に構築して、APIの作成者がサポートすることに関心のあるプラットフォームごとに異なる実装にフックすることもできます。

今のところ、 Portable.XamlはSystem.Xamlに非常に近いと思います。 問題を見つけた場合は、フィードバックをお寄せください。

WPFチーム（@ dotnet / wpf-developers）は、.NET Core3.0用のWPFのオープンソーシングを発表しました。 この一環として、.NET Core 3.0のプレビュービルドにはSystem.Xamlが含まれるようになり、対応するソースはhttps://www.github.com/dotnet/wpfで入手できます。

ところで