Visual Studio 2013售价曝光

微软计划于11月13日正式发售Visual Studio 2013,其售价方面也与Visual Studio 2012相似.而如果你是一位MSDN或TechNet订阅用户的话可以在10月18日,即Windows 8.1发布的当天提前下载Visual Studio 2013 RTM版本.

Visual Studio 2013

Visual Studio 2013售价分别为:专业版499美元,专业版+MSDN订阅799美元,高级版+MSDN订阅2569美元,终极版+MSDN订阅4249美元.微软还将特别为Visual Studio 2012专业版发布更新包,用户可以从11月1日至明年1月31号以99美元的活动价升级至Visual Studio 2013.该升级包原价为299美元.

.NET 4.5.1比看上去更丰富

  本周的 Build 大会上宣布了 .NET 4.5.1 的推出。看上去这次更新好像只是一次 bug fix,或者顶多包括一些很小的更新。不过 Habib Heydarian 在演讲中消除了这种错误的观念。Heydarian 的这个演讲题为“.NET 开发中的新内容”,涵盖了 .NET Framework 中一些重要的新特性。

  Heydarian 的演讲主要围绕着三个方面展开:开发者生产力、应用程序的性能及持续创新。首先是开发者生产力,Heydarian 宣布了某个很常用 .NET 特性的后续进展,那就是“修改并继续执行”。他在提到了 32 位机器上的该功能在 2005 年就已发布,随后高兴地宣布 64 位机器上的相同功能将成为 .NET 4.5.1 的一部分。这一功能和 32 位版本是完全相同的。

  随后,Heydarian 宣布了检测方法返回值的新功能,它可以在 Visual Studio 的 Autos 窗口或 Immediate 窗口中使用。可以在调试器中展开返回值以便查看当前的值。对于 Windows Store、Web App 和 Windows 8.1 桌面 App 而言,由于对 Call Stack(调用栈)和 Tasks 窗口的使用性进行了改进,使得调试异步代码更加容易了。

  这还不是 Windows Store App 的唯一改进,另一项改进是开发者可以将 System.IO.Stream 转换为 IRandomAccessStream 了。另外,通过引入可空值类型,WinRT 的类型系统也得到了增强,并且对异常提供了更好的支持(例如:System.Exception.Message,System.Exception.StackTrace)。这些 System.Exception 的新属性是在基于 Windows 8 的经验上进行的改进,在这之前只有在附加的进程上的调试器中才能避免丢失这些信息。

  EF 和 ADO.NET 现在对连接失败的情况容错性更好了。在之前,断开网络连接会导致一个异常的产生,而在 4.5.1 中则能够优雅地应对这种失败情况,一旦网络连接得以恢复,应用程序就会监测到它,并继续之前的工作。

  ASP.NET 应用现在可以自动挂起了。实际运行的 ASP.NET 工作进程(worker process)将被挂起为可随时唤醒的状态,这能够节省 90% 的启动时间。当应用程序处于空闲状态一段时间后,它将会被分页到磁盘,一旦某个请求到来或是完成,它将被唤醒。可以在 IIS 配置中将 Time-out Action 这一项设置为“挂起”以实现这一功能。

  在 .NET 4.5.1 的底层,你现在可以压缩大对象堆(LOH)以应对堆碎片问题。LOH 模式是 GCSettings 的一部分,但 Heydarian 提醒大家:“能力越大,责任越大”,在一般的开发过程中绝不要使用这项功能。

  多核的即时编译(JIT)性能也有所改进,按 Heydarian 的说法,在冷启动的状态下能达到 15% 的性能提升。

  另一项在 .NET 4.5.1 中得到改进的部分是有关 framework 升级后系统的表现。目前,运行更新后的 .NET Framework 会使应用程序性能在短时间有一定程度的下降。这是因为核心的 .NET 程序集在更新或补丁需要一段时间进行 JIT 编译。在 Windows 8.1 中,即使运行(更新后的).NET Framework,应用的性能也能保持稳定。这使用户体验大为提高,也符合微软的努力方向,即尽可能提升平板电脑的续航能力。

  Heydarian 宣称他的团队的一个目标是尽可能做完所有的脏活累活,而让 .NET 开发者能直接从中受益。另外,他希望只要可���,.NET 平台的所有改进都能使开发者直接受益,而把重新编译的时间(如果需要的话)减至最小,为了达到更好的性能。

  最后要说的是,微软创建了一个新的 NuGet feed,为官方的微软 .NET 包(package)提供稳定而实时的更新,可以应用于 Visual Studio 2010、2012 及 2013。这个 feed 在 VS2013 中直接支持,而 VS2010 和 2012 的用户可以手动添加这个 URL 以获取 feed:https://nuget.org/api/v2/curated-feeds/dotnetframework/

  关于 .NET 4.5.1 预览版的更多细节,请参考 .NET 团队的正式声明

