クロスプラットフォーム開発-Windows MobileおよびWindows（.NET Compact Framework、C＃）

Compact Frameworkを使用してWindows Mobileプラットフォーム用のアプリケーションを開発する場合、デスクトップバージョンのWindows用に同じアプリケーションを構築するチャンスがあることを認識している開発者は多くありません。 私自身は、そのような可能性があると仮定して、これについて長い間考えていましたが、少なくとも何らかの形で何かとは考えていませんでした。



クロスプラットフォームビルドを成功させるために理解する必要があるいくつかの重要な側面があります。 ネットワークのさまざまな部分で知識を収集するのにかなりの時間を費やしましたが、場所によっては些細なことなので、微妙な点をhabrasocietyと共有することにしました。

第一に、第二に、第三に...

まず、最初にWindows Mobile用のアプリケーションを作成する必要があります（つまり、これがメインプラットフォームです）。 これは本当に重要です。 いくつかの理由がありますが、主な理由は、コンパクトフレームワークがコンパクトであり、クラスとクラスのプロパティが実質的に少ないことです。 つまり デスクトップとの互換性はありますが、一方的なものです。 デスクトップに向かってのみ。



第二に、アプリケーションにはまだ違いがあり、それらを個別にプログラムする必要があることを理解する必要があります。 たとえば、Windows Mobileの下部にある標準メニューは自動的に上に移動し、[キャンセル]および[その他]はあまり魅力的ではありません。 さらに、デスクトップには、原則として、InputPanelはありません。 つまり 基本的に、＃if #else #endifコンパイラによる指示の準備が必要です。



第三に、フォームの設計に関していくつかの制限があるという事実にも備える必要があります。 つまり、デスクトップが現在のターゲットとして選択されている場合、ビジュアルエディターでフォームを開くことはできません。すぐに、* .Designer.csは、モバイルフレームワークでサポートされていない多くのプロパティに遭遇するため、ロールバックする必要があります。



4番目に、* .csprojファイルを手動で編集し、ソリューションエクスプローラーに黄色の三角形を表示する必要があります-これは正常です:)



第5に、すべてのアセンブリと名前空間がデスクトップで100％動作しているわけではありません。 たとえば、SQL Server Compactがデスクトップ上に構築されているかどうかはまったくわかりません。 私はチェックしなかったので、約束しません。 SQLiteを使えば、すべてがうまくいくことは確かです（少し汗をかかなければなりませんが）。



第6に、デスクトップでアプリケーションをデバッグする方法を理解する必要があります。モバイルアプリケーションを構築するときは、デバイス、物理デバイス、またはエミュレータを選択する必要があることは誰もが知っているからです。



主な微妙さに対処してみましょう。

デスクトップターゲット

まず、Compact Framework用のプロジェクトを作成する必要があります。 Build-> Configuration Managerを使用して新しいターゲットを作成します。





その後、プロジェクトプロパティに条件付きコンパイルシンボルを追加します。





開始されました。 次に、正しいアセンブリが正しいターゲットに接続されていることを確認するために何をすべきかを見てみましょう。 デフォルトでは、csprojファイルにはターゲット分離がありません。

< ItemGroup >

< Reference Include ="mscorlib" />

< Reference Include ="System" />

< Reference Include ="System.Data" />

< Reference Include ="System.Drawing" />

< Reference Include ="System.Windows.Forms" />

< Reference Include ="System.Xml" />

</ ItemGroup >





* This source code was highlighted with Source Code Highlighter .

完全に制御するには、おおよそ次のフェイントを整理する必要があります。

< ItemGroup Condition =" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' " >

< Reference Include ="mscorlib" >

< Private > False </ Private >

</ Reference >

< Reference Include ="Microsoft.WindowsMobile, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" >

< SpecificVersion > False </ SpecificVersion >

< HintPath > ..\..\..\..\..\Program Files\Windows Mobile 6 SDK\Managed Libraries\Microsoft.WindowsMobile.dll </ HintPath >

</ Reference >

< Reference Include ="Microsoft.WindowsMobile.Status, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" >

< SpecificVersion > False </ SpecificVersion >

< HintPath > ..\..\..\..\..\Program Files\Windows Mobile 6 SDK\Managed Libraries\Microsoft.WindowsMobile.Status.dll </ HintPath >

</ Reference >

< Reference Include ="Microsoft.WindowsCE.Forms" >

< Private > True </ Private >

</ Reference >

< Reference Include ="System" />

< Reference Include ="System.Data" >

< Private > False </ Private >

</ Reference >

< Reference Include ="System.Windows.Forms" />

< Reference Include ="System.Drawing" />

< Reference Include ="System.Data.SQLite, Version=1.0.60.0, Culture=neutral, PublicKeyToken=1fdb50b1b62b4c84, processorArchitecture=MSIL" >

< Private > True </ Private >

< HintPath > ..\..\..\..\..\Program Files\SQLite.NET\bin\CompactFramework\SQLite.Interop.060.DLL </ HintPath >

</ Reference >

</ ItemGroup >



< ItemGroup Condition =" '$(Configuration)|$(Platform)' == 'Desktop|AnyCPU' " >

< Reference Include ="mscorlib" >

< Private > False </ Private >

< HintPath > C:\Windows\Microsoft.NET\Framework\v2.0.50727\mscorlib.dll </ HintPath >

</ Reference >

< Reference Include ="System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089, processorArchitecture=x86" >

< HintPath > C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.dll </ HintPath >

</ Reference >

< Reference Include ="System.Windows.Forms" >

< HintPath > C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Windows.Forms.dll </ HintPath >

</ Reference >

< Reference Include ="System.Drawing" >

< HintPath > C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Drawing.dll </ HintPath >

</ Reference >

