Microsoft Live Labs :: VOLTA

Microsoft Live Labs Volta helps developers who build distributed applications on the .NET platform, using the Microsoft development stack (programming languages, libraries, and Visual Studio). This version of Volta supports applications that run on the Microsoft CLR, a JavaScript-enabled browser, or a combination of the two.

First, this document introduces the Volta technology. Then, it covers two important Volta targets that developers are likely to build and deploy: applications and controls. Recipe-like descriptions for several common web-based scenarios follow. The document concludes with an overview of the libraries installed with Volta, and a summary of known issues and limitations.

The Volta Programming Model

In essence Volta is a recompiler. Volta works on MSIL rather than on a textual source language. Volta rewrites MSIL into any number of target languages, including, today JavaScript and MSIL itself. Rewriting, as a general technology, lets us delay permanent decisions about architecture, execution platform and browser until after our code is basically working. Furthermore, it frees us from having to express all these irreversible decisions in your source code. The result is a programming model that enables us to easily reshape a working application, and finally realizes the promise of one application running anywhere.

Volta effects recompilation through 3 general capabilities: refactoring, retargeting, and remodulating. Refactoring converts single-tier code into distributed, concurrent code as directed by user-supplied annotations. Retargeting converts MSIL code into code for other virtual machines. Remodulating tailors a single piece of code for multiple browsers. The next 3 sections explain in more detail.

Architecture Refactoring

The Volta programming model takes refactoring one step further. Volta applies transformations on our compiled code based on metadata, in particular, custom attributes prefixed on classes or methods that could run on a server tier. During development, all code runs in the client for ease of testing and debugging. Redistributing the code amongst client and server is merely a matter of moving custom attributes around and rebuilding. The Volta rewriter automatically creates and deploys the marshalling and security code necessary to execute the code on multiple tiers. The following diagram illustrates evolution of a Volta application from single-tier architecture to a distributed, multi-tiered architecture.

After refactoring, notice that the same application that used to run in one instance of the CLR is now running on two tiers. Volta dramatically extends the reach of the .NET platform to cover the cloud. We emphasize that the only differences at the source-code level are the presence and positions of custom attributes. Volta doesn’t eliminate the intellectual challenges of distributed computing. We must still formulate strategies for partitioning functionality and dealing with network latency and availability. Volta does, however, radically simplify the error-prone plumbing and re-plumbing of communication code.

Volta leverages the entire .NET platform, including most libraries and programming languages. We can write in our favorite .NET languages, use familiar .NET libraries and tools, and produce sophisticated distributed applications using only the “materials already in the room.” Without Volta we are exposed to too many inconsistent, special-purpose languages with kludges to help them interact in the cloud. For instance, typical methodologies for cloud programming involve combinations of ASP, PHP, Flash, XML, HTML, CSS, JavaScript, Perl or Ruby, C# or Java, SQL, and even more! Volta reduces the brittleness of distributed applications by lowering the sensitivity to idiosyncrasies of multiple languages and dialects.

Another important advantage of architecture refactoring is opening up brown-field scenarios. With minimal changes we can run existing .NET code in the cloud, greatly increasing the user base of code that may have been designed only for a single tier. Volta gives us a new dimension of software reuse. Traditionally, we would endeavor to reuse bits and pieces of source code in new scenarios. Volta lets us reuse binaries in new scenarios.

In summary, Volta confers flexibility in the architecture dimension through:

• Language-independence. Write Volta code in any language that compiles into MSIL. For example, C#, VB, IronPython, etc.
• Leverage the entire .NET toolchain. Use libraries; the IDE, Intellisense, auto-complete, snippets; FxCop; profiler; class browser; ILDASM; and so on.
• Low entry barrier. Reduce your learning burden; use “only the languages in the room.”
• Brown-field applicability. Volta-enable existing applications for the cloud.
• Beyond 2 tiers. Refactor to as many tiers as you need using exactly the same mechanisms recursively applied.

Platform Retargeting: Extend the Reach

Without Volta, we must choose not only the architecture, but also the execution environment before we write code. For example, we often start with a WinForms application, confining us to client-side architecture and CLR execution.