.NET 4.5提升了Web开发的生产率

  随着.NET 4.5 发布日期的日益临近,微软已经开始慢慢揭开下一代开发平台的神秘面纱。关于 Metro 和 Windows 8 已经有了很多宣传,而对 .NET 核心特性所作出的改进会在短期内抢了它的风头,传统上那会专注于 web、服务和数据开发。

ASP.NET Web Forms 在 .NET Framework 的前几次发布中保持相对稳定,很多开发者市场份额分享给了 ASP.NET MVC。在 .NET 4.5 中,微软做了大量工作,在 ASP.NET Web Forms 中提供了对模型绑定的支持,从而减少这两种 web 开发产品之间的生产力差别。这种绑定让开发者可以在代码中跳过服务调用和绑定,直接给控件赋值。

  尽管这种方法确实节省了时间,但是它并没有把页面的渲染和业务逻辑完全分离开: 载入网格的服务方法名称会嵌入在控件中。

  除了 ASP.NET 栈中的模型绑定和其他改善——像提升了的对 HTML 5 的支持、降低了的内存消耗、易于编写异步代码的能力——之外,ASP.NET 相关技术还在 Visual Studio 编辑器中享受更丰富的开发体验。在更引人注目的改善之中,其中之一就是智能任务(Smart Tasks)。在标签中使用 Ctrl + .(点), 开发者可以使用智能任务来加快开发的速度,而不需要知道关于如何配置给定控件的细节。

  其他 Visual Studio 的改进包括: 对于 JavaScript 和 CSS 更智能的支持,还有更精细的调试机制,像页面检查工具(Page Inspector tool)。

  由于引入了 ASP.NET MVC,它已经能够以某种形式来提供 RESTful 的 web 服务,而在 ASP.NET MVC 的最新版本中,微软引入了一些 Web API,让这个概念标准化。Web API 的关键特性就是,通过支持 RESTful 的方法来暴露 IQueryable,从而减少开发时间。这种特性能够帮助开发者创建专门的客户端查询,而不需要创建通常需要用来产生有用服务的大量代码。和其他 .NET 4.5 的改善一样,这项特性所修改的代码范围被降到了最小。

  对于以下标准的 API 控制器:

  基于 GetProducts ()的 REST 查询,它会返回所有产品:

http://localhost:8334/api/product

  对于以下可查询 API:

  基于 GetProductsByQuery ()的 REST 查询,它会返回所有成本小于 4 的产品:

