できないので注意!
こんな感じで
データベースから生成を選んで接続しようとしても
==========
この要求のデータを取得できませんでした。
不明なプロパティ PrimaryFilePath
==========
ってエラーになるから注意してね!
※SQL Azureから生成するなよって話。
さっきの投稿でも書いた System.Web.Providers ですが、名称としては ASP.NET Universal Providers というそうです。
簡単に何をするものか説明すると、「ASP.NET におけるセッションステート、メンバシップ、ロール、プロファイル機能を、SQL Compact と SQL Azure にも対応させるツール」 という感じでしょうか。パクリですけど。
Node.js、Ruby、Python を Windows Azure で利用する Smarx Role ~ クラウドカバー Episode 48 より引用
ASP.NET におけるセッションステート、メンバシップ、ロール、プロファイル機能を、SQL Compact と SQL Azure にも対応させるツール “ASP.NET Universal Provider” がアルファ版としてリリースされました。
これにより、これまでのオンプレミスな Windows & SQL Server という組み合わせに加え、低トラフィックな Web サイトでは共有ホスティング & SQL Compact を利用、トラフィックが多い Web サイトでは Windows Azure & SQL Azure を利用する、といったことが可能になります。
ということで便利でナイスなプロバイダなわけですが、現時点でnugetから入手できるASP.NET Universal Providerは 0.1です。
でも、ASP.NET MVC 3 Webロールテンプレートに含まれる System.Web.Providers は1.0扱い?なんですよね。アセンブリも違うもののようです。(中身まで見たわけじゃないですがバイナリは異なる)
そのうちNugetにもあがる気はしますが、とりあえず正式版?がASP.NET MVC 3 Webロールテンプレートには含まれてるようです。
ちなみにアセンブリは<プロジェクトフォルダ>\packages\System.Web.Providers.1.0 のLibにあります。EULAやReadme.htmlもあるので使い方とか参考にどうぞ。
これはちゃんと使いこなしたいですね!
※EULAのどこどう見たらGoLiveなのか詳しい人に教えてもらいたいところ…ちゃんと読めという話ですが。
※EULAの補足。nugetで入手できる0.1はALPHA版ということで、商用利用が制限されています。ただ、ASP.NET MVC 3 Webロールに含まれてる1.0のほうはこの制限がないので、商用利用OK、Go-liveとみていいと思います。
いろいろ盛り込んでくれますね!Azure Team!
先日の投稿でも書きましたが、Windows Azure Tools for Visual studio v1.4 (August 2011 Update)でASP.NET MVC 3のWebロールテンプレートが追加されました。
で、このASP.NET MVC 3なWebロールを使うと今まで面倒だったアセンブリの追加とかが不要なわけですが、そのまま何も気にせずデプロイするとエラーになります。
よくみる(?)画面ですね。
さて、この原因ですが Deploying the Windows Azure ASP.NET MVC 3 Web Role にもある通り、ASP.NET MVC 3 Webロールプロジェクトテンプレートに含まれてるWeb.configにて、SQL Expressなカスタムセッションを利用するようになっているのが原因です。
解決方法はWade Wegner氏が書いてるとおりSQL Azure使うように正しく接続文字列変えてあげると良いのですが、面倒な場合はsessionState属性のmodeをOffとかInProcにすればいいんじゃないでしょうか。(投げやり)
※というのもちゃんとアプリケーション作るときはこの辺きちんと考慮するだろうし、デフォルトのままデプロイしたりするのは訓練されたあじゅらーぐらいな気もするので…
まぁ、そのうち修正されるかもしれませんがちょっとしたbad know-howということで…
たけはらさんにTumblrで教えていただきました。
どうもこのASP.NET MVC 3 Webロールテンプレートで使っているセッションやメンバシッププロバイダ等各種プロバイダはEntityFrameworkベースのSystem.Web.Providersだそうです。
未来を先取りテンプレート!!
ということは、Bad know-howで問題点として片付けるんじゃなくて、新しいテクノロジを活用しよう!っていう方向に持っていくべきですかね。
たけはらさんありがとうございます。
だいぶ前にWCF Data ServicesでForm認証をやりましたが、Cookieで認証してるんだからいずれCookieの期限が切れるわけです。
で、ASP.NETではCookieの自動更新を有効にするためのフラグ(slidingExpiration)があり、このフラグをtrueにしておくことで期限が半分過ぎた後にアクセスがあると、新しいCookieを発行してくれるようになります。
(レスポンスヘッダの”Set-Cookie”に新しいCookieが付与される)
<authentication mode="Forms"> <forms name="sample" timeout="1440" cookieless="UseCookies" slidingExpiration="true" /> </authentication>
さてブラウザ等はこの辺の処理を自動的にやってくれますが、アプリだと手動でやらないといけませんね。
ではEntityFrameworkではどうでしょう?
うーんそのまんまだとCookieどころかHTTPのレスポンスさえ見れませんね。
じゃぁどうしよう?と調べたところエンティティをQueryOperationResponseにキャストしてあげると良いみたいです。こんな感じ↓
ServiceReference1.Entities context = new ServiceReference1.Entities(new Uri("http://localhost/test.svc"));
context.MergeOption = MergeOption.NoTracking;
context.IgnoreMissingProperties = true;
var nodes = context.Users;
QueryOperationResponse<ServiceReference1.Users> response = nodes.Execute() as QueryOperationResponse<ServiceReference1.Users>;
if (response.Headers.Keys.Contains("Set-Cookie"))
{
//response.Headers["Set-Cookie"] に新しいCookieが入ってる
}
foreach (var user in response)
{
Console.WriteLine(user.DisplayName);
}
Cookieの有効期限が半分以上過ぎてからアクセスすると、レスポンスヘッダにちゃんとSet-Cookieが付与されているのがわかりますね。
あとはこの値をゴニョゴニョしておけばOKです。
※WCF Data Servicesで認証Cookie以外のCookieははかないと思いますが…一応注意ください。
これでForm認証するWCF Data Servicesとクライアントはばっちり?ですね!
WCF Data ServicesはHTTPベース(ODataやJSON等)を使用してデータの送受信ができる強力な仕組みです。このあたりの説明はとりあえず割愛。
で、便利が故にぽんぽん使ってるとそれなりに転送量や帯域も消費するわけでして。でHTTPベースであればgzipで圧縮して通信したいと思うのが世の常。
というわけでさくっとgzip圧縮する方法です。
自分用メモ。
基本からたたき直しが必要です。
いろいろありまして Entity Framework 4 など触り始めてみました。
今のところ、情報があまりあるという状況では無さそうな感じですので、手さぐりで何とか進めてる状況であります。
そんな中で調べて分かったことメモなど。。