We’ve already seen that Volta tier splitting lets us refactor the application so that part of it runs on the server. Volta retargeting lets us run MSIL code also in a JavaScript engine. Primary scenarios involve JavaScript in a browser running the client side of a distributed application. However Volta is not tethered to the browser and retargeted code runs in any JavaScript engine, such as the Jscript engine bundled with Internet Explorer.

Volta retargeting employs the technique of deep embedding, which preserves precise semantics of CLR objects, classes, methods, events, and so on, despite some rather deep impedance mismatches between the two platforms. For instance, MSIL is statically typed, whereas JavaScript is dynamically typed. Volta does all the hard work for us, though, and we are not restricted to a subset of .NET language features. Anything MSIL can do, including events, exceptions, casts, and generics, runs precisely correctly on alternative platforms. Volta’s semantic fidelity is orthogonal to tier-splitting, so, with some limitations, it’s possible to fire events and exceptions across tiers, as if they were on the same runtime instance.

Let your imagination be your guide. Retargeting is independent of refactoring and we can mix and match them as appropriate to our scenarios.

Let’s develop a simple scenario. Consider a typical web application, and focus attention on the component running in the browser. Without Volta, we write HTML, CSS, and JavaScript, targeting the browser’s execution environment, in addition to server code. With Volta, we have one programming model for both tiers, namely .NET. Volta retargets the browser component, writing the JavaScript for us from MSIL, hiding the impedance mismatch.

Retargeting is all the more important in the face of Ajax, which encourages ever more functionality in the browser for increased responsiveness and better user experiences.

In summary, Volta confers flexibility in the execution-platform dimension through:

• Deep embedding of CLR semantics. Preserve exact CLR semantics across platforms.
• Cross-browser support. Use one programming model across browsers.
• Complete orthogonality with refactoring. Mix and match refactoring and retargeting.
• Ajax-ready. Write Ajax patterns and idioms in familiar .NET languages.

Browser Remodulating: Cross-Browser Support

Despite the standardization of DHTML, which includes JavaScript and DOM access, many subtle differences exist amongst popular browsers. The rise of Ajax has amplified the differences, and furthermore, has created a sense of urgency in the marketplace, hence a continuous flow of new features and capabilities that developers must chase. Consequently, without Volta, developers must write more and more browser-specific code, leaving them less time to focus on their applications.

Volta hides as many browser-specific differences as possible, but still allows developers to leverage the unique capabilities of particular browsers. Instead of targeting solely the intersection of browser capabilities, Volta targets the entire union, but makes the intersection browser-agnostic. This is browser remodulating. From the developer’s point of view Volta attenuates browser differences. But what about testing and debugging? Volta and the Visual-Studio integration supports debugging and testing of applications with full transparency. Visual Studio’s Solution Platform dropdown lets us choose the specific browser we want for a testing/debugging session. This allows us to see how each browser renders the HTML.

In this release Volta supports the Internet Explorer and Firefox browsers. We accommodate specific browsers through a combination of changes to the recompiler and libraries, plus Visual Studio integration for debugging.

In summary, Volta confers flexibility in the execution-platform dimension through:

• Cross-browser support. Write the same code for Internet Explorer and Firefox.
• Debugging transparency. Debug code with a specific browser.
• Leverage browser-specific features. Where needed, access features unique to each browser.
• Visual-Studio integration. Enjoy seamless integration with the IDE.

Silverlight: A few thoughts on minimizing CPU usage

The first two suggestions will have the most drastic improvement on the performance of your Silverlight application, and can affect CPU usage, framerate, and application responsiveness.  

1.       IsWindowless=false is faster

Do not turn on isWindowless unless your design requires overlay of other HTML content on top of Silverlight content.

 

2.       Opaque Background is faster

