Visual Studio 2013 で Entity Framework のコードジェネレータが動かないとお困りのあなたへ

Visual Studio 2013 を C ドライブ以外のドライブにインストールし、Entity Framework のコードジェネレータを動かした時のこと。ツールが存在しないと怒られ、コードが生成されませんでした。
原因は単純で、環境変数 VS120COMNTOOLS のパスがインストール時に C: ドライブ前提で設定されているからです。この現象、CTP版だった頃から発生していた現象で、リリース後も残っていました。
単純に、環境変数のパス文字列を正しいドライブに修正し、Visual Studio 2013を再起動するだけです。
ちなみに、PowerShell で 環境変数を表示させるには「dir Env:」と入力します。

広告

Azure WebSites の .NET Framework が 4.5.1 にアップデートされました。

Azure WebSites の .NET Framework が、4.5 から 4.5.1 にインプレースアップデートされたみたいですね。うちのテナントのインスタンスも確かめなくちゃ。ちなみに、この情報は、しばやん大先生のブログ記事を見つけてくれた、うちの会社の若い子によります。ありがとう。若い子!

何が重要かって、TransactionScope の async/await インフラストラクチャ対応ですよ。Entity Framework 6 の DbContext が非同期実行に対応しているのに対し、TransactionScope は対応していなかったんです。

具体的には、await される度にどのスレッドで再開されるかわからないのが async/await です(実際は、WPFだとUIスレッドに戻ってきたり、ASP.NETだとどのスレッドかわからないけど HttpContext は同一だったりし、フレームワークに合ったコンテキストの保ち方をします)。しかし、EF5 までの DbContext も、.NET 4.5 までの TransactionScope もスレッド依存だったんですね。TransactionScope に関しては、ライフサイクルをスレッドで管理していたようで(おそらく)、await に対応するには、SyncrhonizationContext で管理する必要があると考えられます。おそらく 4.5.1 からそれに対応できたのでしょう。TransctionScope コンストラクタのパラメータに、非同期対応を行うか同課のパラメータが追加されました。ちなみに、.NET 4.5.1 は、Windows Server 2012 R2 にはインストールされているので、ずいぶん前にリリースされています。

しかし、ちょーお手軽 PaaS (IIS の間貸し)である Azure WebSites は、ベースOSがWindows Server 2012 のまま。.NET Framework だけアップデートしようにも、IaaS ではないので、対応を待つしかありませんでした。そして、いつの間にか更新されていました。

TransactionScope が async/await に非対応なら、それ相当の書き方があるのでいいっちゃいいんですが、ようは、トランザクション区間に入って出るまでを1スレッドで実行しなくちゃいけないので、せっかくの async/await インフラストラクチャもタスクパケットの占有時間が長いわけです。CPU時間がもったいないことになるのです。

さて、これで心おきなく Entity Framework と TransactionScope で async/await できるぞ!

Office用アプリ開発概要:セミナー登壇資料

先日開催されました、「技術ひろば.net 勉強会 11月30日」にて、「Office用アプリ開発概要」と題しまして、登壇させていただきました。

このセッションの中で、Excelの日時シリアル値をJavaScriptのDate型に変換するコードを紹介しましたところ、参加されているみなさんよりコード化を希望されましたので、以下に貼り付けておきます。ライブラリ化するほどのことでもないので、利用者ご自身の責任にてお使いください。

var oneDayInMilliseconds = 86400000; // 1日分のミリ秒
// 1900/1/1 が 1ということは、1899/12/31 が 0 である。
var excelOriginDateInMilliseconds = new Date(1899, 11, 31).getTime();
var val1 = Math.floor(excelDateTimeSerialValue); // Excelシリアル値の整数部分
var val2 = excelDateTimeSerialValue - val1; // Excelシリアル値の小数部分
// 日付部分から1日引く。// 2013/10/26 10:00 は、数量的には「2013/10/25までの日数 と 10 時間」という意味である。
var day = oneDayInMilliseconds * (val1 - 1);
var time = oneDayInMilliseconds * val2;
var dateTime = day + time + excelOriginDateInMilliseconds;
// Dateオブジェクトの生成
var result = new Date();
result.setTime(dateTime);

Windows Azure上にネイティブコードを含むWebアプリケーションを配備する