http://localhost:8334/api/product?$filter=(cost lt 4)

  过滤器会在运行时应用给第二个查询,从而形成结果。这让一个方法可以为多个特性服务,而且减少了方法的关注点。对于特定的特性,任何特殊的情况或者副作用都可能需要它自己的实现。

  最后,为了管理你需要通过 Web API 暴露的数据,微软提供了 Entity Framework 5。尽管 Entity Framework 的各种模型已经存在一段时间了(像代码先行、数据库先行和实体先行),Entity Framework 5 引入了一种概念,能够在开发工作的周期内,自动同步模型和数据库。这会节省很多花费在创建 SQL 变更脚本和管理已经持久化的数据的工作。尽管在包管理控制台(Package Manager Console)中协调迁移的环节很可靠,但是还是值得学习一下相关的语法。

  在代码先行(Code First)的应用程序中,运行这条命令:

  如果“InitialCreate”文件没有添加到你的迁移目录中,那么就运行这条命令:

  对于给定的模型:

  如果我们增加属性“HasLid”:

  我们可以运行另一条命令,使用我们对模型的改变来更新数据库。

  如果你想要回滚所做的变更,只需要运行 add-migration 命令,并确定你想要让数据库反映的目标:

  尽管这些变更已经被大家广为接受,认为它能够改善 .NET 开发者的生产力,但是4.5版本中引入的大量变更还是存在一些问题。Greg Duncan 简要地说明了微软在 .NET Framework 中的速度问题: “我猜你可能会说微软(或者参与的团队)是敏捷的,并试图在每次迭代中做出改善,从过去的经验学习……? (咳咳……所以我希望至少……咳咳)。”

用于.NET的可移植HTTP客户端

  直到最近,关于在 .NET、Silverlight、Windows Phone 和 Windows Store 之间分享代码的问题之一,依旧是缺少发起 HTTP 请求的能力。每个框架支持一个或多个 HTTP 客户端,但在 API 层面它们互不兼容。

  要解决该问题,开发者可以创建自己的平台相关适配器,并使用依赖注入把它们添加到有需要的可移植库中。而基本上,这也正是新的可移植 HttpClient 所做的事情。

  当然,每个版本的 HttpClientHandler 都有不同的功能集。所以,为了尽可能地将更多的功能暴露出来,可移植 HTTP 客户端引入了诸如 SupportsUseProxy 和 SupportsAllowAutoRedirect 这样的扩展方法。

Immo Landwerth 解释道:

倘若开发者想要知道为何我们添加扩展方法而不是常规属性的话:某些 Microsoft.Net.Http 支持的平台已经提供并正在使用 HttpClientHandler 类。由于不能直接修改属性的内建版本,我们添加了扩展方法并通过 NuGet 包以独立程序集的方式发布。

  基于以下原因,微软正在变得越来越青睐类似于可移植 HttpClient 这样的小型、带外发布:

首先,它搭建了一座桥梁以跨越我们已经发布的平台之间的差异。HttpClient 是一个很好的例子,同样的还有对 async 和 await 关键字的支持。带外发布特性允许我们通过单一可移植类库针对多平台发布新功能,而无需等待其中任何一个平台添加该功能。

其次,我们的目标是增强与客户之间的反馈回路。过去,我们发布“大型”beta 版本,例如整个 .NET 框架的 beta 版本。这一方法当然有其优势,但我们也发现了它的问题。其中最大的缺点是“大型”beta 版发布代价高昂,而且它一般与 RTM 非常接近,这也就意味着我们不能再进行重大变更。实际上,我们必须拒绝大量在“大型”beta 版本中获得的 bug 报告,因为它们仅影响了相对小众的客户,或是因为修订这些 bug 会把 RTM 版本置于风险之中。我们当然不是第一家遇到这个问题的公司;在这个产业里,整个敏捷软件开发运动都在聚焦于此。虽然我不想开启关于敏捷方法论的哲学讨论,但是很难否认尽早并经常发布对反馈回路的问题是有帮助的。

  某些开发者期望的特性未能纳入这次候选发布,其中最重要的是对自动解压缩的支持。为了不推迟本次发布,该特性将在完成后出现在后续版本中。

  为了在诸如 Silverlight 等老平台上支持 async/await,可移植 HttpClient 依赖 BCL 可移植性包

