在Azure云中部署支持MVC的ASP.NET程序

之前我就像某人说的那样 I m not quite a cloud guy 但是后来看了各式各样的演示 认识了 Cloud Project 的构成 以及 Mix 里面某人说 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( CTP) 是没有安装所谓的 MVC WebRole 模板的 也就是在 Roles –>Add –>New Web Role Project 不能搞出一个以 MVC 结构开始的模板 只有 Default aspx nfig

显然不够 然后发现 Roles –>Add –>Web Role Project in solution 选项不能用 于是删掉默认的 Web Role Project 新建一个 MVC Web Application 到解决方案 发现该选项仍然是无效的

这时候 我的做法是用 diff 工具比较 MVC 项目文件 (C# 项目就是 csproj 了) 和 Web Role 的项目文件 发现 MVC 项目文件没有 Web 以及一些指向 Azure SDK 中一些程序集的引用 用 diff 工具很快就能补上这些东西了 重新加载修改过的 MVC 项目文件 Roles –>Add –>Web Role Project in solution 就能选上了

如果像我在开始的时候顺便创建了测试项目的话 在上面这个过程可能会造成测试项目丢失对MVC项目的引用 编译时会提示 加上即可 现在 按 F 调试 等一轮初始化过程 MVC 项目默认首页出来了 这就完成了吗？

AspProviders &StorageClient

是差不多了 但是在 Azure 上运行的应用程序可以有多个 Instances 的 每个 Instance 运行在不同的 Appdomain 里（瞎猜的 甚至可能在不同的虚拟机中 分布在不同的地理位置……） 反正是隔离的 那么像登陆这类需要 Session 的操作会产生一些问题 具体什么问题很难说 我没试过 大概就是注册不了啊 登陆记不住之类的 这时候发挥 Google 的长处 会有惊喜的 我找到了 篇（ ）相关的文章 原文都是英文 比较详细 另外还有几篇出自园友 除了关键的步骤 我就不重复他们的东西了

说起来惭愧 我不是读计算机专业的 之前学过一点 Asp 没怎么学习过 Asp Net 因此很多东西都是不久前才知道的 例如 Asp Net 的 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 总结后的做法 希望对大家有用

修改 nfig 使那些 Providers 生效 大部分代码可以从 AspProvidersDemo 中复制 其中要修改的是 appName 属性 修改成应用的名称 Profile 的那个 inherits 属性删去 否则会出现运行时错误

不使用readme 里面的标准 appSettings 设置 tableServiceBaseUri 等 addtional options 因为发布到云上就不能修改了 然而在本地调试的时候 用的是 local development storage

修改 csdef 和 cscfg 文件 本地调试时按照 相关文章 填写 发布上传之前 cscfg 改成

<ConfigurationSettings><Setting name= DefaultProviderApplicationName value= YourApplicationName /><Setting name= AccountName value= YourStorageAccountName /><Setting name= AccountSharedKey value= YourStorageAccountPrimaryKey /><Setting name= BlobStorageEndpoint value= /><Setting name= QueueStorageEndpoint value= /><Setting name= TableStorageEndpoint value= /><Setting name= allowInsecureRemoteEndpoints value= false />ConfigurationSettings>

这里我加上了 DefaultProviderApplicationName 这条 否则用默认的 appName 有点恶心 这样做记得在 csdef 文件上加上相应的定义 （多口一句 怎么像 C++ 的 h 文件那样啊 居然要自己声明元数据……）一些已知的问题

在我给出的相关文章里有了 简单归纳就是

注意 Request Url 的额外信息

安装这个 HotFix（同时修复了一个 WPF 设计器的问题）

不明白为什么要 Create Test Storage Tables 的话 请看这里

最后

可能因为Azure 还是 Preview 阶段吧 这些 Providers 的配置都要靠自己RTFM 然后人工完成

lishixinzhi/Article/program/net/201311/13896

完全可以将asp的项目部署到Linux服务器上

需要在Linux服务器上搭建asp的环境

步骤比较多 就不在这里详细说明

可以参考：参考链接

希望可以帮助你  请采纳  谢谢

ASP.NET Core 是一个全新的开源、跨平台框架，可以用它来构建基于网络连接的现代云应用程序，比如：Web  应用，IoT（Internet Of Things，物联网）应用和移动后端等。ASP.NET Core可以运行在 .NET Core 或完整的  .NET Framework  之上，其架构为发布到云端或本地运行的应用提供了一个最佳的开发框架，由开销很小的模块化组件构成，这就保持了你构造解决方案的灵活性。你可以跨平台地在Windows、Mac和Linux等设备上开发和运行你的  ASP.NET Core 应用。

ASP.NET Core有以下优势：

ASP.NET Core相对于之前的版本有许多变化,才使得它成为一个更加灵活和模块化的框架。ASP.NET  Core不再是基于System.Web.dll，它基于一组分解在NuGet的包。这使您可以根据实际需要来判断是否引用相应的Nuget包，可以优化您的应用程序。表面积更小的应用程序的好处包括安全更强、维修更少，提高性能,降低成本。

最新版本的 ASP.NET 叫做 ASP.NET Core (也被称为 ASP.NET 5) 它颠覆了过去的 ASP.NET。

---