マイクロソフト社のプラットフォーム「Windows Azure」に、ネイティブコードを含むアプリケーションを配備するための、抑えておくべきコト。今回は「WebSites」もしくは「クラウドサービス」の「Webロール」から、ネイティブコードであるDLLをP/Invokeするための環境を構築する上で抑えておくべきポイントを挙げます。記事の執筆時では、IDEはVisual Studio 2013 RCです。

1.IISでネイティブコードを走らせる

IISにおけるネイティブコードには種類があります。「Fast CGI」「HTTPハンドラ」「P/Invoke」といった、ネイティブコードを走らせるにも選択肢があります。当記事では、「P/Invoke」について述べます。

 

P/Invokeは、マネージドコードをターゲットに開発されたアプリケーションから、既存資産の利用、速度向上、プラットフォームのAPIの利用などの目的で、手軽にネイティブコードがコールできる.NET側に実装されているインターフェイスです。Win32 API群をはじめとする、既存の(そして古くから存在する)DLLに改修を行うことなく、マネージドコードから関数を利用できるため、資産活用の観点でとても有用です。また、特殊な計算や機能を持ったライブラリがネイティブコードで書かれているケースは多く、それらを手軽に利用しようとしたときにもP/Invokeは有用な相互運用手段です。

 

IIS上に配備するマネージドコードで構成されたWebアプリケーションも、もちろんP/Invokeを使用することができます。ただし、IISのセキュリティモデルの影響は受けるため、Webアプリケーションでネイティブコードの実行を許可させるためには多少設定等必要となります。

2.Azure上に配備するためには

Azure上でネイティブコードを実行するには、いくつかの制約があり、それに準じたDLLの作成や、Azure上のインスタンスの設定が必要となります。

(1)カスタムのDLLのビルドのターゲットは64ビットかつReleaseビルドでなければならない。

(2)上記DLLから参照される他のDLLも64ビットでなければならない。

※2013年12月28日追記:この修正記事執筆時においては、Azure WebSitesのOSはWindows Server 2012だと考えられます。2012 R2ではなさそうです。この環境において、ネイティブアプリケーションを Visual Studio 2013 で開発し、ランタイムライブラリ MSVCR120.DLL を配備する必要がある場合は注意が必要です。P/Invoke によるDLLの遅延ロード時にBadImageFormatExeptionが発生します。後述するプラットフォームの選択において64ビットを選択しても発生します。VC++のランタイムが2012 R2より前のプラットフォームに対応していないと思われます。この場合は、ネイティブアプリケーションにランタイムを静的リンクしてください(コンパイルオプション /MT)。いずれベースOSがServer 2012 R2になったり、VS2013のサービスパックが出た時点で解消されることを願って…。

(3)参照される他のDLLのうち、Azure上のOSイメージに含まれていないDLLは、カスタムDLL同様、Webアプリケーションと共に配備しなければならない。

(4)WebアプリケーションのWeb.configに、「完全信頼」のセキュリティポリシを記述する。※2013/12/28追記:<trustLevel>で、各信頼レベルごとの設定ファイルを指定し、<trust>で、どの信頼レベルで稼働させるかを選択します。

<system.web>
  <securityPolicy>
    <trustLevel name=”Full” policyFile=”internal” />
  </securityPolicy>
<trust level=”Full” originUrl=”” processRequestInApplicationTrust=”true” />

</system.web>

なお、「信頼レベル」が「Full」というのは、「無制限のアクセス」ということです。逆に「Minimal」というのは、「最小レベルのアクセス」しか許可されない、最も制約の多い信頼レベルです。ネイティブコードを動かすには、無制限のアクセスが必要ということです。文言とセキュリティレベルの高さは逆なので注意が必用です。

そして、この信頼レベルの設定は、提供されているIISの規定値から制約を強めるための仕組みのようです。つまり、ホスティングサービスが既定でどの信頼レベルで稼働しているかが、アプリケーションの制約に影響します。Azure WebSites は既定で「Full」で稼働しているようです。従って、上記設定をWeb.configに記述しなくてもネイティブコードは動きます。ただ、Azure WebSitesが既定「Full」で提供され続けるかどうかは分かりませんが、変更されるとなればアプリケーションに大きな影響があるため、アナウンスはされると思いますが…。