.NET不可变集合已经正式发布

  微软基础类库(Base Class Library)团队已经完成了.NET 不可变集合的正式版本,但不包括 ImmutableArray。与其一起发布的还包括针对其它不可变对象类型的设计指南。

  如果你需要在多个线程中安全地共享集合,并且允许每个线程在需要时对其内容进行改变。这种场景就是不可变集合所设计的初衷。只读集合在使用时需要复制集合中的全部内容,而新的不可变集合可以以一种更高性能的方式从一个现有集合中进行创建。

  使用不可变集合需要特别当心,因为你很容易错误地写成“list.Add (item)”,而正确的方法是“list = list.Add (item)”。甚至编译器也可能产生类似的错误,这也是为什么不可变集合不支持构造函数的原因。考虑以下代码:

list = new ImmutableList<int> {1, 2, 3};

  在编译后会产生以下代码:

temp = new ImmutableList (); temp.Add (1); temp.Add (2) temp.Add (3) list = temp;

  由于 3 次 Add 方法的结果都被丢弃,最终整个集合包含的项数目为0,而不是期望中的3。

不可变对象指南

  Immo Lendwerth 建议,当你在创建自己的不可变对象时,在其中加入适当的 WithXxx 方法。对简单的对象来说,为每一个属性创建一个 WithXxx 方法即可。当属性值需要变化时,该方法会返回当前对象的一个拷贝。

  如果某属性代表了一个结合,那么这种模式就需要一点变化。以下这段代码来自 Immo 的发布声明

class Order
{
    public Order (IEnumerable<OrderLine> lines)
    {
        Lines = lines.ToImmutableList ();
    }
    public ImmutableList<OrderLine> Lines { get; private set; }
    public Order WithLines (IEnumerableOrderLine> value)
    {
        return Object.ReferenceEquals (Lines, value)
            ? this
            : new Order (value);
    }
}

  如你所见,WithLines 方法可接受任意 IEnumerable。因此你可以传递一个新创建的 ImmutableList 对象,或者是某个 LINQ 表达式的结果。这种方式已经足以满足需求了,不过他还建议提供某些辅助方法:

class Order
{
    //... public Order AddLine (OrderLine value)
    {
        return WithLines (Lines.Add (value));
    }
    public Order RemoveLine (OrderLine value)
    {
        return WithLines (Lines.Remove (value));
    }
    public Order ReplaceLine (OrderLine oldValue, OrderLine newValue)
    {
        return oldValue == newValue
                ? this
                : WithLines (Lines.Replace (oldValue, newValue));
    }
}

ImmutableArray 被移除

  由于性能方面的原因,ImmutableArray 从最终的发布版本中被移除。其原因是:为了满足内存性能指标,ImmutableArray 必须设计成一个值对象,并且为了保持值对象的语义,ImmutableArray 的默认实例必须表现为一个空数组形式。不幸的是,为了达到这一点,对空值的检测(null check)会使得 C# 无法移除对数组边界的检测,而这一点是为达到良好 CPU 性能的一个重要考虑事项。

  由于 ImmutableArray 类对于 Roslyn 编译器项目非常重要,设计者曾考虑删除会导致性能问题的空值检测功能,但又因此产生了另外的问题,Immo 这样写道

由于所有的值类型都有一个自动产生的默认构造函数,它会将该值类型初始化为它的默认状态,而 ImmutableArray<T>的默认值是空,它的底层数组实现则为 null。因此,AddRange 方法的实现会因为 NullReferenceException 的产生而崩溃。

这一问题还表现在其它一些地方,由于 ImmutableArray<T>实现了某些集合接口(例如 IEnumerable 和 IReadOnlyList),因此你可以把它传递给某些接受这种接口的方法。由于这种接口引用是非空的,使用者在调用它的方法或者属性时不会考虑到有可能产生 NullReferenceException。

  基础类库团队并未放弃这个项目,他们还在研究其它设计方式,以争取让 ImmutableArray 重新亮相。

