前回も疑問に思っていたけれど、VS2017にアップデートがあった場合、アップデートダイアログが出てChecking for Updateが表示されたままになる。どうやら裏でダウンロードしているらしい。毎回無視してCloseして作業を始めてしまう。
VS2017はマイクロソフトだしこんな感じかな。
前回も疑問に思っていたけれど、VS2017にアップデートがあった場合、アップデートダイアログが出てChecking for Updateが表示されたままになる。どうやら裏でダウンロードしているらしい。毎回無視してCloseして作業を始めてしまう。
VS2017はマイクロソフトだしこんな感じかな。
最近、OneDriveの同期フォルダにローカルのgitリポジトリフォルダを置いてソースをMacとWinで共有している。今は一人でソースをアップデードしているのでこれで十分たりている。Winからコードをアップデートし、コミットすると同時にOneDriveの常駐アプリが即座にファイルをアップロードし、Macのソースコードもアップデートされる。
WinではUWPのコードを中心にアップデート、PCLの共通ライブラリはどちらからも必要な時にアップデートする。
Android のコードはWin、Macどちらでもエミュレータが使えるので慣れた環境が良いのだけれど、今後のモバイル環境、マシン依存を考えて、MBPでアップデートすることにする。
iPhoneのコードはWinでも更新可能だけれど、Win上でデバッグするとMac上でAppleのシュミレータが起動されてMac上でオペレーションをする事になるので、こちらもMBPに以降する。WinのUWPアプリは圧倒的にダウンロードするが少ないのでiPhone, Android, UWPの優先順位で行く。
そして本題ですが、
OneDriveを使っていて、Win10上でノートパッドを使って.txtファイルをOneDriveの同期フォルダに作成した。そして、iPhone、iPadで同じファイルを更新したかった。
しかし、iOS版のOneDriveで、TXTファイルの開いて内容を見ることはできるのだが、テキストの入力ができない。外部コマンドを見るも、txtファイルをそのアプリに添付するか、ファイルをダウンロードしてローカルに保存しようとする。Appleのメモ帳アプリでもTXTファイルを添付ファイルにされてしまう。
つまり、iOSからは直接OneDriveのファイルは更新できなくなっている。アプリそれぞれのデータファイルとしてしか保存できず。そのアップデートしたテキストもOneDriveに戻すこともできず。
PDFファイルで保存すれば、MSWORDかその他のPDFエディタを開けるけれど、TXTでは対応していない。
その線で次のアプリを考えて見るか。
Xamarinでクロスプラットフォームのコードを書いていてハマった点。
少々込み入った話ではあるけれど、Xamarinでクロスプラットフォームプロジェクトを使っていてメインで共有されるコードに使えないnamespaceが結構あります。
今回はまった点としては、
・project.ios、project.UWP、project.Androidのそれぞれの参照には、System.Http.Netが定義できるが、肝心なメインのprojectの参照には追加できない。
ターゲットの定義上で、.NET Standardが定義されているのが理由のように見える。
ターゲットの定義に問題がありそうだけれど、各プラットフォームのプロジェクトで参照できるのに、肝心な部分でHttpClientが使えないのはちょっと痛い。
アプリの提出を優先して、各プラットフォームに書いてしまうことはできるけれど。どうしたもんかな。
追記:いろいろなサイトを検索して調べていますが、Mac版Xamarin Studioとかで設定が可能らしい。この辺をきっちり公開してる人っているのかな。。。参考リンク
追記2(解決):XMLDocumentはPCLではサポートされていないようです。参考リンク 理由はWindows Phone 8でXMLDocumentがサポートされていないからのようです。ターゲットからWindows Phone 8を外せればよいのでしょうが、PCLではデフォルトWindows 8.1とPhoneが入れられるようです。(プロファイルのリストがMac版Xamarin Studioで設定できます)
個人的にはテスト用にWindows Mobile 10を持っているけれど、一番シェアの少ない(ほとんどユーザーのいない)Windows Phoneのせいで・・・
解決策としては、System.Xml.Linq.XDocumentを使えということですね。\o_o;/
追記3:プログラムをXDocumentベースで書き換えました。結局XMLDocumentよりも素直な書き方になった感じ。まぁプログラムも2回目書き直すときは最初よりも簡単にかけるもの。仮にNativeコードベースでクロスプラットフォームのプロジェクトを作る場合は、Xamarinのクラスライブラリプロジェクトを作って、参照(Refference)で呼ぶ必要がある。DLLにして一つのモジュールとしてコンパイルする。Shared Projectは、参照設定とNuGetのパッケージは使えないので。
最近UWPでプロジェクトを進めていますが、サンプルをダウンロードしてWindows10上で実行することがあります。その時にソリューションを保存したドライブがNTFSじゃないと以下のエラーで止まります。
以下のメッセージはXamarinで公開されているサンプルコード(WorkingWithListview.UWP)で出たエラー。
1>—— 配置開始: プロジェクト:WorkingWithListview.UWP, 構成: Debug x86 ——
1>新しいクリーンなレイアウトを作成しています…
1>レイアウトにファイル (合計 18 MB) をコピーしています…
1>必要なフレームワークがインストールされているかどうかを確認しています…
1>アプリケーションをレイアウトから実行するように登録しています…
1>DEP0700: アプリケーションの登録に失敗しました。[0x80073CFD] Windows cannot deploy to path Debug of file system type exFAT.
========== 配置: 0 正常終了、1 失敗、0 スキップ ==========
今回はMac/Win両方で使う為のUSBドライブ(exFAT)だったので、デスクトップマシン内にあるハードディスク(D: 1TB)にソリューションをフォルダごとコピーして実行できるようになりましたが、CドライブがSSDで256GBでDドライブがexFATというケースはあると思います。
参考までに
投稿が、日記のようになってきているが、日を追って進んでいるというで。一般的には進捗とか言うんだろうけど、そうなると仕事っぽく報告とか嫌いな感じになっていくのでそういう話はやめて書きたいことだけ書く。
C#プロジェクトのテンプレートに”Shared Project”というものがあり、どのくらいクロスプラットフォーム間でコードが共有できるか試してみました。
結局のところC#で書いたクラスをネームスペース上で使えるようになるというもの。
Desktop Appなり、UWPなり、Androidなり、iOSに依存したコードは書いた時点で、プロジェクト側がエラーを検知するようになっている。
一つのソリューション内に違うプラットフォーム用にプロジェクトを作っておいて、同じコードを使いまわすという想定なのだろう。
C#を中心にコードを書くのに、悪くない環境だ。下にあるスクリーンショットは書くプロジェクトのアイコンを示したもの。
この中でCSSharedProject1というのがShared Project。ちなみに、CPPSharedというのはWin32 C++のShared Project。それぞれ同じ言語でしか共有はできくなっている。Win32でDLLを書いて.NET側からDllImportなりでAPIを取り込むのとどちらがいいのかは、この時点では不明。
Win32で書かれた共有コードをC#に共有するためにはC++CLRでも書けるので、それぞれのクロスプラットフォームではコードレベルでの共有が有効かもしれない。
この共有プロジェクトを今回、VisualStudio2017 Communityに含まれることになった、XamarinでAndoidとiOSで共有ができることが確認できた。
注意が必要なのは、XamarinでiOSプロジェクトを書くときは、ネットワーク上にXCodeとVS2017がインストールされたMacが必要になる。しかもXCodeはiOS用にライセンスが必要。幸いiOS用のライセンスはあったのでVS2017 Community for Macをインストールしてサンプルをデバッグしてみた。
Windowsマシンからデバッグをスタートさせ、デバイスにiOS Simulatorを選ぶ。
その時点ではMacにVS2017がインストールされたいなかったので、リモートデバッグができないメッセージがでる。さらにXamarinのガイドでMac側のリモートログインを有効にしないといけないとのこと。(SSHを有効にする)
さらにSSHを有効にし、VS2017をインストールしたところで、デバッグを走らせると今度はXCodeのSDKのバージョンが古い。
今日はここまでで作業終了。
なんという長い手順だ。しかし、MacにVisual Studioをインストールして、リモートデバッグとはMSFTの好むやり方だ。
最近話題になっている、IoTデバイス(ラズパイ)のデバッグも同じ形式。ラズパイにIoT版Windowsをインストールして、デスクトップのVisualStudioからコードを書いてデバッグするという方法をとっている。もともとラズパイはスタンドアローンでパソコンとして動作するものをどうしてもう一台のパソコンを使ってプログラムを書かないといけないのか。Windowsをラズパイにインストールすればそれでいいはずなのに。
コードの共有ができたところで今日はここまで。C#で一度書けば、今のところ考えられる全てのデバイスで使えるのは良いところであろう。で?Arduinoは?やらないの?