(5)Azureにおいて、「クラウドサービス」のWebロール・ワーカーロールは64ビット環境なので配備可能。

(6)WebSitesは、モードが「標準」(環境がサブスクリプションで占有可能なモード)であり、かつ、プラットフォームを64ビットで選択した場合のみ配備可能。概念的にはWindows Serverインスタンス1つを64ビット環境で占有しないとダメってことね。

快適なNative on Azure lifeを!

2013-11-07 追記:

MSDNにより詳しい内容が掲載されました。

http://msdn.microsoft.com/ja-jp/library/windowsazure/hh694038.aspx

イントロダクション – Apps for Officeの開発環境を構築する

Microsoft Officeは、Office 2013から、そのドキュメント上にWebアプリを配置し、ドキュメントの参照や編集が行えるようになりました。一般的なWebアプリ開発者ならば、自身のWebアプリをExcelやWord上で稼働させることができるようになったのです。

これまでExcelを業務に使用することによって情報共有が妨げられるといった課題は各所に散見されてきました。そのため、各種業務アプリケーションが開発され、主にWebとしてホストされてきました。しかし、今度はExcelのような操作感が得られず、業務がやりにくいといった声が聞かれました。そしてとうとう、Office 2013でこれら両方の課題を解決する新しいアプリケーションのモデルが提示されたのです。それが、Apps for Officeです。

Office用アプリ概要 – MSDN
http://msdn.microsoft.com/library/office/apps/jj220082(v=office.15)

このブログシリーズでは、Excel向けアプリの開発を例に、Apps for Officeの開発の流れを追っていきます。ブログ中ではVisual StudioとWindows Azureを使用していますが、Webサーバおよびデータベースの選択は自由ですので、必須というわけではありません。ご自身の開発環境・言語に合わせ、読み替えてください。

アプリの開発だけならば、特別なツールは必要ありません。テキストエディタと、動作検証用にOffice 2013が必要なだけです。Webアプリとして開発し、アプリケーションのマニフェスト(XML)をOfficeに読み込ませるだけです。必要な作業スコープに応じて、以下の環境をそろえてください。

  1. Webアプリの開発環境
    Webアプリとして開発するための環境です。Eclipse・Apache・PHP・MySQLでも構いませんし、Visual Studio・IIS Express・SQL Server Expressでも構いません。
  2. Webアプリの配備環境
    アプリケーションを稼働させるためのサーバ側の環境です。LAMPの構成をオンプレミスで構成しても構いませんし、AWSで用意しても構いません。Windows Azure WebSitesといったお手軽なPaaSでもかまいません。
  3. Office 2013を稼働させる環境
    Office 2013の稼働には、Windowsが必要です。Windows XPはすでに対象外です。
    Office 2013の稼働要件 – TechNet
    http://technet.microsoft.com/ja-jp/library/ee624351.aspx
  4. ストア申請に必要な有効なOffice 365アカウント
    アプリをストアに申請し、販売する場合、Office 365の有効なアカウントが必要です。これは、販売者側のポータルサイト「Seller Dashboard」のアクティベーションの要件に、有効なOffice 365(E系もしくはMidsize Business)が必要だからです。この、E系もしくはM系のOffice 365テナントでは、Apps for Officeのオンライン開発統合環境であるNapaがインストール可能です。また、ストアへの申請は、このツールを経由して実施します。社内ネットワークのみに利用を限定するなど発行する範囲を限定できるならば、Office 365は必須ではありません。
    Create apps for Office and SharePoint by using ‘Napa’ Office 365 Development Tools – MSDN
    http://msdn.microsoft.com/en-us/library/jj220038.aspx

それでは今後、以下のように記事を追加していきます。おたのしみに。

  1. Hello World
  2. Excel向けTask Paneアプリの簡単な例
  3. Excel:表の設計とJavaScriptコード
  4. Excel:Excelの日時シリアル値とJavaScriptのDate型の相互変換
  5. Excel:クライアント用アプリとWeb Appの初期化の違い
  6. Excel:nullはバインドできない
  7. Excel:参照不可能となっている「名前」は動作不良のもと

Apps for Office セミナーで登壇してきました


Excelのダッシュボードツール化 from Hirotada Watanabe