企业软件开发者继续使用.NET 4.0

  每次一有新版本的 CLR 发布,例如 .NET 2.0 和 4.0,开发者更新时都显得颇为无奈。CLR 的更新为运行时的表现带来了各种微妙的变化,这有可能破坏现有代码的运行。例如 DateTime.Kind 属性的变化就是一个灾难,另一个例子就是当后台运行线程抛出未捕获的异常时,会将整个进程中止这一变化。

  与之相反,纯类库改变的升级更容易被使用者所接受。当 .NET 3.0 与 3.5 推出后,许多开发者并未选择第一时间就切换至新版本,但他们也不担心接受升级带来的变化。一旦开发者需要某些新版本的特性时,他们可以从容地选择升级。

  但对于 .NET 4.5 的接受情况,我们却看到了不太一样的情形。根据一次非官方调查的结果,选择继续使用 .NET 的最主要原因是对 Windows XP 和 Windows Server 2003 的支持。虽然这些颇有年头的老产品已经差不多快要退出历史舞台了,许多公司还是不情愿地选择继续使用它们,以下是人们的一些评论:

出于对 XP 支持的考虑,在可见的未来内,基本上所有企业软件开发者都会继续使用 4.0。

由于客户不愿意升级他们陈旧的硬件设施,今后数年我们还是必须支持 XP,因此我们无法升级至 4.5。当年 Vista 发布之后,我们依然有客户坚持使用 NT 整整一年时间。

唉,为了 Windows 2003 server,我不得不继续使用 4.0。

他们总是这样告诉我:“如果旧机器能满足我们的需求,那何必花钱购买新操作系统的许可呢?”

我对此不敢苟同,但在小企业内,要想说服老板为什么不要继续使用 .NET 4.0 也是件困难的事,因为它本身并没有什么大缺陷。很遗憾,我想我对此无能为力,我不得不继续按照老方式编写代码。

  某个开发团队对此的临时方案是,将对客户端操作系统的依赖从他们的架构中移除出去。

我们对此的应对方式,是将更多的实际工作放到服务端,尽量保持一个瘦客户端。最终的目标是完全放弃使用需要部署的客户端,而让浏览器完成所有的工作。

  另一个我们所听到的继续使用 .NET 4.0 的原因,是开发者不愿接受 Visual Studio 界面的变化,下一条评论所代表的观点并不少见:

我继续使用 .NET 4.0 的原因,是 4.5 必须使用 Visual Studio 2012 进行开发。我和我的同事们对 VS 2012 的界面实在不感冒。不过看起来 VS 2013 似乎有所改善(不像 VS 2012 那么扁平和色彩单调了),我们大概会很快升级到这一版本吧。

Visual Studio 2013 RC面向Web开发者的新功能

Browser Link connects the IDE and Browser

ASP.NET 和VS2013RC Web工具今天发布了。如果喜欢的话,你可以抽空在VS2013预览版上安装它。这正是我所做的。

· 下载并安装VS2013RC

确认你在http://www.asp.net/vnext上查看了发布的注意事项和文档,还有更新过的教程。更多的文档和视频将会出来,包括如何去扩展和使用每样东西的详细步骤。因为这是候补发布版(而不是最终版)所以还有一些事情需要完成。

我最喜欢的一个功能,一个我认为最具代表我们发展方向的一个功能是浏览器链接而且最厉害的是它的可扩展性模块。

例如,你还记得你如何选择用浏览方式,设置多个浏览器作为你的默认浏览器么?(一些朋友还没注意到这个功能)我做了一个通常的幻灯片,用浏览方式对话框选择IE和Chrome作为我的默认浏览器(按住Ctrl健多选浏览方式)。

image

现在,按Ctrl-F5打开两个浏览器:

image

注意看Bootstrap现在是默认的模板了。我们将在最终版使用Bootstrap 3.0.

