Anith Gopal

  Problem: When you develop a WCF/Workflow service using Visual Studio and try to run it, by default Visual Studio runs it under web development server. Here the problem is that the web development server is a light weight host and does not support reach features which comes with IIS.

Come get a full day of technical training on the new technology coming in Windows 8 and the new Metro design principles.

In this video blog, we would walk you through some tips and methods to troubleshoot Missing MSI’s/MSP’s error during SQL Server Patching or installation.

If you are new to Windows Phone and want to know how to quickly use photo apps on your phone then watch the video below Rob Technorati Tags: Windows Phone , WP7

The below command can be used to upgrade SQL server 2008 to SQL server 2008 R2 silently , please enter the correct instance name.

[原文发表地址] Round-tripping with Visual Studio 11 [原文发表时间] 2012-03-28 8：00 大约两年前我们发表了一篇博客，题为 为什么Visual Studio 2010 转换了我的项目？ 我们收到的最多反馈是你们希望能够使用当前的和以前的VS版本来操作你的项目。我们很高兴地宣布 Visual Studio 11 将让你轻松地与 Visual Studio 2010 SP1 往返切换你的项目！这意味着你可以利用 Visual Studio 11 的功能，同时与可能仍在使用 Visual Studio 2010 SP1 的团队成员协作同一项目。 当我们开始着手启用往返切换时，我们意识到执行该功能归结为实现三个目标： Visual Studio 11 只适用于现有的 Visual Studio 2010 项目 很容易并可行地升级到 Visual Studio 11 团队在同一时间可以使用 Visual Studio 11 和 Visual Studio 2010 实现这些目标的关键是要回答一个问题 — — 是否一个项目可以利用Visual Studio 2010 和 Visual Studio 11 中相同的工具集，并呈现相同的design-time和运行时行为。在 Visual Studio 2010 中，我们启用了完全的多目标，并把它作为 Visual Studio与.NET运行库之间的一对一的纽带，这就允许使用Visual Studio 2010所创建的项目指向较旧的.NET 框架，这让在Visual Studio 版本之间往返切换项目变得事倍功半。当在不同环境中操作时，我们在 Visual Studio 11中采取自然步骤来正确处理项目。 我们通过Visual Studio 中附带的所有资产来迭代，我们意识到要提供一个无缝的往返转换体验，我们需要为Visual Studio 2010提供服务，那样当处理修改过的或甚至升级过的项目时，它可以提供适当的用户体验。例如，Visual Studio 2010 中的Web 项目使用硬编码“v10.0”，指定路径为它们的生成目标。如果使用Visual Studio 11 打开Visual Studio 2010 Web 项目，这显然不行，因为Visual Studio 11使用"v11.0"生成目标。该问题的解决方案就是在生成目标路径中将硬编码的 Visual Studio 版本字符串替换为 $(VisualStudioVersion) 属性，它将会基于Web 项目加载的环境来动态地更改其值。我们不得不为Visual Studio 2010提供服务，那样它可以识别并接受新的属性。 每个新的 Visual Studio 版本都有一组新的语言功能，并附带在.NET 框架推出的编译器中，还有一些附带在Visual Studio推出的编译器中，用于智能感知和其他用途。例如， 异步 是.NET 4.5 和 Visual Studio 11附带的一个功能。这意味着，如果在 Visual Studio 2010 中打开一个使用了异步的项目，会出现生成错误，因为Visual Studio 2010不懂新的语言功能。当使用Visual Studio 11 的团队成员无意中使用新的语言功能时，这可能会导致混乱的用户体验。检查代码后，表面上能成功运行，但一旦在 Visual Studio 2010 的计算机上运行项目，它们将无法运行。 虽然审查了Visual Studio 2010 和 Visual Studio 11推出的每个资产和功能体验，我们意识到若要提供无缝的往返转换的体验，我们需要约束两个功能： 往返切换仅限于 Visual Studio 2010 SP1 和 Visual Studio 11 之间 所有指向NET 2.0 到 4.0 ，以及 Silverlight 4，Silverlight 5的项目可以往返切换。 一旦约束生效，我们决定了四种类别的项目： (1) 那些可以无缝地往返的项目(2) 那些需要做一些修改来往返的项目，(3) 部分不能往返， (4)在 Visual Studio 11 中已被弃用的几个项目。这篇文章的其余部分将详细阐释每个类别，并描述我们设计它的体验。 第 1 类：无缝往返切换 大多数项目属于此类。这些项目在 Visual Studio 11 中打开时与它们在Visual Studio 2010 SP1 中的行为完全相同。你可以在 Visual Studio 2010 SP1中重新打开它们，你会发现在 Visual Studio 11 中所做的修改被保留下来了，并且项目继续如同在 Visual Studio 11 中所操作的一样。 此类别中有两种类型项目： 完全不需要修改 ：在 Visual Studio 11中加载时没有涉及到的项目。例如，Windows Forms项目。 需要进行修改，但不会更改项目行为： 对于那些生成目标路径为硬编码过的 Visual Studio 版本的项目，需要使用$(VisualStudioVersion) 属性来替换其以便启用往返转换，那样Visual Studio 11 会根据项目加载自动做修改，然后在解决方案目录中备份修改过的文件。如果这些项目在源代码管理下，它们会自动签出并编辑。这些修改 启用了 往返，同时 不影响 你的项目行为。MVC 3 项目就是此例。 第 2 类： 需要做一些修改来往返切换 为了在 Visual Studio 11 中加载这些项目，必须做一些修改来更改项目的行为。然而修改后，这些项目将会无缝地与 Visual Studio 2010 SP1切换。 当你在 Visual Studio 11 中加载这些项目时，你将会看到一个 审查项目和解决方案更改 对话框。例如，当在Visual Studio 11 中加载Silverlight 3 项目时，将会出现一个 审查项目和解决方案更改 对话框，因为Visual Studio 11不支持Silverlight 3，因此项目需要重定向为Silverlight 5。 请注意此对话框的以下功能： 若要了解有关状态的详细信息，你可以悬停在其上面，这将调用一个工具提示来解释它们的意思。 如果你仍不清楚当前你对你的项目所做的更改，你可以单击 More information ，它将带你到 MSDN 帮助页面，其中列出了Visual Studio 中所有的项目类型和为了在 Visual Studio 11 成功加载它们而发生的变化。 如果你需要在提交迁移之前咨询你的团队，你可以右击对话框的中间窗格，并选择 复制信息，这 会将对话框的内容复制到剪贴板上。复制到剪贴板上的内容列出了解决方案中的所有项目。在对话框中没有出现的那些项目属于第一类：无缝往返切换。 使用复选框来指定你想要迁移的项目。未选中的项目不将在Solution Explorer中被加载，并有一条“需要转换”的消息。你可以重新加载这些项目，这将触发 审查项目和解决方案更改 对话框重新出现。 迁移后，所有修改过的文件都将在解决方案目录中备份。并会创建一个迁移报告，保存在解决方案目录中，如果有任何迁移错误或警告的话，就只能在web 浏览器中打开此报告。 一旦迁移完成后，项目在 Visual Studio 2010 SP1中打开时，不会有任何问题。如果是 Silverlight 项目的话，只要Visual Studio 2010 SP1 的机器上安装了 Silverlight 5 工具 ，它就会重定向到为 Silverlight 5，并继续与 Visual Studio 2010 SP1 进行无缝往返切换。 第 3 类 : 不能往返 当在 Visual Studio 2010 SP1 和 Visual Studio 11 中打开这些项目时，不能表现出相同的design-time和设计时行为。当在 Visual Studio 11 中打开这些项目时，将会出现一个 审查项目和解决方案更改 对话框，通知你需要一个单向的升级。例如，由于 VS SDK项目用于为特定的Visual Studio版本创建扩展，因此项目本身需要在有针对性的 Visual Studio 版本中运行。 迁移后，这些项目将不能往返切换，在 Visual Studio 2010 SP1 中打开它们将导致加载失败和 ‘不兼容的消息。 第 4 类：已弃用的项目 Visual Studio 11 中不支持这些项目类型。打开已弃用的项目将在web 浏览器中打开迁移报告。 在上面的示例中，每个已弃用的项目都报告为一个错误。相应的链接将带你到该项目类型的帮助页面，这将帮助你将已弃用项目中的资产迁移到 Visual Studio 11中。 参考 Visual Studio 11 兼容性 帮助页面列出了所有的项目类型、文件类型和变更的种类，它们能帮助你在 Visual Studio 11中 成功加载项目。如果你有一个自己的项目系统，并想参与往返切换基础结构，请参阅 如何： 修改项目系统，那样项目可以在多个Visual Studio版本中加载 帮助页面。 一如既往，欢迎大家提交反馈！你可以在这篇博客帖子中留下你的评论以及在 Microsoft Connect上 提交Bug。

