We provide the ability in Visual Studio 11 to do native unit testing, with a new C++ unit testing framework shipping in the box. We’re really happy to enable this support for our C++ developers, so you no longer need to use the “/clr” flag or fall back to 3rd party frameworks. Read here for more details.
In my recent post on the “The Road to Visual Studio 11 Beta and .NET 4.5,” I shared my thoughts on some key industry trends that have influenced our most recent wave of development tools.
One such trend is represented by the order of magnitude increase in the number of people developing software. the proliferation of digital devices, the transformation to cloud computing, and the advent of app stores to provide reach and monetization opportunity for software developers all contribute to this increase. with such a surge, and with the breadth of app types being built, it’s no wonder that the number of choices developers have for languages, libraries, and frameworks has also increased significantly.
We continue to invest heavily in .NET. much of the work we’ve done in .NET 4.5 has been focused on making .NET a premier developer environment in which to build server-side applications and services (for example, with the scalability capabilities afforded by the new async/await support in C# and Visual Basic). .NET will continue to grow as a great choice for developers building cloud-based systems. at the same time, we fully recognize that the world is larger than .NET, and we want developers to be successful using Windows Azure regardless of the development technologies upon which they rely.
In that light, we are continuing on our roadmap of embracing popular Open Source Software (OSS) tools and working collaboratively with the open source community to build together a better cloud that supports all developers and their needs for interoperable solutions. Developers want to use the tools that best fit their experiences, their skills, and their application requirements; our goal is to enable that choice. We continue to be committed to providing an experience where developers can build applications on Windows Azure using the languages and frameworks they already know, and to making it easier to get started and to use cloud computing on their own terms.
Hopefully, this focus has been evident in much of the recent work that’s been done to reflect Windows Azure openness. for example, there are now SDKs available for working with Windows Azure from .NET, Node.js, Java, and PHP. There’s a developer preview available for using Apache Hadoop on Windows Azure. We’ve been working closely with 10Gen and the MongoDB community to provide MongoDB database integration for Windows Azure, including deployment packaging, documentation, and code samples. There’s an updated Eclipse plug-in for Java developers to work with Windows Azure, including support for remote Java debugging. There’s configuration guidance and documentation available for using Solr with Windows Azure. there are Windows Azure Toolkits available not only for Windows Phone and Windows 8, but also for Android and iOS. and the majority of these projects, and others like Python Tools for Visual Studio, are available under open source licenses. even from an IDE perspective, Team Explorer Everywhere supports developers accessing Team Foundation Server from Eclipse-based environments running on Windows, Linux, Mac OS X, Solaris, AIX, and HP-UX.
This only scratches the surface of the interoperability and openness work we’re doing for the cloud. in fact, just two weeks ago we announced a new subsidiary known as Microsoft Open Technologies, inc., to advance the company’s investment in openness. As we said at that time, Microsoft and our individual business groups will continue to engage with the open source and standards communities in a variety of ways, including working directly with many open source foundations and standards organizations. Today, MS Open Tech released a new version of the Redis port to Windows, providing, among other improvements, better performance over the version released in February. Additionally, today I’m excited to announce the release of a Metro style theme for jQuery Mobile, which enables Web sites and HTML5-based mobile application to use the Metro style.
You can expect us to continue doing more here over time.
Meeting Developers Where They Are
If you are interested in the Auto-Vectorizer feature, shipping in Visual Studio 11, please hop over to the Native Concurrency blog, where we are now on episode 4. the Overview post now includes a Table of Contents, with links to each separate post.
In my previous blog I talked about how in Visual Studio 11 we have eliminated the need to convert your Visual Studio 2010 C++ projects in order to adopt the new IDE. the blog also mentioned that you can build your projects using Visual Studio 2010 compiler (tools and libraries) from within Visual Studio 11 using the multi-targeting feature. this means while you adapt to using the new compiler and while your 3rd party vendors provide you with binaries compatible with the Visual Studio 11 compiler (tools and libraries) you can leverage the new Visual Studio 11 IDE without disrupting your ship cycle. Just set the platform toolset property to v100 in the property pages (requires Visual Studio 2010 to be installed side-by-side with Visual Studio 11). Since no upgrade of your project file is necessary you can continue to load the project/solution in Visual Studio 2010 as well.
We have recently received feedback from a number of customers about the inability to build binaries that run on Windows XP with the Beta version of the Visual Studio 11 compiler and libraries. this is because the C++ compiler and libraries in Visual Studio 11 Beta leverages platform capabilities only available in Windows Vista and higher. However, if support for Windows XP targeting is important to you, then you can use Visual Studio 11 Beta’s multi-targeting capability described above in order to employ the Visual Studio 2010 compiler and libraries to build applications and libraries than execute on Windows XP. this enables you to enjoy the new features of the Visual Studio 11 Beta environment without sacrificing backward compatibly in your applications!
Target Windows XP in Visual Studio 11 Beta using the Visual Studio 2010 compiler and libraries
Hi there! I’m Diego Dagum, a Program Manager with the Visual C++ team.
As Stephan announced last September when Visual Studio 11 Developer Preview was released, our STL implementation comes with SCARY iterators. On Stephan’s words,
”(…) as permitted but not required by the C++11 Standard, SCARY iterators have been implemented, as described by N2911 “Minimizing Dependencies within Generic Classes for Faster and Smaller Programs“ and N2980 “SCARY Iterator Assignment and Initialization, Revision 1”.
What are they useful for? what are they, in the first place? What’s so SCARY about them?
In this post I’ll demystify any mystery about SCARY iterators, hopefully inspiring in you some design best practice for your own template classes.
Imagine the following situation:
Does it compile or not? well, I tried to compile that code using a pre-v11 Visual C++ compiler, getting the following error:
The reason I’ve got this error is that in the last line of the code I’m trying to initialize iter (an iterator over a list of int using the default list allocator std::allocator<int>) with an iterator which looks similar excepts that it corresponds to a list allocated by the alternative stdext::allocators::allocator_unbounded<int>. Sad but true, these are different specializations of list of ints; therefore, conversions between them can’t be handled by default.
From a compiler perspective there is nothing wrong here. From a practical standpoint, however, there isn’t any semantic dependence between list iterators and list allocators. and, in general for all STL containers, iterators only depend (semantically speaking) on the container element type.
Based on research paper N2911 “Minimizing Dependencies within Generic Classes for Faster and Smaller Programs“, the acronym SCARY describes
Assignments and initializations that are Seemingly erroneous (appearing Constrained by conflicting generic parameters), but Actually work with the Right implementation (unconstrained bY the conflict due to minimized dependencies)
… or just SCARY, you know… (Don’t kill the messenger, I wasn’t the inventor of this name!)
In our STL11 implementation, iterator dependencies were minimized so the precedent code compiles fine. The same applies for any other STL container iterator (vector, deque, etc.) this said, you’ll be able to implement novel algorithms in ways that were previously impossible due to type mismatches. not that scary, after all!
Epilogue
The issue that prevented my program to compile isn’t just tied to a particular STL implementation. in fact, as N2911 “Minimizing Dependencies within Generic Classes for Faster and Smaller Programs“ tells, it’s a more general issue that can happen when designing generic classes. in its authors’ own words:
We advocate a design principle whereby the dependencies between the members and the type parameters of a generic class should be minimized, we propose techniques to realize this principle, and we show that the principle can be leveraged to achieve faster and smaller programs.
Worth reading. Enjoy!
PS. a HUGE THANKS to Stephan T. Lavavej (Mr. STL) for reviewing this post.
the Code Analysis team has just posted an article on the latest improvements in Visual Studio 11. If you are a C++ developer (we guess you are as you are reading this blog), it’s worth taking a look.
What’s New in Code Analysis for Visual Studio 11
Hello, I’m Pat Brenner, a developer on the Visual C++ Libraries team. Through this blog post I wanted to share some information about the Microsoft Foundation Class (MFC) Library, since I am the primary developer working on MFC.
As you know, MFC is an important technology component which has been extensively used over the years by C++ developers to build desktop applications for Windows. In every product release, we make enhancements to the library, whether it is taking advantage of features in newer versions of the Windows operating system or adding fixes for common developer issues. with the recent release of Visual Studio 11 Beta, there have been some concerns among the MFC developers about the apparent lack of focus on MFC.
In every release we need to balance our investment across the various areas of the product. however, we still believe that MFC is the most fully-featured library for building native desktop applications. we are fully committed to supporting and maintaining MFC at a high level of quality. Here’s a short list of some of the issues that we fixed in MFC for Visual Studio 11:
In addition to this, the Visual C++ teams have invested significantly in enabling C++ developers to natively build Metro style applications for Windows 8 (through compiler, libraries and productivity features). this is the primary reason that in this release MFC didn’t receive as much attention as in previous Visual Studio releases.
We don’t know yet what the future investments for feature additions in MFC would be. however, we’re committed to supporting MFC and making sure that applications built on it will run on future Windows platforms. I hope you find this information useful and reassuring.
Pat Brenner
Visual C++ Libraries Development Team
What’s up with MFC in Visual Studio 2011 Beta
In my first post of this Visual Studio 11 series, I discussed some of the language-level innovation in the Visual Studio 11 Developer Preview. In this second post, I’ll take a look at some of the improvements that have gone into the .NET Framework 4.5 Developer Preview.
Languages enable developers to express their intentions for the behavior of their programs. To be as productive as possible, however, developers rely on runtimes and libraries to encapsulate commonly needed functionality. our teams have augmented.NET 4.5 significantly to enable developers to be as productive as possible while building out rich, reliable, and high-performance software in managed code. my goal here is not to detail every new feature that’s been included (such an endeavor would warrant an entire book), or even to touch on every area of the Framework that’s been improved. instead, I simply want to highlight a few additions that I believe are representative of the forward strides we’re making. for a broader look at what’s new in .NET 4.5, I recommend Joshua Goodman’s talk from //BUILD/ as well as the MSDN documentation on the topic.
Performance
For the .NET Framework 4.5, a lot of effort has gone into improving performance, both in terms of improving the performance of existing code as well as into providing new support for writing code that just runs faster, that’s more responsive, and that’s more scalable.
The Common Language Runtime (CLR) team has focused heavily on improving the performance of the runtime environment itself. With additions like background server garbage collection, multi-core background JIT compilation, and profile-guided optimization, managed applications (especially those on the server) can now start faster and run with better throughput and lower latency.
Performance improvements extend beyond the runtime execution environment, as core components throughout the Framework have been rewritten internally to provide improved performance in key scenarios. for example, the Stream class in .NET sits at the heart of most I/O-related operations, and asynchronously reading and writing with Stream is extremely common; these operations now have significantly less overhead in .NET 4.5. as another example, ItemsControl in Windows Presentation Foundation (WPF) has been made much faster at handling certain kinds of data.
This work in streams is part of a larger focus on asynchrony in this release. as I mentioned in my previous post on languages, C# and Visual Basic have both been extended with first-class language support for writing asynchronous code. That support extends well beyond the languages and into the libraries in the .NET Framework. New task-based APIs have been added across the Framework, including in core Base Class Library (BCL) types, throughout the networking and Web services stacks, in the system.Xml and system.Data libraries, and more.
For more information, I recommend the following talks from //BUILD/:
Networking
It’s relatively rare these days to see an isolated application, one that doesn’t communicate in one way or another. .NET has historically been rich with high-quality networking libraries, whether for low-level socket-based programming or for high-level communication via Web services. .NET 4.5 builds upon that foundational support to enable the development of increasingly connected applications. While there are a multitude of interesting networking-related improvements in the .NET Framework 4.5, I want to call attention to three in particular.
WebSockets is a new bidirectional communication protocol that supports low-latency communications between client and server. It’s great for implementing interactive applications, such as online games, that benefit from server to client “push,” and .NET 4.5 includes support for WebSockets both in ASP.NET and in Windows Communication Foundation (WCF). this release of .NET also sports the new HttpClient class, which enables clients and servers to easily and efficiently consume existing web APIs.
The other advance I want to call attention to is the integration of Tasks with WCF. With the aforementioned language support, asynchronous APIs across the Framework are being exposed via tasks. beyond these APIs included in .NET, however, there are also APIs generated for you by Visual Studio. one significant source of such APIs is for WCF Web service endpoints, as created by the Add Service Reference… dialog. In previous releases, this tool by default only generated synchronous operations, and you could use the advanced configuration dialog to opt-in to having asynchronous operations exposed. Now in Visual Studio 11 Developer Preview, by default the tool will not only generate asynchronous operations, it will do so using the task-based asynchronous pattern.
This means that all Web services to which you add service references will immediately support being awaited in asynchronous methods. Here’s an example of using one such generated proxy to make asynchronous calls to search Bing:
For more information on the networking improvements in .NET 4.5, I recommend the following talks from //BUILD/:
Interop
A look at advancements in the .NET Framework would not be complete without an acknowledgement that the Framework itself contains only one of the sets of libraries your applications use. In addition to all of the libraries from the .NET Framework that you rely upon, you also rely upon libraries of your own creation and of those created by 3rd-parties. Historically, many of the libraries used in your applications have been thin wrappers on top of operating system functionality exposed by Windows… accessing the file system, accessing audio and video devices, and more. since the first release of .NET, the CLR has provided the ability to interop with such capabilities, but doing so has rarely been a trivial exercise.
With .NET 4.5 and with the advent of the Windows Runtime (WinRT), the need to create such interop wrappers becomes a thing of the past. through advancements in the CLR, your .NET applications can reference the metadata files for these components, and the CLR takes care of the interop details necessary to enable you to use these components as you would other .NET libraries. this is a terrific productivity boon for developers.
For more information on the interop improvements in .NET 4.5, I recommend the following talks from //BUILD/:
There is a huge amount of functionality I’ve skipped past and glossed over in this post. the BCL, the Managed Extensibility Framework (MEF), system.Xml, system.Net, WPF, ADO.NET, ASP.NET, WCF, Windows Workflow Foundation, Parallel Computing, and on… they’ve all received good attention in this release, and I’d encourage you to explore on your own to learn more about the work the teams have delivered.
Visual Studio 11 .NET Advances
In my last few blog posts, I’ve highlighted significant advancements our teams have made as part of the Visual Studio 11 Developer Preview released at //BUILD/, and I’ll continue that series in future posts. Today, however, I want to highlight some innovative work our teams have been doing that is even more forward looking.
I’m excited to announce that we’ve just released the Microsoft “Roslyn” CTP, which enables the C# and Visual Basic compilers to be used as a service. while we’ve been busy working on C# 5 and Visual Basic 11, via Roslyn we’ve been working concurrently on a complete rewrite of the C# and Visual Basic compilers. whereas today’s compilers are implemented in native C++, in Roslyn we’ve rewritten the compilers from the ground up, implementing the C# compiler in C# and the Visual Basic compiler in Visual Basic. That in and of itself isn’t entirely noteworthy, as it’s long been a tradition for a language compiler to be implemented in its target language, something that’s been true of both our F# and Visual C++ compilers. What’s quite noteworthy are the scenarios and services this work enables.
Historically, the managed compilers we’ve shipped in Visual Studio have been opaque boxes: you provide source files, and they churn those files into output assemblies. Developers haven’t been privy to the intermediate knowledge that the compiler itself generates as part of the compilation process, and yet such rich data is incredibly valuable for building the kinds of higher-level services and tools we’ve come to expect in modern day development environments like Visual Studio.
With these compiler rewrites, the Roslyn compilers become services exposed for general consumption, with all of that internal compiler-discovered knowledge made available for developers and their tools to harness. the stages of the compiler for parsing, for doing semantic analysis, for binding, and for IL emitting are all exposed to developers via rich managed APIs. as an example, in the following screenshot I’m taking advantage of the Roslyn APIs to parse some code and display the tree of syntax nodes.
The Visual Studio language services for C# and Visual Basic have been rewritten to use these new APIs. and new tools have been introduced to take advantage of all of these services. for example, the new C# Interactive window enables scripting and exploration in C#:
Roslyn represents an exciting opportunity for developers to build richer tools, such as refactorings and deep visualizations, utilizing the same support that Visual Studio and its compilers would use for their work. it should be noted, however, that this is an early look at this compilation infrastructure, as the Roslyn work is focused towards a post-Visual Studio 11 release. this CTP will help to illuminate the kinds of exciting end-to-end experiences that are possible with such technology, but at the same time this particular release only supports a subset of each language and is intended for exploration and to enable us to gather feedback from you on the direction.
For more information on Roslyn, to download the CTP, and to let us know what you think, visit http://www.msdn.com/roslyn.