我将在Index.cshtml里改动一些文本。将鼠标悬停在工具栏上的浏览器链接按钮上:

image

它知道两个浏览器正在用SignalR和JavaScript与VS对话。这不是魔法,只是web的基本功能。

现在你可以敲代码和html脚本并按下Ctrl+Alt+Enter键刷新所有连接的浏览器,或者你点击浏览器链接仪表盘:

image

这就是仪表盘。我在已经在IE上点击过了:

image

更有趣的是,浏览器链接是可自扩展的。

我们与一个特定浏览器对话的那个浏览器链接仪表盘里的菜单在哪呢?你可以往里面加东西。Mads Kristensen已经用Web Essentials做到了这点并且向Browser Link里添加了扩展。(确保获得VS Web Essentials 2013 RC 版本, 或者你可以从源码编译!)

这就是安装了浏览器链接扩展的浏览器链接仪表盘的样子。看到添加的菜单项了么?

image

旁白:还要注意错误列表,我们可以在VS里添加新的一些列的错误甚至可以双击来修复它们。

image

如果我点击设计模式,看看会发生什么。设计面板隐藏地移动到了浏览器本身,用的是JavaScript但是是VS和浏览器之间的双向通信。

请记住Web Essentials是开源的,所以我可以通过读代码来了解这些是怎么回事。因为不用深究,我看了监督模式并且发现它正在用MEF。

[Export(typeof(BrowserLinkExtensionFactory))]
[BrowserLinkFactoryName("InspectMode")] // Not needed in final version of VS2013
public class InspectModeFactory : BrowserLinkExtensionFactory
{
...
}
这是行为的列表:
public IEnumerable<BrowserLinkAction> Actions
{
    get
    {
        yield return new BrowserLinkAction("Inspect Mode", InitiateInspectMode);
    }
}

这是用SignalR与注入的JavaScript对话:

private void InitiateInspectMode()
{
    Clients.Call(_connection, "setInspectMode", true);
    _instance = this;
}

我可以看到在浏览器的JavaScript里,当我鼠标悬停在浏览器里的元素上面,我可以选定它VS里面的源码甚至把VS拉到前端:

inspectOverlay.mousemove(function (args) {
    inspectOverlay.css("height", "0");
 
    var target = document.elementFromPoint(args.clientX, args.clientY);
 
    inspectOverlay.css("height", "auto");
 
    if (target) {
        while (target && !browserLink.sourceMapping.canMapToSource(target)) {
            target = target.parentElement;
        }
 
        if (target) {
            if (current && current !== target) {
                $(current).removeClass("__browserLink_selected");
            }
 
            current = target;
            $(target).addClass("__browserLink_selected");
            browserLink.sourceMapping.selectCompleteRange(target);
        }
    }
});
 
inspectOverlay.click(function () {
    turnOffInspectMode();
 
    browserLink.call("BringVisualStudioToFront");
});

这就是将要来临的技术的味道。One ASP.NET只是一段旅程,并不是目的地。我们还会朝着我们这个方向以及在今后的更新中(Update1等等)有更多的改进,更多的构架,和持续的改善。

浏览器链接只是其中一个功能,请确保查看(和订阅)MSDN上有关ASP.NET和Web工具的Web开发博客

  • One ASP.NET
  • Authentication
  • The new HTML5 editor
  • Azure Web Site tooling
  • Scaffolding
  • MVC5, Web Forms, SignalR 2, Web API 2
  • Entity Framework 6
  • OWIN Support and Self-Hosting
  • ASP.NET Identity
  • NuGet 2.7
请记住,虽然它看上去很多,但是这些几乎都是可由你取舍的附加的更改。你仍然可以在VS2013中制作开发ASP.NET 2应用程序。你可以用你自己的视图引擎,你自己的ORM,你自己的特性,你自己的构架,你自己的组件。由你决定。

image