< Reference Include ="System.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089, processorArchitecture=x86" />

< Reference Include ="System.Data.SQLite, Version=1.0.60.0, Culture=neutral, PublicKeyToken=db937bc2d44ff139, processorArchitecture=x86" >

< Private > True </ Private >

< HintPath > ..\..\..\..\..\Program Files\SQLite.NET\bin\System.Data.SQLite.DLL </ HintPath >

</ Reference >

</ ItemGroup >





* This source code was highlighted with Source Code Highlighter .

ご覧のとおり、ItemGroupブロックをターゲットで分離し、アセンブリへの異なるパスを示しています。 私がプロジェクトで一番忙しかったのはここだったと認めます。 正しいバージョンは、コンパイルエラーメッセージから直接引き裂かれました;） コンパイラは、そのような必要なアセンブリが見つからないと呪い、正しい値に置き換えました。 そして、すべてをやめようと何度か試みたのはここです。 そのようなエラーをグーグルで調べることは非常に悪いです。



csprojファイルを使用した巧妙な操作の結果、ソリューションエクスプローラーでそのようなナンセンスが得られます。





これは正常です Visual Studioは、そのような歪みにはあまり適していません（ただし、最終的には可能になります）。

#if #endif

アセンブリが正しく接続されると、各プラットフォームがサポートする最大値を使用できるようになります。 ただし、フォームデザイナの自動コード生成は、ここですべてを台無しにします。 したがって、可能であれば、最初にすべてを設計し、それを手動でのみ編集する必要があります-* .Designer.csが再生成されると、スタジオは編集を保存せず、＃if endifセクションを追加しません。



少しトリッキーな瞬間。 私のプロジェクトはQVGAとVGAの両方の解像度をサポートしていますが、フォーム上のDesigner.csでは、ClientSizeプロパティは常にQVGA解像度に対応しています。 デスクトップでは、特にVGAスキンがある場合に、240x268ウィンドウを使用するのは間違っています。 したがって、InitializeComponent（）の後のコンストラクターには、条件付きコンパイルセクションを配置します。

Size vertSize = new Size(480, 560);

Size horisSize = new Size(640, 480);





[...]

InitializeComponent();

#if Desktop

this .ClientSize = vertSize;

this .FormBorderStyle = FormBorderStyle.Fixed3D;

this .MaximizeBox = false ;

this .MouseWheel += new MouseEventHandler(MainController_MouseWheel);

#endif



* This source code was highlighted with Source Code Highlighter .

ご覧のとおり、Size型の2つの変数が宣言されています。 なぜこれが必要ですか？ 単純に、F9でClientSizeを切り替えて、画面の向きの変更をエミュレートします。 OnResizeをテストする必要がある場合に便利です。 そして、最終的には、800x480のネットブックがあります。それらの場合、すべてが画面に収まるのは横向きのみです:)



MouseWheelもデスクトップ上でのみ処理されることがわかります。

System.Diagnostics.Conditional

メソッドを収集するターゲットを示す便利な方法があります。

[Conditional(“Desktop”)]

public void SomeDesktopMethod()

{

}



* This source code was highlighted with Source Code Highlighter .

このメソッドでは、このメソッドへの呼び出しがコード内に存在できることが良いのですが、この属性を使用すると、他のターゲットでの呼び出しが単に無視されます！ #if #endifを使用する代替方法では、呼び出しが必要な場所で、目的のプラットフォームで呼び出しをコンパイルするかどうかをチェックする必要があると想定しています。

デスクトップのデバッグ

デバッグには2つの方法があります。 最初の（不便な）のは、bin \ Desktop \に移動してexeファイルを実行し、スタジオでDebug-Attatch to processと言うことです。 最初は、この方法が唯一の方法と思われます。 しかし！ メガハック、非公式でサポートされていない方法があります（ただし、VS2005とVS2008の両方で機能します）。 メソッドは次のとおりです。

1. スタジオで、ツール/オプションを開き、ツリーでデバイスツール/デバイスを選択します。
2. ドロップダウンメニューで、デスクトップでデバッグを整理する必要があるプラットフォームを選択します。 これは、必要に応じてすべてのプラットフォームで繰り返す必要があります。
3. 次に、任意のエミュレータを選択して、[名前を付けて保存...]をクリックする必要があります。 「マイコンピュータ」のコピーに名前を付けると便利です。
4. 次に、スタジオを閉じて、％USERPROFILE％\ Local Settings \ Application Data \ Microsoft \ CoreCon \ 1.0 \ conman_ds_platform.xslファイルをテキストエディターで開く必要があります。
5. ファイルでは、新しく作成した「デバイス」に対応する<DEVICE ...>要素を見つける必要があります
6. 次に、次の行を追加します-<PROPERTY ID = "IsDesktopDevice" Name = "IsDesktopDevice"> true </ PROPERTY>
   
   <PROPERTYCONTAINER>タグの直後。
7. conman_ds_platform.xslを保存してスタジオを再起動します

さて、デバッガーとデスクトップデバッグのすべての利点にアクセスできるようになりました。

おわりに

さて、この記事には、Windowsプロジェクトをビルドするプロセスで遭遇した主な落とし穴がリストされています。 さらに、すべては技術の問題でした-例外をキャッチし、その原因を把握しました。 それらの中には、デスクトップなどで明らかに異なるパスが見つかりませんでしたが、これは最初の問題と比較するとまったく何もありませんでした。



PS。 上記のほとんどすべては、長い検索の結果として苦しみましたが、今、デスクトップでデバッグする方法を探していたときに、コンパクトフレームワークのクロスプラットフォームコンパイルに関するスマートな記事に出会いました:)私の記事は決して翻訳ではありませんが、私はそれへのリンクを提供せざるを得ません。