No último dia 04/03/2012 (Sexta-feira) tive o prazer de realizar mais uma edição dos Web Dev Camps no Sul do Brasil. Desta vez o evento foi realizado nas dependências da escola técnica Alcides Maya, no centro de Porto Alegre. No total, cerca de 150 pessoas …read more…( read more )

http://aka.ms/de  

“TCP/IP and Ethernet will not be accepted as a valid network implementation as SNA and Token Ring are our preferred standards.” – circa 1993 by nameless corporate Information Systems expert. I was shocked when I had heard this, and images of ostriches with their heads in the sand immediately came into mind. I was new to my career, and attempting to challenge the old masters of the all mighty Information Systems department was considered blaspheme.

It is a known limitation that AIF does not serialize null values in outbound XMLs.

It has been a while since I got a new piece of hardware and today I am setting up a new HP machine. It’s pretty nice – 8 core, 16GB RAM, and about 2TB of hard drive space. The only challenge is moving my virtual machines from the machine that is being replaced to the new machine

As I’ve developed VsVim over the years I’ve authored quite a few reusable Visual Studio components.  For the last 6 months I’ve had many of these factored out to a separate utility library and this last week I decided to publish them as a separate NuGet package.  Even if no one else every uses the library I want to reuse the utilities in other projects I’m working on and NuGet is the perfect distribution mechanism.  For those interested I’ll be blogging about these components and why I authored them in the coming weeks (hint: perf, perf and more perf).  I wanted to blog about my the rules I learned from this exercise because even as a seasoned extension author I hit a couple of very surprising problems along the way.  Hopefully the lessons I learned will help out the next person to attempt this Utility libraries must be signed This is an unfortunate truth of authoring a utility library in Visual Studio.  If you intend to ever release more than one version of a utility library then you must accept that there will be two extensions referencing different versions of your library in the same instance of Visual Studio.  Unless the assemblies are signed the CLR will only load one version into the AppDomain.  This means one extension will see the version it expects and the others won’t.  This would be disastrous if the newer version of the library had new MEF interfaces, features, etc … Simply being very diligent with version numbers just isn’t enough here.  When comparing a DLL reference to a DLL loaded in memory the CLR will ignore version numbers on unsigned assemblies [1].  If an app has a reference to MyUtility.dll at Version 99 and MyUtility.dll at Version 1 is loaded the CLR will consider it a match.  There’s nothing I’m aware of, other than signing, that will change this behavior. This also means you can’t even rely on the latest version of your utility library being loaded.  Extension load order is not defined in Visual Studio [2].   Hence it’s quite possible that extension referencing the oldest version of your utility library loads first and establishes that version as the one every other extension will use.  When an assembly is signed the CLR will respect version numbers and load multiple versions of the assembly into the AppDomain at the same time.  Every extension will then see the version they are expecting independent of what other extensions are installed on the machine.  MEF isn’t version safe by default MEF gives the appearance of being a model that deals in terms of types.  Contracts are typically defined in terms of interfaces, [Export] of the implementation use a typeof experession and the associated [Import] is tagged on a type location.  Everything about it screams Type, yet MEF doesn’t actually deal in terms of types, it primarily deals in terms of strings.  Specifically in the form of a contract name and type name.  Every export and import have a contract name and type name associated with them.  Only when both the contract name and type name match does MEF consider an Import and Export to match.  Consider: [ Export ( typeof ( IObjectCache ))] internal sealed class ObjectCache : IObjectCache { } The above code did not create an export of the .Net type IObjectCache or even it’s assembly qualified name.  Instead it created an export with Contract Name: SomeNamespace.IObjectCache Type Name: SomeNamespace.IObjectCache Note: If you don’t specify a contract name explicitly MEF will just reuse the type name it generates Notice that no assembly information is captured in this export.  It’s just a type name plus the enclosing namespace.  This contract will match up with any other Export of a type with the same fully qualified name as IObjectCache in any assembly loaded into the AppDomain.  And this is exactly what will happen if you have multiple versions of your library loaded into the Visual Studio process [3] In order to have version same MEF components the export and import contracts need to be different for different versions of your library.  The easiest way to achieve this is to embed the assembly version into the contract name portion of an Export and Import.  In my projects I achieve this by means of a constant which I reuse in my AssemblyVersion attribute and Exports public static class Constants { public const string AssemblyVersion = "1.0.0.0" ; public const string ContractName = "MyUtility " + AssemblyVersion; } [ Export ( Constants .ContractName, typeof ( IObjectCache ))] internal sealed class ObjectCache : IObjectCache { } [ assembly : AssemblyVersion( Constants .ContractName)] Unfortunately this messiness isn’t something that can be self contained within your library.  It’s a price you must push down to your consumers as well.  Their [Import] attributes must have the same contract name else MEF won’t consider them a match and will reject the composition.  Hence consumers of your library must use a similar pattern.  public class MyService { [ ImportingConstructor ] public MyService([ Import ( Constants .ContractName)] IObjectCache objectCache) { } } This applies to all ImportingConstructor, Import and ImportMany usage of your types.  Both of these lessons set me back quite a bit.  But eventually I was able to produce the EditorUtils package I’d been working on and change VsVim to use it.  Hopefully there aren’t many more surprises waiting for me around the corner …     [1] Except for Silverlight [2] Unless there is an explicit entry in the manifest file declaring a dependency. Won’t ever happen for unrelated extensions.