Apps for Officeは、Officeクライアント(Word, Excel, PowerPoint, Outlook等)の中で動くWebアプリケーションのことで、Office用APIを介して、ドキュメントのデータにアクセスできます。つまり、Webシステム側とExcelドキュメント側のデータの相互運用が可能となる仕組みです。これまでも、Excelは外部データの取り込みが可能でした。しかし、Webアプリケーションがそのまま動く仕組みは今回のApps for Officeがはじめてです。

また、エンドユーザに近いところにあるツールはとても重要で、このツールでできることが中小企業はもとよりExcel「データベース」の依存率の高い零細企業にとって重要になります。それは、データの蓄積とドキュメント化を分離できるようになり、データの共有が進み、集計による経営情報の視覚化が可能になることを示します。

今回デモでは、マーケティング情報の参照をイメージした、Excelのピボットテーブルのデモを行いました。ピボットテーブルで集計する対象のデータをApps for Office経由で取得しようとするものです。また、データの取得にはパラメータが必要です。そのパラメータは表として定義します。つまり、Apps for Officeの役割は主に以下の3つです。

  1. Excelのシート上のデータを読み取る(パラメータ用)
  2. Webサービスへ問い合わせる(データ取得)
  3. 取得したデータをExcelシート上へ出力する(ピボット集計の元データ)

これらを開発するために、以下の構成としています。

  1. Webサービス側はWindows Azure Web Sitesにてホスト。ASP.NET Web APIを使用してAPIを実装。DBはSQL Databaseを使用。
  2. Apps for Office アプリケーションは上記Web Sitesにホスト。
  3. アプリケーションのマニフェストファイルは、オンプレミスのファイルサーバ上に配備し、UCNにてアクセス可能とした。
  4. Excelのセキュリティ設定で、UCNパスを信頼するパスに追加。

今回のデモでは、マーケットプレイスに置いたわけでもなく、SharePointに置いたわけでもありません。企業用のApps for Office配備モデルの1つである、ファイルサーバへ置きました。

さて、下のキャプチャは、Excelのデモアプリを稼働させる前に、元データの説明に使ったアプリケーションです。これは私が今開発しているサービスの画面の一部です。青いピンから周囲 500m の範囲にあるロケーション情報を参照しています。Excel上には、このように検索されるロケーション情報をダウンロードし、場所によって異なる「人気度」を集計するデモを行いました。
青いピンから半径500mのロケーション情報

Apps for Office勉強会で登壇してきました

先日行われた、Apps for Office 勉強会 第1回に登壇してきました。生意気にも喋ってきたわけですが、そこで喋った内容がコレ。新しいOfficeの新しい開発モデルである「Apps for Office」におけるサーバサイドです。

Apps for Officeは、Officeアプリケーション(Excelなど)の画面内にホストされるHTML+JavaScriptで書かれたアプリケーションです。Office専用のランタイム上で稼働し、JavaScript APIを通じてOfficeドキュメントと相互運用を行います。また、Apps for Officeから外部のネットワークにアクセス可能なため、Web上に転がっている数多のAPIと通信でき、つまり、Officeアプリケーションを、WebサービスのクライアントUIとすることができます。

従来、Officeドキュメントはドキュメントだったわけで、例えば、請求書をExcelブックで作成したとすると、請求書を発行するたびにExcelブックをコピーして作成していたわけです。そして、請求情報はExcelブック中にしかなく、さらに、担当者のPCにしかなかったりするのです。Excelでレイアウトし、印刷することを優先した結果です。

これが、Apps for Officeでどう改善できるかというと、請求データはサーバに、Excelブックは単なるレポートのレイアウトだけになり、請求書のフォーマットだけを保存したたった1つのファイルとなります。Apps for Officeを介してサーバからデータをロードし、Excelのセル上の所定の位置に顧客名や数値を表示させることができるのです。これによって、データの集約化と、Excelによる柔軟な印刷が可能となります。(もう、Webページの右上の「PDFでダウンロード」ボタンを押下しなくてもいいのです!)

その上で、サーバサイドをどう簡単に開発していくか、その構成はオンプレミスとクラウドでどう違うのかなど、Officeファイルがどう利用されるのか、そのシナリオを考えてみました。