3.3 Windows Azure项目组成
前面我们展示了如何创建一个简单的Windows Azure项目，通过Visual Studio开发以及通过Developer Portal部署到Windows Azure平台。接下来有必要详细介绍Visual Studio中这个Windows Azure项目。
3.3.1 Windows Azure Project介绍
回到Visual Studio重新浏览刚刚部署到Windows Azure平台的这个Solution。它包含两个项目，一个是类似于ASP.NET MVC 2 Web Application的网站项目，另外一个是Windows Azure专有的Windows Azure项目。而这个Windows Azure项目又包含三个部分，分别是Roles、ServiceConfiguration.cscfg文件以及ServiceDefinition.csdef文件。
3.3.1.1 Windows Azure Roles的管理
Roles目录包含当前Windows Azure项目中所有Web Role和Worker Role。每一个Role都会对应Solution中的一个项目。这就意味着所有的Windows Azure Role必须以项目的形式加入到这个Solution里面。
目前Windows Azure平台仅支持.NET 3.5 SP1和.NET 4.0两个运行时。也就是说如果要将一个已经存在的应用程序迁移到Windows Azure平台，它的.NET版本至少是3.5 SP1。
目前Windows Azure平台中能够作为Windows Azure Role的项目类型如表3-1所示。
表3-1 Windows Azure支持的Project类型及其对应的Role类型
注意
Windows Azure平台不支持Website类型项目，因此必须将Website转化为Web Application才能以Web Role的形式加入Windows Azure项目。
在创建Windows Azure项目的时候，随着创建向导用户可以同时创建所需的一个或多个Role。正如前面创建ASP.NET MVC 2 Web Role一样，Windows Azure Tool for Visual Studio会同时创建对应的项目并且加入Windows Azure所需要的一些特殊设置和文件。同样的，开发人员也可以在已经创建好的Windows Azure项目里添加新的Role，或者将Solution中已存在的项目添加为一个Role。
如图3-30所示，当前的Windows Azure项目已经创建完毕，但是并不包含Role。而Solution中有一个已经创建好的ASP.NET MVC Web Application，这时便可以通过右键单击Roles节点，然后选择Add菜单下面的Web Role Project in solution命令来将某个项目加入到Windows Azure Role中。
图3-30 从已有项目中创建Windows Azure Role
参考
代码请参考ch002_shaunwabook002.zip。
在弹出的对话框中选择当前Solution里面能够成为Web Role的项目，然后单击OK按钮，如图3-31所示。
图3-31 选择添加到Windows Azure Role的Project
之后便可以看到Windows Azure项目的Roles目录下增加了一个新的Web Role。同样的，通过右键单击这个Roles节点，用户还可以将Solution里面其他符合要求的项目添加为Role，如图3-32所示。
图3-32 将一个Project添加为Windows Azure Role
不只如此，开发人员也可以在Windows Azure项目建成之后，再创建新的Web Role或者Worker Role。具体的做法这里就不再赘述了。
另外，选择Roles下面的节点，在右键菜单中可以通过Associate with命令将目前这个Role关联到另外一个项目上面，如图3-33所示。同时也可以通过Remove命令移除这个Role。
图3-33 将某个Role关联到别的Project上
提示
Remove操作只是删除了Windows Azure项目中的Role，而不会将其对应的实际项目一并删除。
3.3.1.2 Service模型以及csdef文件
Windows Azure平台部署的应用是基于一个个Hosted Service存在的，Windows Azure通过Service Model（服务模型）方式描述整个Hosted Service的配置，包括：
· Service里面所包含的Role及其类型（Web Role还是Worker Role）；
· Service中每一个Role所使用的VM Size；
· 终结点地址中包含对外以及对内两种终结点地址；
· 配置变量信息的声明中所有配置变量的名字都需要首先在Service Model里面声明；
· 本地存储；
· 服务器端证书；
· 需要导入的Windows Azure Plugin（插件）的信息。
当部署工作开始的时候，Windows Azure数据中心底层的Fabric Controller就会依照Service Model配置相应的运行环境，主要包括：
· 分配与VM Size相符合的虚拟机；
· 为虚拟机打开指定的内部终结点端口，同时在负载均衡服务器和路由器上配置外部终结点地址以及端口映射；
· 分配本地存储的空间。
由于上述工作大部分和虚拟机分配、负载均衡等硬件相关，所以如果用户希望修改Service Model的内容，则只有通过完整部署（即删除原有的部署然后重新上传部署包和配置文件）才能够实现，而不能通过就地升级功能实现。关于就地升级，请参考本书5.2.2节。
Service Model的信息保存在Windows Azure项目下的ServiceDefinition.csdef文件中，这是一个XML格式的文件，如图3-34所示。
图3-34 Service Model文件
开发人员可以直接修改，也可以通过Visual Studio提供的图形化界面进行修改。双击Roles下面某一个Role节点便可以看到Visual Studio打开了这个Role的配置界面，如图3-35所示。关于这个界面的具体用法，请参考本节“使用Role Setting界面管理CSDEF和CSCFG文件”部分的内容。
图3-35 Visual Studio中的Role Settings界面
3.3.1.3 CSCFG文件
和ServiceDefinition.csdef文件相邻的就是ServiceConfiguration.cscfg文件，顾名思义它就是Service模型的配置文件，主要包括当前Service里面每一个Role所使用的Instance数目、具体的配置变量值，以及服务器端证书等信息。
和ServiceDefinition.csdef文件不同，Windows Azure平台允许Hosted Service在运行状态下对ServiceConfiguration.cscfg进行修改。这主要是因为CSCFG文件的内容变化不会影响Service模型的修改，因此不需要重新分配Windows Azure虚拟机以及修改负载均衡和路由配置。也正是由于此特性，在使用Windows Azure平台的时候，我们通常会将那些需要经常修改的配置信息放到CSCFG这个文件里面，而不是原来经常使用的Application Configuration文件（即web.config或app.config文件）里面。
提示
当向Windows Azure平台部署应用程序的时候，web.config或app.config文件将会作为部署包的一部分，也就是说在部署结束后用户不能在应用程序运行的时候直接修改它的内容。如果想要修改Application Configuration文件，则必须进行全新部署或就地升级。
2011年8月版的Windows Azure Tools for Visual Studio还提供了对于多CSCFG文件的支持。也就是说，在一个Windows Azure项目中允许开发人员创建和管理多个CSCFG文件。默认情况下，在创建一个新的Windows Azure项目时，系统会自动生成两个CSCFG文件，分别是
· ServiceConfiguration.Cloud.cscfg
· ServiceConfiguration.Local.cscfg
这样，开发人员可以针对不同的部署环境选用不同的CSCFG文件配置。例如，在开发环境中使用本地的Storage Emulator和SQL Server，而对于系统上线的云环境则使用Storage Service和SQL Azure。通过Visual Studio中的Role Setting界面就可以管理这些CSCFG文件。
注意
本书基于Windows Azure Tools for Visual Studio 1.3版本，因此后续章节的内容及示例代码均只包含一个CSCFG文件，但是不影响程序的运行。读者如果使用Windows Azure Tools for Visual Studio 1.4 August 2011版本，则会出现两个CSCFG文件。关于更多CSCFG文件的详细介绍，请参考作者的博客文章http://blogs.shaunxu.me/archive/2011/08/04/new-version-avaliable---windows-azure-tools-for-vs2010.aspx。
3.3.1.4 使用Role Setting界面管理CSDEF和CSCFG文件
在Visual Studio中双击某个Role节点便会打开当前Role的属性窗口，开发人员可以通过这个属性窗口完成对CSDEF和CSCFG这两个文件的修改操作。属性窗口共分为如下六个标签页。
· Configuration：主配置。
· Settings：配置信息项目。
· Endpoints：配置终结点。
· Local Storage：配置本地存储。
· Certificates：配置服务器端的证书。
· Virtual Network：配置Windows Azure Connect功能。
同时，开发人员可以通过界面顶部的Service Configuration下拉框来选择当前编辑的CSCFG文件。比如用户选择了“All Configurations”项目则表示同时编辑所有的CSCFG文件以及CSDEF文件；如果用户选择了“Cloud”项目则表示编辑ServiceConfiguration.Cloud.cscfg这个文件。
1．Configuration标签页
如图3-36所示，Configuration标签页包含如下的内容。
图3-36 Role Setting中Configuration标签页
· .NET trust level：用来配置运行在Windows Azure平台应用程序所使用的信任级别。默认选择为Full trust，即完全信任模式；也可以选择部分信任的模式（Windows Azure partial trust）。一般情况下都会选择完全信任模式，即允许应用程序访问Native Code。而在部分信任模式下，Windows Azure Role只能够访问到很有限的系统资源。
· Instances：配置当前Role要使用的Instance个数，以及当前Role所使用的VM Size。关于不同的VM Size配置可以参考表2-1。
· Startup action：这个配置项只针对Web Role有效，用来设置当本地调试启动时打开的浏览器访问哪个协议的地址。默认情况下访问HTTP的地址，如果在Endpoint部分指定了HTTPS协议的话，这里也可以选择打开对应的HTTPS地址。
· Diagnostic：设置是否要启动Windows Azure的诊断服务以及诊断服务要用到的Storage服务的连接字符串信息。关于诊断服务请参考本书5.3节。关于Storage服务的连接字符串请参考4.1节。
2．Settings标签页
Settings标签页包含了自定义配置信息，其功能非常类似于Application Configuration文件中的appSettings部分。Settings标签页通过表格列出了当前Windows Azure项目中定义的所有配置信息及其内容。配置信息分为两种类型：字符串（String）和连接字符串（Connection String）。对于连接字符串，它有点类似于在连接数据库时使用的连接字符串，不同之处是这里的连接字符串是连接Windows Azure存储服务的。
连接字符串有两种格式。如果程序使用本地模拟器的存储服务，那么连接字符串将会使用如下统一的格式：
UseDevelopmentStorage=true
如果应用程序使用真正的云端Windows Azure存储服务，那么连接字符串的格式将会如下所示：
DefaultEndpointsProtocol=http;AccountName=wapass;AccountKey=zo5iVfPDa3LBqAb4LDqMfnu
UAuyuWpEBTiLgKTyALoD5xcdz9FLdmOyPy5M3IFVrQNaY0baH1bg0VLmnVj9HVw==
其中包含了用来连接存储服务的通信协议（使用HTTP或HTTPS）、访问服务的用户名以及验证码（Account Name和Account Key）。在Settings窗口的上方单击Add Setting按钮，然后在Name栏填入DataConnectionString，Type栏选择Connection String。这时可以看到，在Value栏的右侧出现了一个按钮，如图3-37所示。单击这个按钮。
图3-37 创建新的Connection String
在Connection String配置对话框中，如果要使用本地模拟器的Storage服务，只需要选择第一个单选框：Use the Windows Azure storage emulator即可。如果需要使用云端的Storage服务则需要选择Enter storage account credentials，并且从Developer Portal上面获得相应的Account Name和Account Key，然后选择想要使用的连接协议（HTTP或HTTPS），如图3-38所示。这样Visual Studio就会生成上面介绍的另一种连接字符串格式。
图3-38 配置适用云端Storage服务的连接字符串
3．Endpoints标签页
Endpoints标签页负责设定当前Role对内对外的终结点信息，简单来说就是开放的端口号。Windows Azure对于运行在其上的Web Role和Worker Role支持两种端口类型：Input和Internal。
· Input Endpoint指可以由外部访问的端口，客户端可以通过Hosted Service URL访问到Input端口。
· Internal Endpoint通过Hosted Service URL是无法访问的，但是当前Hosted Service的其他Role可以通过Internal Endpoint访问。
如图3-39所示，在Windows Azure平台上，每一台分配的虚拟机（每一个Role Instance）都会开放内部端口（默认使用20000端口）。而通过Windows Azure负载均衡将客户端对于Input端口（以80端口为例）映射到Instance内部端口（20000端口）上面。关于Endpoint的更详细介绍，请参见本书8.1节。
图3-39 Windows Azure平台的端口映射
在Visual Studio的Settings页面中，开发人员通过Add Endpoint按钮就可以添加一个新的Endpoint。对于Input类型的Endpoint需要指定Public Port，即通过Hosted Service URL可以访问的端口号。一般第一个Input Endpoint会默认使用80端口，此后的依次为8080、8081等。而对于Internal的Endpoint，由于其对外不可见所以只能设置Private Port。而如果不设置，Windows Azure平台会在创建虚拟机的时候随机指定一个端口。如果当前Endpoint使用HTTPS协议，则还需要选择所使用的证书，即通过Certificates标签页上传的证书，如图3-40所示。
图3-40 设置Endpoint信息
4．Local Storage标签页
Windows Azure平台的计算服务允许应用程序使用一部分虚拟机的本地磁盘作为本地的存储资源。这个本地存储资源位于Windows Azure虚拟机C盘的一个特殊目录之下，其使用总量基于在Configuration标签页中所选择的VM Size的值。如果开发人员需要在程序中使用本地存储，那么需要在Local Storage标签页中进行配置。
Local Storage配置项包含名称、大小以及Role重启时是否清空内容这三个选项，如图3-41所示。一旦用户配置了本地存储，就可以在程序中通过名字访问到这个存储空间所对应的文件目录，进行文件操作。
图3-41 配置本地存储
注意
本地存储不同于Windows Azure的存储服务，在虚拟机迁移、服务器故障以及全新部署的时候，本地存储有可能会被清除，所以本地存储只适合文件的临时保存。另外，使用本地存储会对Hosted Service横向扩展的实现有影响。
5．Certificates标签页
Certificates标签页用来添加和删除Windows Azure虚拟机中的证书，并且Windows Azure会在分配了虚拟机之后执行证书安装操作。配置一个Certificates需要设定其名字、存储位置（Local Machine或Current User）、存储名（My、Root、CA等）以及Thumbprint。对于Thumbprint部分，可以单击后面的按钮直接选择一个已经安装到本地计算的证书即可，如图3-42所示。
图3-42 添加一个新的证书
6．Virtual Network标签页
Virtual Network标签页主要是用来配置Windows Azure Connect功能的。关于Windows Azure Connect请参考本书8.3节。
当用户通过Settings页面修改并且保存配置后，对应的ServiceDefinition.csdef文件和ServiceConfiguration.cscfg文件都会进行相应的修改。一般来说，开发人员只需要通过Role Setting界面就可以完成对上述两个文件的修改工作，即完成对部署到Windows Azure的Hosted Service的所有配置工作。
3.3.2 Role及其生命周期模型
接下来通过浏览此前创建的Windows Azure项目以及ASP.NET MVC 2 Web Role来介绍Role的结构和生命周期模型。整个项目如图3-43所示。
图3-43 Web Role项目
ASP.NET MVC 2 Web Role项目和传统的MVC项目类似，包含了MVC的三元素，即Models、Views和Controllers。同时还包含一些ASP.NET的必要文件如Global.asax等。但是可以看到，与标准的MVC项目不同，这里的项目多了一个名为WebRole.cs的文件。其中定义了一个名为WebRole的类，它派生自RoleEntryPoint这个在Windows Azure SDK中定义的基类。
RoleEntryPoint这个类定义在Microsoft.WindowsAzure.ServiceRuntime命名空间中，位于Assembly Microsoft.WindowsAzure.ServiceRuntime.dll这个文件里面。它随着Windows Azure SDK安装到开发计算机中。
Microsoft.WindowsAzure.ServiceRuntime这个命名空间主要提供了对Windows Azure平台运行时的支持，开发人员可以通过它提供的一系列类来获取或设置Windows Azure平台以及运行在其上的Role、Instance等相关属性。其中RoleEntryPoint这个类主要负责Role的生命周期管理。
当一个Role被部署到Windows Azure平台的时候，Windows Azure底层的Fabric Controller会首先基于CSDEF文件分配指定类型的虚拟机，然后将部署包解压缩到指定的目录。如果是Web Role的话，Fabric Controller将会配置IIS中的网站；如果是Worker Role的话，Fabric Controller会启动特殊的寄宿进程来运行Worker Role代码。最后，Fabric Controller搜索Role里面派生自RoleEntryPoint的类，通过调用下面几个方法对Role进行启动和停止操作。
· OnStart方法：Role启动的时候被调用。OnStart方法中加入的代码可以处理一些在Role启动时的初始化工作。当返回True的时候表明启动成功，否则表示启动失败。如果在调用过程中出现未捕获的异常则会引发Role的重新启动。
· Run方法：包含Role所执行的业务逻辑操作。Run方法在实现的时候必须是一个无限循环的逻辑，以保证部署之后Role始终处于运行状态。和OnStart一样，任何在Run方法中出现的未捕获异常都会引发Role的重新启动。
· OnStop方法：包含Role停止时的逻辑。OnStop中的代码可供处理一些在Role停止的时候需要执行的收尾或回收工作，例如关闭数据库连接、关闭文件等。需要注意的是，Fabric Controller会判断Role关闭的时间是否超时（30秒）。因此在OnStop里面加入的业务逻辑需要在这个超时范围之内完成，否则将会被视做异常。同样的，任何在OnStop方法中抛出的未捕获异常也会引发Role的重新启动。
在Windows Azure平台，当进行上述操作的时候，Fabric Controller会更改Role的状态值，同时触发StatusCheck的事件。
这个状态值和这个事件被定义在Microsoft.WindowsAzure.ServiceRuntime命名空间中的RoleEnvironment类里面。开发人员可以在代码中绑定这个事件来实现判断当前Role所处的状态。当Fabric Controller调用OnStart或OnStop方法的时候会修改此状态为Busy，调用并进入Run方法的时候会修改此状态为Ready，如图3-44所示。
图3-44 Role的生命周期模型及其对应的状态值
在Visual Studio中打开WebRole.cs文件便可以看到Windows Azure模板创建的默认内容。可以在OnStart、Run和OnStop方法中加入一些调试信息来检验上述方法何时被调用，以及对应的状态值。修改后的WebRole.cs文件如下所示。
using System;
using System.Collections.Generic;
using System.Linq;
using Microsoft.WindowsAzure;
using Microsoft.WindowsAzure.Diagnostics;
using Microsoft.WindowsAzure.ServiceRuntime;
using System.Diagnostics;
namespace MvcWebRole1
{
public class WebRole : RoleEntryPoint
{
public override bool OnStart()
{
// For information on handling configuration changes
// see the MSDN topic at http://go.microsoft.com/fwlink/?LinkId=166357.
Trace.WriteLine(string.Format("Role Instance {0} entered OnStart method.",
RoleEnvironment.CurrentRoleInstance.Id));
return base.OnStart();
}
public override void Run()
{
Trace.WriteLine(string.Format("Role Instance {0} entered Run method.",
RoleEnvironment.CurrentRoleInstance.Id));
base.Run();
}
public override void OnStop()
{
Trace.WriteLine(string.Format("Role Instance {0} entered OnStop method.",
RoleEnvironment.CurrentRoleInstance.Id));
base.OnStop();
}
}
}
参考
完成的代码ch003_shaunwabook003.zip。
在本地模拟器中运行此代码，可以看到在部署好项目之后Windows Azure模拟器自动打开浏览器展示这个网站。此时右键单击Windows状态栏中Windows Azure本地模拟器的图标，如图3-45所示，选择Show Compute Emulator UI命令打开计算服务的管理界面。
图3-45 显示本地计算服务模拟器的管理界面
关于这个管理界面的详细介绍请参见本书3.3.4节，这里主要通过它的输出界面来确认刚才在WebRole.cs文件里面的调试代码是否正确执行，并且确认Windows Azure平台对Role中代码的调用顺序。在左侧树形窗口中依次打开Shaun.WABook003下面的MvcWebRole1节点，选中下面的名字为“0”的节点，通过右侧的控制台窗口可以看到本地模拟器的调试信息。如图3-46所示，在OnStart和Run方法里面加入的调试信息都被打印到这里。
图3-46 在本地模拟器中测试Role的生命周期
对于Worker Role而言，Windows Azure项目模也会自动生成一个名为WorkerRole.cs的文件，它定义了一个名为WorkerRole的类，同样派生自RoleEntryPoint。而WorkerRole的内容和WebRole稍有不同，但是原理、调用次序和生命周期模型都是一样的。
这里需要提示的是，对于一个Worker Role而言这个WorkerRole类是必不可少的。Fabric Controller需要这个类来确定如何调用并运行当前的Worker Role。但是对于Web Role而言，WebRole这个类是可选的。也就是说Windows Azure Web Role是可以在没有派生自RoleEntryPoint的WebRole类的情况下在Windows Azure平台运行。在这种情况下，Fabric Controller会直接启动ASP.NET的管道模型，从Global.asax文件的Application_Start方法启动网站。但是如果应用程序需要Web Role在启动网站之间完成一些操作，则必须创建这个WebRole类。图3-47展示了基于ASP.NET的Web Role启动顺序。
图3-47 ASP.NET和Role的生命周期及其相互关系
3.3.3 Configuration的变更和通知机制
Windows Azure项目中包含两个重要的配置文件：一个是Service Model定义文件Service Definition.csdef；另外一个是配置文件ServiceConfiguration.cscfg。CSDEF文件一经部署就无法修改，除非重新部署整个Hosted Service；而CSCFG文件可以在Role运行状态下修改，类似于web.config文件的修改机制。
Microsoft.WindowsAzure.ServiceRuntime命名空间下面的RoleEnvironment类不但能够获取到Windows Azure平台的信息，还允许应用程序绑定CSCFG文件的变更事件。RoleEnvironment通过Changing和Changed两个事件通知调用方CSCFG文件发生了变化。需要注意的是，这两个事件都是在CSCFG文件发生修改之后才会触发的。
· Changing事件：在配置信息被应用到这个Role Instance之前发生。开发人员可以通过事件参数RoleEnvironmentChangingEventArgs中的Cancel属性确定是否需要重启这个Role。如果Cancel = True，那么Fabric Controller将会从OnStart方法开始重新启动整个Role，否则将不会重启Role，但是修改后的新内容也可以被获取到。
· Changed事件：在配置信息被应用到这个Role Instance之后触发。
例如修改WebRole.cs里面的内容，加入对CSCFG文件变更的事件函数，如下所示：
using System;
using System.Collections.Generic;
using System.Linq;
using Microsoft.WindowsAzure;
using Microsoft.WindowsAzure.Diagnostics;
using Microsoft.WindowsAzure.ServiceRuntime;
using System.Diagnostics;
namespace MvcWebRole1
{
public class WebRole : RoleEntryPoint
{
public override bool OnStart()
{
// For information on handling configuration changes
// see the MSDN topic at http://go.microsoft.com/fwlink/?LinkId= 166357.
RoleEnvironment.Changing += (sender, e) =>
{
Trace.WriteLine("[INF] RoleEnvironment.Changing.");
e.Cancel = false;
};
Trace.WriteLine("[INF] WebRole.OnStart.");
return base.OnStart();
}
public override void OnStop()
{
...
}
}
}
在RoleEnvironment的Changing事件上加入了一段代码，当CSCFG发生变化的时候输出一行提示信息，并且将e.Cancel设置为False，不需要重启Role。为了演示起见，在这个Role的Settings里面加入一个配置项，如图3-48所示，也就是在CSCFG文件中加入了相应的内容。
图3-48 加入Setting信息来演示CSCFG的变更机制
同时，修改HomeController里面的Index方法让网站的首页显示Settings里面设置的内容，代码如下所示：
namespace MvcWebRole1.Controllers
{
[HandleError]
public class HomeController : Controller
{
public ActionResult Index()
{
ViewData["Message"] = RoleEnvironment.GetConfigurationSettingValue
("Message");
return View();
}
}
现在在本地模拟器运行这个Windows Azure项目，可以看到在首页显示了CSCFG文件里面设定的内容。接下来定位到当前Windows Azure项目所在路径的bin/Debug目录内，可以看到这里面也有一个CSCFG文件，这是本地模拟器在部署的时候生成的CSCFG文件，也就是应用程序实际运行时使用的CSCFG文件。用文本编辑器打开并且修改这个Setting的值，如图3-49所示。
图3-49 用文本编辑器修改CSCFG文件的内容
由于本地模拟器没有自动感应CSCFG文件变更的功能，因此需要手动调用模拟器的更新操作告知现在CSCFG文件已经产生了变化。打开本地模拟器的Compute Emulator界面，在左侧的树形窗口中找到当前部署的序列号，如图3-50所示。
图3-50 本地模拟器的部署序列号
然后在开始菜单中执行Windows Azure SDK v1.4中的Windows Azure SDK Command Prompt。在打开的命令行界面里面切换到刚才修改的CSCFG文件所在的目录地址（即Windows Azure项目路径下面的bin/Debug目录），执行如下的命令：
csrun /update:116;ServiceConfiguration.cscfg
命令行中的116参数就是当前本地模拟中部署的Windows Azure项目序号。之后可以看到在Compute Emulator UI的控制台界面中输出了对应的调试信息，如图3-51所示。
图3-51 本地模拟器侦测到CSCFG文件的变化
这时候刷新网站，可以看到新的Setting值已经被读取出来了，如图3-52所示。
图3-52 读取到新CSCFG文件内容的网站
而如果部署到Windows Azure环境，CSCFG的变更会自动触发相应的事件而无须人工干预。登录到Developer Portal后选择一个已经部署好的Deployment节点，在工具栏中单击Configure按钮便会弹出一个修改CSCFG文件的对话框。
通过这个对话框，用户可以从本地上传一个新的CSCFG文件，或者直接在线编辑部署好的CSCFG文件。如图3-53所示，直接修改了CSCFG文件中的Setting值并且保存之后，在Developer Portal主界面中可以看到对应的Deployment、Role和Instance状态变为Updating。
图3-53 通过Developer Portal在线修改CSCFG文件
上面的章节介绍了Windows Azure项目的主要组成部分和相关的内容。而在介绍中我们多次使用了Windows Azure本地模拟器的Compute Emulator界面，下面的部分将会着重介绍这个本地模拟器的各种功能。
3.3.4 Windows Azure本地模拟器
本地模拟器随同Windows Azure SDK一并安装到计算机上，它的主要目的是尽可能完整地在本地模拟出Windows Azure平台的计算服务及存储服务。对于计算服务，本地模拟器主要模拟了Windows Azure项目的部署、启动、环境变量变更、负载均衡以及诊断服务等。
如果开发计算机安装了Windows Azure Tool for Visual Studio，在Visual Studio里面启动或调试Windows Azure项目则会自动启动本地模拟器的计算服务和存储服务。除此之外，用户还可以通过Windows Azure SDK Command Prompt窗口用命令行的方式启动本地模拟器。
本地模拟器启动之后，在Windows状态栏中会看到一个蓝色的Windows Azure图标，通过单击右键可以打开相应的功能，包括Compute Emulator UI（计算服务模拟器管理界面）、Storage Emulator UI（存储服务模拟器管理界面）、关闭计算或存储服务模拟器以及关闭整个模拟器。
3.3.4.1 Compute Emulator UI介绍
Compute Emulator UI，也就是计算服务模拟器管理界面。通过这个界面用户可以看到目前已经在本地模拟器上面部署的所有Windows Azure应用。
管理界面主要包含两部分，左侧以树形结构列出了目前部署的Windows Azure应用。如图3-54所示，当前模拟环境中有一个序号为118的Windows Azure项目部署。这个部署包含了一个名为Shaun.WABook002的Hosted Service，里面运行了两个Role，分别是WebApplication1和WorkerRole1。而Role节点之下的0、1、2节点表示每个Role所分配的Instance。
图3-54 Compute Emulator UI
右侧有一个类似控制台窗口的界面，每一个Role Instance都会对应一个控制台窗口。通过选择左侧的Instance节点可以看到控制台的具体内容。
通过Service Details节点用户可以方便地看到目前部署的Service详细信息，包括所开放的对外端口号，如图3-55所示。由于本地模拟器使用IIS模拟Web Role，所以默认的Web Role使用81端口，如果还有别的Web Role则会使用82、83等端口，以此类推。同理，如果指定了HTTPS连接，那么默认的端口号为444。
图3-55 Compute Emulator的Service Details信息
并且，用户可以通过界面上方的工具栏启动、停止、重启部署的Role Instance，也可以将部署的Windows Azure应用从模拟器中删除。
提示
如果通过Visual Studio启动Compute Emulator，当停止了Visual Studio的调试模式后，本地模拟器就自动将此应用从模拟器中删除。
3.3.4.2 Storage Emulator UI介绍
与计算服务模拟器相比，存储服务的管理界面相对简单。通过状态栏的模拟器图标右键菜单，选择Show Storage Emulator UI命令就可以打开存储模拟器的管理界面。用户通过此界面可以打开或关闭对应的存储服务，看到三个存储服务所对应的本地访问地址，如图3-56所示。
图3-56 本地存储服务模拟器的管理界面
本地模拟器模拟了Windows Azure平台提供的存储服务，供应用程序在本地运行时使用。在接下来的章节里，我们将详细介绍Windows Azure平台提供的三种不同的存储服务，包括它们的特点、使用方法、使用场景和注意事项。