ちょっと触ったので個人的メモです。
今日ちょっとなやんでしばやん先生に即答してもらったのでメモ。
まずリソースファイルをPublicにしておきます。要確認。
リソースファイルのプロパティでカスタムツールを PublicResXFileCodeGenerator にしてビルドアクションで”埋め込まれたリソース”にしておきます。
あとはデータアノテーションのところでリソース指定するだけ。
例:ASP.NET MVCで既定で生成されるAccountModelなど
[Display(ResourceType = typeof(YOURNAMESPACE.App_GlobalResources.StringResources), Name = "ResUserName")]
public string UserName { get; set; }
超簡単ですね。
ASP.NET MVC3での多言語対応はこちらも参照。
ただこれやって発行したりするとリソースDLLはできてるんだけど読み込めないみたいなんですよね。なんでだろ。。まだ調べてる途中なのでわかったら追記等します。
2011.02.23 追記
いろいろ見てると以下の事がわかりました。
ということでGetGlobalResourceObjectが問題。Webアプリケーションの発行先にApp_GlobalResourcesフォルダ(と.resxファイル)があれば問題なく動作しますが、埋め込みリソースとしてビルドするとアセンブリに埋め込まれて(あとサテライトアセンブリが出来て)発行先にはApp_GlobalResourcesフォルダは含まれません。
で、この状態でGetGlobalResourceObject呼び出すとNGと。嵌ってた状況はこんな感じです。
じゃぁどうやってアクセスするんだ?というと単純にリソースは既にPublic化されているわけですから
@MvcApplication1.App_GlobalResources.StringResources.String1
みたいにしてあげればいいわけですね。やぁ長かったよ。
参考にしたサイトはこちら。
ゼロから始めるといろいろ壁にあたりますね~。
今日はWindows Azure Connectなんぞをネタにしようと思います。
さてWindows Azure Connectとは?というところなんですが、よく考えるとあまり取り上げてなかった気がしますね。
ぶっちゃけていうと、クライアントコンピューターとWindows AzureのホストサービスをVPN(IPSec)で結んであたかも直接通信ができるようにトンネリング接続してくれる機能のことを指します。
IPSec接続にはクライアントからOutbound TCP/443ポート(HTTPS)だけ開いていればいいので、ネットワーク要件としてはファイアウォールの設定変更も大半のケースでは不要ですし、使い勝手は良さそうです。が。
Windows Azure SDK 1.3 の機能であるFull IISを利用してWeb Roleを展開すると、Web.configに明示的に指定してたMachineKeyが Windows Azure上に配置後上書きされる問題があります。(※Hosted Web Coreを利用する場合は問題ないようです)
この問題に対する回避策はSteve Marxが回答していますが、MSDNのIssueにあるようにRoleEnvironmentのOnStart等で明示的に書き換えてあげる必要があるようです。
前回のPOSTで書き忘れたこと。
インターセプターを使えば特定の列だけ値を変える等できます。OData and Authentication – Part 7 – Forms Authentication にも記載されていますが、たとえば認証されているときだけセンシティブな情報を返すとか。
認証ユーザーやロールに応じて1つのWCF Data Services で柔軟に操作範囲を変えたりできるのはすごく便利ですね。
あと忘れてましたがASP.NET開発環境だとうまくフォーム認証が動きませんでした。(.adxが見れない?)このあたりあまり情報なくてちょっと諦め気味…
面倒だけどデバッグはIISのワーカープロセスにアタッチする等したほうがいいのかも…?
またSQL Serverへの接続は手抜きですが、アプリケーションプールのユーザー等にアクセス権限無いと無駄に怒られますので注意。
最後に追加でいろいろリンクを置いておきます。
ちと調べてて悩んでたので一応吐き出しておきます。
WCF Data Services を使うとOData形式等で強力なデータ連携が可能になります。
特に Entity Framework や LINQとの相性は抜群です。
でもむやみやたりにデータ公開したくないわけで。特にクラウドに置いたりする場合は。
じゃやっぱり認証かけたいよね、ということで今回は以下のケースで考えてみます。
イントラネット等でWindows統合認証が使えるならこんな苦労はないのかも知れませんが、プログラム内から操作する方法だと取れる手法は限られてきます。
で、今回はお手軽にフォーム認証を使って Cookie ベースで制限をかけたいと思います。(まぁなんというか、やってることは OData and Authentication – Part 7 – Forms Authentication と変わりません。)
※ Cookie ベースならまぁローカルに保存してても許してくれそうですし。
なんか需要があるとかないとか…
Windows Azure ホステッドサービスでSSL(HTTPS)したい場合のTipsです。
※Windows Azure SDK 1.3前提です。
今日はちょっとした実験の元ネタです。
Windows Azureのホステッドサービスは通常「xxx.cloudapp.net」なホスト名で提供されますが、ドメイン名は独自のでサービス提供したい!とか要望あるかと思います。