Do not set a transparent channel in the Silverlight HTML control background property. Setting the background to a transparent or semi-transparent value will add tremendous cost as each render call is forced through the blending pipeline, regardless if the transparency has any visual effect. (A background of 0, transparent, #11aabbcc, etc. will cause blending)

 

If you simply want to set the control’s background property to match that of the HTML, background:document.body.style.backgroundColor will suffice.

 Note: I am referring to the background of the Silverlight HTML control. Setting an opacity on elements within your Silverlight app has relatively minimal cost. Note: if you do decide to use transparency, please make sure to test the performance on Mac:Safari. 

3.       Only offer the quality that is needed for your design.

-          Framerate: you can set the max framerate for the entire contents of the control in properties. Many websites run all animations and media at ~15fps, and most users do not notice.
Note: I set the value of the framerate property below.

-          Media: When encoding your media file, remember that the average media file on the web is roughly encoded at 320×230, with ~15fps.

4.       Test & Debug

-          Quality and performance vary on different machines, and even on different OS/browser configurations.

-          The below onLoadHandler shows how to display the framerate, for debugging purposes, in IE or Safari’s status bar. If your desired framerate is out of reach, you should set the framerate property lower so as not to peg the user’s CPU.

 

Sys.Silverlight.createObjectEx({source: “xaml/Scene.xaml”,parentElement: document.getElementById(“SilverlightControlHost”),id: “SilverlightControl”,properties: {width: “500″,height: “500″,background: “black”, //NO ALPHA =)version: “0.9″,framerate: “15”    //only as much as needed},

events: { onLoad:onLoadHandler} });

 function onLoadHandler() {/* To see the framerate displayed in the browser status bar */agControl = document.getElementById(“SilverlightControl”);agControl.settings.EnableFrameRateCounter = true;} 

Deploying ASP.NET Applications

As an ASP.NET developer, we are always focusing on learning new ideas on design and development which made us to have less knowledge on deployment of applications in production. This article targets developer community to have some of the rudimentary knowledge on deployment of ASP.NET application on IIS 6.0. After reading this article a user will be familiar in: ·         Virtual Directories and Creating it ·         Application Pools, Creating Application Pools and why it is used ·         Use of service accounts in Application Pools ·         Web.Config Settings and using Web.Config Settings for debugging errors ·         Common hindrance we may possibly face during deployment and resolutions It is assumed that the user is logged in to the server or connected to the server through Remote Desktop Connection and the user has enough permission to do the deployment.

Preparing the application for deployment

[ Back To Top ] We can use the Web Deployment plug-in for Visual studio 2005 given by Microsoft for creating Web deployment projects for 2.0 Applications, where we can compile in release mode for 1.1 applications for deployment. See the reference section for more details on Web Deployment plug-in. Copy the application to a folder location where the application needs to be deployed on the server. Make all Web.Config changes, like updating connection strings, if there is any appsettings values changes corresponding to production environments, etc. Virtual Directory An IIS Virtual Directory is essentially an alias to the physical directory. The IIS Virtual Directory is a directory name which may be accessed from the Internet to access the physical directory on the server. The most common ways of creating virtual directory is done through two methods. 1.    Using IIS Manager 2.    Using Windows Explorer Using IIS Manager We can open IIS manager in 3 ways: ·         Type Inetmgr in RUN ·         Open Control Panel > Administrative tools > Internet Information Services ·         Right click My Computer, click Manage and expand Internet Information Services Creation Doing any of the above approach will bring us the IIS manager. 1.    Expand the local computer node, right click the Website under which you want to deploy the application and click New > Virtual Directory. It will bring a dialog like Figure 1. Figure 1 – Create Virtual Directory                                                        Click Next. 2.    It will bring the next window for entering “Alias” for our websites. See Figure 2. Figure 2 – Virtual Directory Alias   Type the alias name you would like to assign for the applications virtual directory. I have used “test” for this article. Click Next. 3.    It will bring a window for linking our website’s physical directory with virtual directory. Figure 3 – Physical Directory Path Browse to the location and select the website folder. Click Next. 4.    This will bring the window for specifying access permissions for the users. Select appropriate permissions. Figure 4 – Virtual Directory Access Permission    I have not changed the default setting in this window as this permission is more than enough to run most of the applications. Click Next.       5.    Click Finish. Thus we have created the virtual directory.  Using Windows Explorer                1.    Browse to the folder location where you copied the application and right click the folder and click “Sharing and security.” 2.    Open “Web Sharing” tab and select “Share this folder” which will ask for the Alias. Type an Alias name, click OK and click OK again. We have created virtual directory through windows explorer. Configure ASP.NET version Sometimes the server we are deploying may have both 1.1 and 2.0 framework installed. So we need to configure the applications to use appropriate framework. It can be done through the ASP.NET tab of virtual directory property box like in Figure 5. Figure 5 – ASP.NET version picker If it is 2.0 Application, select 2.0.xxxxx version or else 1.1.xxxx.

Application Pools

[ Back To Top ] Application Pools or App Pools are introduced with IIS 6.0 to isolate websites into a group called Application Pools. Also we can say application pools are a group of one or more URL’s that are served by a worker process, meaning applications running in a single app pools run in the same worker process w3wp.exe, thus providing a boundary so that if one application fails it does not hinder other applications running on other app pools. So as a good practice a highly confidential, secured website can be assigned with a separate app pool. Also we can use app pools to troubleshoot applications by isolating them to a separate application pool if we suspect that it creates problem. By using an application pool, we can have specific configuration settings to a worker process that services a group of applications or single application that is running under the App Pool. For example, you can configure worker process recycling and several other configuration options to match the needs of each application. We will see this in detail in coming sections. With this introduction to Application pools we will move to our subject matter, creating Application pools in IIS 6.0. Creation A new application pool can be created using IIS Manager. Steps 1.    Open IIS Manager. 2.    Expand local computer node. Right click Application Pools node and click New> Application Pool like Figure 6. Figure 6 – Creating New Application Pool                      It will open a dialog to create new app pool. Figure 7 – Application Pool ID                             Type a Pool ID for the app pool, the best practice to give identity is choosing a name relevant to the applications hosted. For example, if the app pool hosts a Shopping cart site, let the pool identity be ShoppingCartPool so that it can be easily identified as opposed to AppPool #1, 2, etc. Under Application pool settings> select “Use default settings for new application pool,” Selecting “Use existing application pool as template” will prompt as to select an existing app pool as the template so that same setting is applied for the newly created app pool. 3.    Click OK. A new application pool is created with default configurations. Customizing Application pools By default, Application pools are configured to use Network Service Account to service the request. At times we will end in a situation where we should use a separate account for servicing the request for different reasons. There are other configuration settings which some times need to be optimized, which are really done in exceptional situations. The coming sections will answer these things and take us through accomplishing this. Steps 1.    Right click the Application pool you have created (Test Pool) in this example and click Properties. It will bring up a dialog like the one below. Figure 8 – Application Pool Property recycling tab                                            Recycling tab is opened with default settings. Periodic recycling of your application pools is recommended to help to clean up memory fragmentation, memory leaks, abandoned threads and other disorders. Keep in mind that when an application pool recycles, session state information stored in-process is lost for that pool, but other pools are not affected. ASP.NET, however, does allow you to store your session state outside the worker process, so that session information is not lost during a recycle. We can recycle the worker process based on the number of requests and memory usages. 2.    Moving to Performance tab. Refer to Figure 9. Figure 9 – Application Pool Property Performance tab                When the application does not receive a request for certain amount of time, it is said to be idle so this setting allow us to free up the occupied resource from the server after the specified time given here. Consider changing the Request queue limit if your application receives thousands request per second to mitigate Server busy messages. Most of the time Enable CPU monitoring is not used. Web garden setting should not be changed from 1, this specifies the number of worker process required to process the request for an app pool. 3.    Next, tab “Health” tab for configuring the health, i.e. the availability of the application can be configured. Refer to Figure 10. Figure 10 – Application Pool Property Health tab        Enable pinging causes IIS to automatically query a worker process to see if it is responsive and utilizing network bandwidth. Enable rapid-fail protection helps to disable the app pool for specified number of failures occurred in the worker process. Startup time limit and shutdown time limit are self explanatory and failing to satisfy those condition falls under failure for rapid fail protection. 4.    The “Identity” tab is where we can configure the worker process identity. Figure 11 – Application Pool Property Identity tab   The predefined setting’s default is to use network service account which is a less privileged account for security purposes. The other account that can be preconfigured is Local Service and LocalSystem account. Before making the App pool to use custom account known as Service accounts, we will explore what and why it is used. Service Accounts It is the identity of the App pool under which it services the request. It is the account that has very less privileges on the machine so as to reduce the security risk and loop holes. There can be several reasons to opt for custom service account over the Network service account. Some of the reasons are: ·         We can have different access controls for different applications on the local and network resources such as fileservers, etc. ·         It is also a mode of isolating one application from another by giving a separate identity so other applications cannot access the resource of another application. ·         We can prevent any accidental or deliberate changes to the access controls or permissions associated with the general purpose Network Service account from affecting your application. See reference section for creating new service accounts. One think to note here is if our site uses a database then make sure that the custom service account has the required access to the database. Configuring Custom service account with Application Pool In the above Figure select Configurable> type the service account id, password and enter. It will ask for password confirmation like the figure below. Click OK. Figure 12 – Configure service account After doing this restart the App pool by stopping and starting it again. Associating Site with Application Pool We need to associate our site with the App pool we created. It can be done by right clicking the site’s virtual directory (Test in our case) and property. Select the TestPool from Application pool drop down in “Home Directory” tab as in Figure 13. Click Apply and OK. Figure 13 – Associating site with Application Pool   We are at the end of the process and we need to do a smoke test for the application verification.

Possible Errors

[ Back To Top ] Error Service unavailable Resolution This is one of the ever green errors we often used to get mostly because of service accounts. The common problem will be this account might not be a member of IIS_WPG group on the server or check IIS_WPG group have Read & Execute, List Folder Contents, and Read permissions to the Web site directories. So precheck with a network admin who is creating the service account for you whether the account has all the required permissions on the server. Error An error has occurred while establishing a connection to the server. When connecting to SQL Server 2005, this failure may be caused by the fact that under the default settings SQL Server does not allow remote connections. (Provider: TCP Provider, error: 0 – A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.) Resolution Again, there may be several reasons, the most common is checking if the service account has access to the SQL Server. This error occurs even if you are not using SQL Server 2005, i.e. the same error occurs even if you use SQL Server 2000. Similar error occurs if there is any problem in the connection string too. Error It is not possible to run different versions of ASP.NET in the same IIS process. Please use the IIS Administration Tool to reconfigure your server to run the application in a separate process. Resolution When we host multiple versions of ASP.net in a single server, we may get this error in event log. The problem might be an application pool will be associated with 2 different applications that use different frameworks. So isolating this application into a different App Pools will solve the problem.

Points to note

[ Back To Top ] This section highlights some of the important things to consider when we are deploying the application. 1.    Make sure the Web.Config setting is perfect, such as connection strings, App setting values, check <compilation debug=”false”/> because setting it to true causes the application to be processed slow, memory consumption is more, scripts and images downloaded from the WebResources.axd handler are not cached. 2.    To trouble shoot the error if it occurred use <CustomErrors> section in Web.Config and make sure you are reverting back to the original settings. 3.    If we are running multiple versions of ASP.net on the same webserver do not use aspnet_regiis utility with –i switch to register the ASP.net with the IIS, instead use –s switch and register it for the particular site because using –i switch is going to update the entire IIS with the current version of ASP.net you are registering leaving the existing application configuration affected. For example, Aspnet_regiis –s W3SVC/1/ROOT/Test. 4.    By default, IIS does not allow dynamic contents like ASP\ASP.NET to be processed by IIS. So to allow this, Open IIS manager, click Web Service Extensions and Allow the Web Service Extensions if it is disabled as shown in Figure 14. If there is no extensions for processing ASP.net 2.0 application, we can add a new web service extension by clicking “Add a new Web service extension” link. Read more on MSDN on how to add web service extensions in IIS 6.0. Figure 14 – Web service Extensions

References

[ Back To Top ] Visual Studio 2005 Web Deployment Projects How To: Create a Service Account for an ASP.NET 2.0 Application Microsoft Support center

Taifiti

Tafiti, which means “do research” in Swahili, is an experimental search front-end from Microsoft, designed to help people use the Web for research projects that span multiple search queries and sessions by helping visualize, store, and share research results. Tafiti uses both Microsoft Silverlight and Live Search to explore the intersection of richer experiences on the Web and the increasing specialization of search.

The shelf is located on the right side of the screen and provides a place to store associated search results, such as the things you want to retain from a particular query or set of queries. Multiple results of different types can be stored on the shelf. There are five shelves and the contents of a single shelf constitute a “stack”. You must be signed in to store items in the shelf from session to session.

• Putting things on the shelf – Search results can be dragged from the results pane to the shelf.
• Labeling a stack – hover over a particular shelf and click to type a label on the text box which appears.
• Seeing the contents of a stack – click on a particular stack (outside the label area) to see all the contents displayed in the Stack View.
• Delete individual items – hover over an item and click the red Remove button which will appear.
• Send a stack to someone else via email – click on the link at the top of the Stack view.
• Post a stack to your Windows Live Space – click on the link at the top of the Stack view.
• Clear a single stack on the shelf – click on the white X that appears when you hover over a particular stack.

Clicking on the Tree View link will provide a tree-based visualization of your web search results.

This tree visualization slowly cycles through and displays all the results for your query.

You can adjust how many results are show using the slider bar located beneath the tree.

You can return to the main result window by pressing the ESC key or by clicking on the star in the top right of the screen.

Yes. In book results, click on the cover of the book that you’re interested in to display content from that book.

For performing searches and taking advantage of the visualization capabilities in Tafiti, a LiveID is not required.

However, if you would like to save items on shelves for future reference, you will need to sign in with a LiveID. The LiveID is used to identify the owner of a shelf and make it available to you on your next session – even if you are on a different computer.

Tafiti is a Silverlight application and supports all currently supported platforms for that technology.

On Windows Vista and Windows XP SP2, this includes Microsoft Internet Explorer 6, Windows Internet Explorer 7, Mozilla Firefox 1.5.0.8, and Firefox 2.0.x.

On Apple Mac OS X this includes Firefox 1.5.0.8, Firefox 2.0.x, and Apple Safari 2.0.4.

Yes. When clicking on an item for your search results, Tafiti displays this in a separate window. If you have pop up blocking turned on in your browser, your browser provides an option that named “always accept popups only from this site’. Select that option and you will not see this message in future.

No. If you see this error, it is because you have cookies turned off in Firefox. You can change this by performing the following steps:

• Click on the Tools item in the menu bar
• Click on the Options item in the Tools menu
• Click on the Privacy Tab
• Click on the ‘Accept cookies from sites’ checkbox
• In the ‘Keep Until’ drop down box, select the option you prefer.

If you refresh the page, you will be delivered to the Tafiti website.

This is because Safari on the Macintosh does not recognize the issuer of the certificate used on Tafiti. This is primarily a cosmetic issue, and will be corrected in an upcoming beta release. Alternatively, if you use the Firefox browser on Macintosh you will not see this issue.

Tafiti uses Silverlight 1.0 RC and AJAX to provide rich, cross-platform user experiences and leverages the following Microsoft services on the backend:

• Live Search for Web, Books, Blogs, News, and Images
• Live ID
• Live Spaces

Silverlight Hello World in C# from VS 2005

In VS2005 you can create a class library which will build against the Silverlight runtime, but it’s a little work.

1. Create a Class Library.
2. Remove all references from it.
3. Right-click on the Project and pick Properties.
4. On the Build tab, click Advanced and check ‘Do not reference mscorlib.dll’
5. Manually add references to mscorlib, agclr, System, System.Core, System.Silverlight, and System.Xml.Core from the Silverlight install folder (\Program Files\Microsoft Silverlight\)

At this point your build outputs should be Silverlight consumable binaries. It looks like the equivalent command line call to csc.exe (the C# compiler) should include the references to the mentioned binaries and the /nostdlib option but may require others as well.