We have fixed a few of the bugs you have reported to the forums. The installer on the site has been replaced with the new version. All you need to do if you were affected by the bugs is to uninstall Volta, download new version from http://labs.live.com/volta and install again.

Thank you for submitting these bugs to us, please feel free to continue asking questions, report issues and give suggestions.

The bugs that we addressed in this update are:

• Add support for tiersplitting WPF applications (will require some manual editting of the project)
• There was a disparity in System.Threading.Timer between Desktop CLR (Debug) and Javascript (Release)
• There was an issue creating / retreiving H2 elements
• There were issues around table creation using CreateTHead and CreateTFoot.
• An exception was throw when navigating away and then using the backbutton.
• Location.HRef did not work
• Iterating over Document.All throw an exception in debug mode.

Thank you again for reporting these and helping make Volta better!

Tanzim Saqib wrote a very nice article on how to create controls in Volta. His article gives step by step instructions on how to write a Flickr control that you can reuse  in your pages. The control covers the Flickr API, how to make asynchronous requests to Flickr’s REST APIs, parsing the resulting xml, dynamic building of UI and including resources (css).  The same basic principles can be applied to building widgets for any number of different services. 

In our final installment on the Volta conspiracy, we want to touch briefly on the topic of Volta as a way to write applications vs. your choice as a developer on what the appropriate client runtime is.

Secret #5: Silverlight

The final question that is frequently asked is how Volta relates to Silverlight.  Is Volta meant to replace Silverlight?  Are we trying to make JavaScript work for the same scenarios as Silverlight?  Simply put, no.  As others have observed, Volta is compatible with and is built to be complementary to Silverlight.  The Microsft PressPass Q&A about Volta further explains that Volta is an MSIL to MSIL toolkit aimed at making writing distributed applications easier. Silverlight is an implementation of the .NET platform that therefore will automatically benefit from the advantages of the Volta toolkit. The technologies complement each other well, and we believe that amplifies and validates the importance of the complete .NET platform, including Silverlight.   

All the benefits of the Volta toolkit, such as declarative tier-splitting and asynchronous programming or declarative import of JavaScript libraries into .NET, will apply to programs deployed to the Silverlight platform. In fact, we are in the process of replacing the browser helper objects used to facilitate debugging in this preview, which host the regular desktop CLR in IE and Firefox, and are replacing them instead with the Silverlight 2.0 runtime.

Charles on Channel 9 framed the idea quite well when he said:

"So, the most obvious case is Silverlight 2.0 as the client tier and a web server as the server tier... This is a great scenario since Volta can split IL to IL without having to resort to IL translation to, say, JavaScript (which has gotten too much attention). Further, execution contexts such as XNA, WinForms, DHTML, SVG, VML, even SQL are realistic client targets (tiers) for Volta. Then there's the notion of a local "distributed" system (think of applications running on a single client as the tiers) where Volta also makes sense as a means of easily composing the system."

Volta is about enabling developers to write a unified code base for distributed application, making decisions about both the appropriate distribution of remoting boundaries and the client runtime a function of the application's requirements, and allowing those decisions to be changed much more easily than they can be today.

The latest installment of our ongoing series about Volta's deepest, darkest secrets brings us to language support.

Secret #3: Visual Basic

Sometimes, it seems as if honesty does not pay off. In the "known issues and limitations" section of the Volta documentation we mention that we do not fully support Visual Basic. From this some people quickly conclude that we treat Visual Basic as second class citizen. This is rather ironic because whenever we talk about Volta our demos are usually done in Visual Basic.

The reason we do not fully support Visual Basic in this specific scenario is simply because we do not support the full Base Class Libraries (BCL) when compiling to JavaScript; and some of the types that we do not support (such as Reflection and CultureInfo) happen to be required by the Visual Basic runtime.

We know how to solve this problem; it is just a matter of work. Unfortunately a lot of work because the BCL contains rather many types that are all quite tightly coupled to each other.  Instead of delaying the preview release of Volta while we did this work, we instead opted to get Volta into developers hands quickly to discover things we do not know yet.  Further Visual Basic support is something we will continue to work on as we iterate on Volta.

In part 1 of our series on Volta's ongoing conspiracy we covered the GWT myth; in part 2, the performance of JavaScript.  Here, we cover a little more of our take on balancing complexity and control when tier-splitting.

Secret #3: Remoting Boundaries

When we talk about making distributed and asynchronous programming easy using declarative custom attributes and automatic MSIL to MSIL rewriting, many people quickly conclude that we do not understand the "Fallacies of Distributed Programming". This is rather ironic because whenever we talk about Volta we usually reference this seminal paper and point out the failure of location transparency as found in say DCOM.

As usual when the pendulum swings from one extreme to the other, some parts of the baby get thrown away with the bath water. In this case the rise of web services unfortunately saddles developers with potential accidental complexities with SOAP, WSDL, WS-*, etc., which can in certain scenarios become part of the problem instead of just the solution--even though they do the right thing with respect to exposing location awareness. This is one of the reasons we see a rising interest in RESTful web services.

