之前我就像某人说的那样，I’m not quite a cloud guy，但是后来看了各式各样的演示，认识了 Cloud Project 的构成，以及 Mix 09 里面某人说 "It’s fun!” 以后，就冲着这句 It’s fun，我就扔了个 Hello World 上去，感觉还不错的，但是缺乏做点什么的动力，后来就丢在一边了。差不多的时间知道了 Google App Engine， 但不知GAE 猴年马月才能用 .Net 技术的，我不会python/java，而且现在貌似 GAE 没有跟 WorkerRole 相应的东西，但是好歹也用上了GAppProxy，也叫在 Google 的云上爽了一把。
这个情况下，在心爱的微软的云上却只有一个 Hello World 实在太说不过去了，于是打算找一段时间，将自己认识的有能力演示出来的东西都搞到云上去，反正现在 Azure 是免费的（希望以后的收费政策是 GAE 现在那种模式吧），不用白不用，浪费了自己漂亮的域名多可惜啊。好，就从刚 Release 不久的 Asp.Net MVC 开始。
如何开始
现在的 Visual Studio Tools for Azure(0903CTP) 是没有安装所谓的 MVC WebRole 模板的，也就是在 Roles –> Add –> New Web Role Project 不能搞出一个以 MVC 结构开始的模板，只有 Default.aspx、web.config：
显然不够，然后发现 Roles –> Add –> Web Role Project in solution.. 选项不能用，于是删掉默认的 Web Role Project，新建一个 MVC Web Application 到解决方案，发现该选项仍然是无效的：
这时候，我的做法是用 diff 工具比较 MVC 项目文件 (C# 项目就是 .csproj 了) 和 Web Role 的项目文件，发现 MVC 项目文件没有
如果像我在开始的时候顺便创建了测试项目的话，在上面这个过程可能会造成测试项目丢失对MVC项目的引用，编译时会提示，加上即可。现在，按 F5 调试，等一轮初始化过程，MVC 项目默认首页出来了。这就完成了吗？
AspProviders & StorageClient
是差不多了，但是在 Azure 上运行的应用程序可以有多个 Instances 的，每个 Instance 运行在不同的 Appdomain 里（瞎猜的，甚至可能在不同的虚拟机中，分布在不同的地理位置……），反正是隔离的，那么像登陆这类需要 Session 的操作会产生一些问题，具体什么问题很难说，我没试过，大概就是注册不了啊，登陆记不住之类的。这时候发挥 Google 的长处，会有惊喜的，我找到了 4 篇（1,2,3,4）相关的文章，原文都是英文，比较详细，另外还有几篇出自园友。除了关键的步骤，我就不重复他们的东西了。
说起来惭愧，我不是读计算机专业的，之前学过一点 Asp，没怎么学习过 Asp.Net，因此很多东西都是不久前才知道的，例如 Asp.Net 2.0 的 Provider Model。在这里 Provider Model 抽象出储存的实现，使得 Asp.Net 的各种状态可以自由选择储存在不同的媒介中，而且可以通过配置文件更改，不得不说这个设计实在非常好。上面给出的第四篇相关文章就叙述了怎么打造一个可以在 Cloud 运行的 Membership Provider。
在 Azure SDK 的安装目录中，有一个 Samples.zip，里面包含有微软提供的 AspProviders 例子，该例子提供了利用 Azure Storage 作为状态信息的储存媒介的样例，顺便也做了使用里面 StorageClient 样例的例子，哈哈，在这里能发掘不少东西的。因为 StorageClient 很多公共方法没有文档，给 Supress 了。
RTFM
AspProviders 文件夹里有一样很重要的东西，就是 providers-extended-readme.mht，我觉得这个文件一定要重视，如果你不打算写自己的 Providers 的话。里面有些代码用红色高亮了，可惜背景是灰色的，看完肯定报废一只眼睛，建议拿 Word 把那里的背景颜色改成黄色，看起来就舒服多了。
以下是我 RTFM 总结后的做法，希望对大家有用：
1.修改 Web.config，使那些 Providers 生效。大部分代码可以从 AspProvidersDemo 中复制。其中要修改的是 appName 属性，修改成应用的名称。Profile 的那个 inherits 属性删去，否则会出现运行时错误。
2.不使用readme 里面的标准 appSettings 设置 tableServiceBaseUri 等 addtional options，因为发布到云上就不能修改了，然而在本地调试的时候，用的是 local development storage。
3.修改 .csdef 和 .cscfg 文件，本地调试时按照 相关文章2 填写，发布上传之前，.cscfg 改成：
<ConfigurationSettings> <Setting name="DefaultProviderApplicationName" value="YourApplicationName"/> <Setting name="AccountName" value="YourStorageAccountName"/> <Setting name="AccountSharedKey" value="YourStorageAccountPrimaryKey"/> <Setting name="BlobStorageEndpoint" |
1.这里我加上了 DefaultProviderApplicationName 这条，否则用默认的：appName，有点恶心，这样做记得在 .csdef 文件上加上相应的定义。（多口一句：怎么像 C++ 的 h 文件那样啊，居然要自己声明元数据……）一些已知的问题
在我给出的相关文章里有了，简单归纳就是：
1.注意 Request.Url 的额外信息
2.安装这个 HotFix（同时修复了一个 WPF 设计器的问题）
3.不明白为什么要 Create Test Storage Tables 的话，请看这里
最后
可能因为Azure 还是 Preview 阶段吧，这些 Providers 的配置都要靠自己RTFM 然后人工完成，希望微软以后能提供 Azure MVC WebRole Project 模板，集成一套 Azure AspProviders，以及 StorageClient。然后呢，继续让某些人骂微软太体贴，哈哈！说实话，微软虽然让人感觉无时无刻都在 JIT，但这不是很好吗，这样才有激情，让微软有动力嘛……又跑题了……
【编辑推荐】