我们很快将会有关于构架,修改和自定义添加你自己的新项目的文档和更新,还有新功能的列表并以NuGet软件包发布。详情请参阅http://www.asp.net/vnext关于诸多细节的发布说明以及任何重大更改

Visual Studio 2013+1 承诺新的C# / VB功能

  使用 Visual Studio 2013(VS2013)的 C# 和 VB 开发者关注的一些关键信息:Microsoft 程序经理 Mads Torgersen 已经确认在 VS2013 中这两个语言不会有任何特性更新。对此 Microsoft 给出的解释是,他们的语言团队正忙于完成基于 Roslyn 框架构建编译器的工作。正如 Torgersen 所说:

“虽然旧的编译器基础设施坚如磐石,并且能够漂亮地支持 VS 2013,但是我们在它上面实现新语言特性所花费的所有努力剥夺了我们对工具、语言特性和编译器 API 这些能够创造未来的投资。”

  (需要注意的是在 NET 4.5.1 Framework 中有新特性。)

  C#的创建者 Anders Hejlsberg 透露,对于 C# 和 VB 这两种语言而言 VS2013 和 VS2012 都会使用基于本地代码的编译器。但是,VS2013 的后续产品将会使用 Roslyn 项目作为其 C# 和 VB 编译器的基础。Hejlsberg 说 Roslyn 编译器的特性已经完成,并且它们已经在所有的内部C#/VB 代码库中进行测试了。为了消除存在的 bug 并进一步完善项目,该团队还使用 GitHub 和 CodePlex 等外部代码源进行了额外的代码测试。

  现在的情况是,一个新的 Roslyn CTP 可能会在 VS2013 发行之后发布。Roslyn 编译器被设计为放置在 VS2013 中能够在命令上启用或禁用,所以如果它们是带外发布的,开发者能够很容易地激活它们。Hejlsberg 承认完成 Roslyn 所花费的时间要长于预期,但是团队必须要确保它们能够正确地编译已有代码。在创建 Roslyn 时的另外一个困难是,开发团队需要解决本地代码编译器实现中未发现的 bug。

设置应用程序中嵌入IE的版本

有些时候会用到,如Live Writer设置成11000(即IE11)的话,便可以让其编辑器支持HTML5的标签

如以下的效果:

具体设置如下:

打开注册表,找到并编辑以下选项:

livewriterHtml5

32bit Configuration on 64 bit machine:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_BROWSER_EMULATION

Key: WindowsLiveWriter.exe
Value: 9000 or 10000  (IE 9 or 10 respectively) (DWORD value)

On a 32 bit only machine:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_BROWSER_EMULATION

Key: WindowsLiveWriter.exe
Value: 9000 or 10000  (IE 9 or 10 respectively) (DWORD value)

Use decimal values of 9000, 10000 or 11000 to specify specific versions of Internet Explorer.

VS2013 RC的一些新功能

尽管微软仍未宣布Visual Studio 2013最终版本的发布日期,但是MSDN和TechNet订户们已经在今天早些时候拿到了期待已久的Windows 8.1 RTM。不过,微软也没有忘记VS 2013,并且随着Win 8.1 RTM一道,正式推出了Visual Studio 2013的候选发布版本。但据报道,该RC版本其实几天前就已经被泄露到互联网上了。

在Visual Studio博客上,微软开发部门总裁Somasegar写到:RC中迎来了Cloud Business App模板,将使得创建为Office 365而打造的应用更加容易。

默认情况下,无需便携任何代码,Cloud Business Apps扩展了Office 365的体验、协作和交流,并且它们提供了一个基于HTML的用户体验。

Visual Studio 2013 RC1为XAML编辑器工具添加了一些功能,包括了数据连结智能感知(IntelliSense for Data Binding)、以及更多的TypeScript工具支持(基于微软2012年10月首次推出的编程语言)。

曾为程序员们带来"深入理解源码上下文"的CodeLens也已得到了更新,并且集成了Lync和新的bug indicators等功能。