By definition, we can never have enough abstraction. Abstraction means leaving out unnecessary details, and as long as there are unnecessary details left, we can keep abstracting from them as long as you leave necessary details in place. This is exactly what Volta aims to achieve; let the tools take care of the unnecessary details and the programmers decide on the necessary ones.

Microsoft's own Channel 9 has just posted two videos from a discussion with the Volta development team.  You'll learn more about what Volta is, how it works, and how to write applications with it:

Tier Splitting Volta: Who. What. How. Why - Part 1

"In this episode (or part 1, if you will) we meet the team and learn the basics. Since it's a room full of devs there is whiteboarding and lots of techincal talk, just the way we like it here on C9."

Tier Splitting Volta: Who. What. How. Why - Part 2

"This is part 2 where we continue to dig deeply into Volta. Lot's of whiteboarding and even a code sample using VS."

 

Continuing our series on the secrets Microsoft does not want you to know about Volta, we want to touch on a topic that is apparent to anyone who has tried using the Word Worm sample.

Secret #2: Performance

Many people that try to run the samples from the Volta website correctly observe that the performance and especially the load time of these samples is sub-optimal. To allow people to play with our samples from the website, the easiest way currently is to deploy these samples as JavaScript since it does not require any installation. The downside of this approach is that for this preview release we did not not optimize for performance, but instead concentrated on providing developers with an end-to-end view of Volta such that we could get valuable feedback about the Volta programming model.

Building an MSIL to JavaScript compiler that generates more efficient code than human programmers can write by hand is a tractable problem and one we are working on for future versions of Volta. This is exactly what the goal of a good compiler is; raise the level of abstraction and at the same time boost performance of the generated code. However, though we know how to improve performance and intend to do so in future iterations the goal of this release was not performance. Instead, we are seeking feedback on aspects of Volta that we do not know exist. In other words by putting Volta in the hands of developers early on, we are hoping to find some unexpected Black Swans. 

So, experiment with Volta, tell us what works and what doesn't--but keep in mind that performance of applications compiled to JavaScript is not yet optimized.

After releasing the Volta preview on December 5th, the blogosphere has been thick with conspiracy theories about Volta. At times it felt as if we were watching another episode of the X-files or reading one of those gossip magazines. According to reverse psychology, the way to set this straight is by acknowledging that there is indeed a conspiracy behind Volta. However, as boring as it sounds, that just in not the case. We are just a small team of hackers that are trying to push the envelope. And most importantly, we assume you are not easily fooled by cheap psychological tricks. So instead, we will give you the straight answers to the top 5 most frequent questions about Volta in a quick series. Here is #1:

Secret #1: The GWT Conspiracy

One common characterization of the last week is that Volta is "Microsoft's GWT clone". As Volta architect Erik Meijer explained  on ZDNet last week, what might seem similar at first glance actually have big differences in their construction and implications. The focus of Volta is on extending the .NET platform to cover the Cloud, hence the essence of Volta is to enable multi-tier and asynchronous programming via declarative attribution and MSIL to MSIL rewriting. We can use the Volta toolkit for any source language as long as it compiles to MSIL, and for any target execution environment, as long as it accepts MSIL. This means that we can as easily tier-split a WinForms application as we can tier-split a Web application.

The fact that we also include experimental support for MSIL to JavaScript compilation is somewhat of an distraction from the key Volta message. The main reason that we are interested in JavaScript is not so much in compiling MSIL to JavaScript but in enabling importing JavaScript libraries into .NET. JavaScript libraries such as Virtual Earth or Search are generally useful far beyond just Web-based applications, and Volta makes it possible to import external JavaScript libraries into ordinary .NET programs. Just like tier-splitting and asynchronous methods, we use declarative custom attributes to remove all the noise from importing JavaScript libraries to .NET.  It might be interesting to observe that, technically, interop with JavaScript is just another example of tier-splitting. Instead of running an application across server and client, it runs across CLR and the JavaScript execution engines.

Today, we are announcing the Volta technology preview, a developer toolset for building multi-tier web applications using existing and familiar tools, techniques and patterns. Volta’s declarative tier-splitting enables developers to postpone architectural decisions about distribution until the last possible responsible moment. Also, thanks to a shared programming model across multiple-tiers, Volta enables new end-to-end profiling and testing for higher levels of application performance, robustness, and reliability. Using the declarative tier-splitting, developers can refine architectural decisions based on this profiling data. This saves time and costs associated with manual refactoring. In effect, Volta extends the .NET platform to further enable the development of software+services applications, using existing and familiar tools and techniques.

You architect and build your application as a .NET client application, assigning the portions of the application that run on the server tier and client tier late in the development process. You can target either web browsers or the CLR as clients and Volta handles the complexities of tier-splitting. The compiler creates cross-browser JavaScript for the client tier, web services for the server tier, and all communication, serialization, synchronization, security, and other boilerplate code to tie the tiers together. In effect, Volta offers a best-effort experience in multiple environments without requiring tailoring of the application.

Learn more about Volta and download it to try building applications yourself >