I will be presenting two sessions -

Microsoft Azure Offerings for Web Developers
This session will focus on what Microsoft Azure offers to web developers. We'll focus on Azure website capabilities, including how Azure makes it easy to build scalable, real-world web applications. We'll also touch on Azure Web Role and Azure virtual machine capabilities. Last, we'll talk about helper services that provide a compelling platform for web apps on Azure, such as Azure Cache, Traffic Manager, Content Delivery Network, and Active Directory. This introductory session will cover the breadth of Azure offerings.

Microsoft Azure Redis Cache
Microsoft Azure Redis Cache is a dedicated cache service based on the open-source Redis Cache engine. In this session we'll introduce users to Redis and the features it offers. We'll discuss the architecture of the Azure Redis Cache service and delve into the capabilities it offers in addition to basic Redis hosting. We'll also review end-to-end real-world scenarios leveraging Redis Cache in conjunction with other Azure services.

Looking forward to it.

Microsoft Azure Redis Cache is a secure, dedicated cache service from Microsoft, based on the OSS Redis Cache engine. In this session we will firstly introduce users to Redis and the features it offers. Next we will talk about the architecture of the Azure Redis Cache Service and dwell into the capabilities that it offers in addition to basic Redis hosting. Lastly, we will review end to end real world scenarios leveraging Redis Cache in conjunction with other Azure services.

Learn How to Easily Move Your ASP.NET Application to the Cloud with Microsoft Azure

You’ve got lots of ASP.NET applications running in-house or at a host, but when it comes time to move those apps to the cloud, there are some architectural things to consider to ensure your app scales. Join us for this practical walkthrough that covers all the things you need to know to scale your existing ASP.NET app to the cloud.

For those not at the conference, I believe video recordings of the talks will be available online.

Original Post::

Today at MIX ‘10 we announced the public availability of WCF RIA Services RC bits.

A few months back, at PDC ‘09 when we released our Beta bits we received strong feedback around making deployment of RIA Services applications easier and asking for more guidance around deployment scenarios.

With our latest RC bits we believe that we now do have an intuitive deployment story and I cover it in some depth in the blog post below.

In this blog I talk about Deployment Scenarios for RIA Services RC bits that only support Dev 10/.NET 4/SL 4.

I do realize a set of folks are still consuming RIA Services Beta bits that only support VS 2008/.NET 3.5/SL 3, primarily because those are ‘Go Live’ bits. For those folks I will be posting a separate blog soon focusing primarily on deployment using the Beta bits.

Configuring the Deployment Server

You have your application ready and it works great on your development machine. Now you want to deploy it to a server and share the awesomeness …

The first thing you will need is a server with .NET 4 RC installed. If the server has RIA services installed as well, even better.

Shared Hosters: 

We have worked with our partner hosters and have the following hosters supporting both .NET 4 RC and RIA Services RC today …

• DiscountASP
• OrcsWeb
• ASPHostCentral 

NOTE - ASPHostCentral has a set of some blog posts here [1, 2, 3] to help you with you RIA Services Deployment as well.

In House Servers:

If you are setting up an in house server, you can download .NET 4 RC from here. 

To install RIA Service RC on your server, download the MSI locally from here and then run it as such -

msiexec /i RIAServices.msi /SERVER=true

More details on this option are in Deepesh’s blog here.

BIN Deployment:

If you have access to a .NET 4 RC server but do not have permissions to install RIA Services on it, you can choose to carry the RIA Services bits in the Web Applications BIN folder.

If you are using the Visual Studio Build->Publish option to deploy your application, make sure the following three assemblies under the Web Application->References have been marked as Copy Local = True

If you are copying the bits over manually to your deployment server, copy the above three assemblies to the Web Applications BIN folder right next to your [WebAppName].dll

Deploying LINQtoSQL Applications:

Starting with RIA Services RC, the RIA Services LINQtoSQL Provider has been moved to the RIA Services Toolkit.

If you have are deploying an application that uses L2S you will need to either manually deploy the Microsoft.ServiceModel.DomainServices.LinqToSql assembly in your servers GlobalAssemblyCache or make sure it is copied to the Web Apps BIN folder.

Azure Support:

Since RIA Services RC bits only support .NET 4 while Azure currently only support .NET 3.5, it is not possible to deploy a RIA Services RC application to Azure.

We are working closely with the Azure team to bring .NET 4 support to Azure.

Configuring IIS

RIA Services supports IIS6/IIS7 deployments.

However WCF (and by association RIA Services) has a limitation that it does not support MultipleAuthenticationSchemas enabled in IIS.

So if you are using Forms Authentication in your application (if you built your application using the Business Application template, Forms Auth is the default there) you need to make sure that for the IIS VirtualRoot that hosts your WebApp Forms Auth is enabled. Forms Auth + Anonymous will also work fine but Forms Auth + Integrated Auth is not supported.

Similarly if you are using Windows Authentication in your application (for a default Web Application no Authentication Mode is specified in the Web Config and the default Authentication Mode  is Windows) you need to make sure that for your WebApp only Integrated Auth enabled.

If you do not have access to your servers IIS settings (most hosters will give you an option to choose the Authentication Mode for your Web Application) you will need to work with your Server Administrator to get those changed.

I talk later about detecting whether IIS is configured correctly for your Web application.

Deploying the Application

Once you have the deployment server set up, RIA Services installed or Bin Deployed and IIS configured, deploying the application is as simple as copying the bits over. 

A typical Web Application hosting a Silverlight Application will look something like this -

The ClientBin folder contains the .xap, while the Bin folder contains the [WebAppName].dll + any bin copied assemblies.

If everything is in place, browsing to the .aspx should download and launch the Silverlight Application. 

If you do not see the Silverlight Application being downloaded successfully when you browse to your web site, it is most likely because your ASP.NET server or  IIS have not been configured correctly. In this blog I do not dwell on debugging Silverlight deployment issues, there is lot of good material available on that online.

However if you can download the Silverlight Application fine but your calls to the DomainService are failing, then it is a RIA Services deployment issue. Below I talk in more detail about trouble shooting such failures …

Troubleshooting Deployment Issues

The flow chart below shows the various platform involved in data or error information successfully making it down from a DomainService to the Silverlight Client.

CustomErrors:

Exceptions thrown at the DomainServices layer make it down to the Silverlight client and if unhandled show up as client exceptions.

If the Web App’s web.config has Custom Errors enabled (the default is Off), then the exceptions will typically contain enough information to help the user debug the exception.

<customErrors mode="On"/>

Since the application worked fine in the development environment and is failing on deployment, the failure typically has to do with the Server environment not being setup correctly. For example, connection string mismatch between development and deployment environments is a common cause of failures.

404/NotFound:

Unfortunately any exception thrown in the RIA Service Host or anywhere lower in the pipeline (WCF/ASP.NET/IIS) all show up in Silverlight as 404/NotFound.

Option #1 - To get to the actual error information an Http diagnostic tool is need. Fiddler is a popular option. It gives you access to the to the Http response body where the actual error information is available.

Option #2 - Not being able to get the error information in Silverlight is a limitation of the Silverlight’s Browser Networking Stack which RIA Services uses internally.

Another option to get to the error info for debugging is to temporarily get your application to use the Silverlight Client Networking Stack. To do so, all you need to do is add the following line of code to your SL Application. It will force all http web request to go via the Client Networking Stack and thus make the error code available on the Client.

WebRequest.RegisterPrefix("https://", 
  WebRequestCreator.ClientHttp);

In case you were wondering – There are certain limitations to using Client networking stack (especially around authentication support) and hence RIA services does not use it as its default networking stack.

If using Fiddler or the Client stack you are still seeing a 404 response, then that really is the error code the server is returning. We then need to move to the next stage of troubleshooting.

Browsing to the .SVC

For every DomainService, a WCF Service is created at runtime using the ASP.NET feature of Virtual Path Providers. More details on the dynamic .SVC file creation can be found in my blog post here.

Since it is a virtual file you will not see a physical .svc in your deployed project, but it will exist at runtime. Being able to browse to the .SVC can be key to debugging RIA Services deployment issues.

For a given DomainService the path to its .SVC can be determined using the following convention:

[BaseURI] + [DomainServiceNameWithNamespace].svc with all “.” in the DomainServiceFullName replaced by “-“

So HRApp.Web.OrganizationService deployed the domain https://www.RIAServicesApps.com will be exposed as – https://www.RIAServicesApps.com/HRApp-Web-OrganizationService.svc

If everything is setup correctly you will see a default WCF Service page, else you will see an error message telling you what is wrong.

If you get a 404 on browsing to the .SVC, the DomainService was not setup correctly

One common cause for this issue is missing sections in the Web config.

At development time when a DomainService is added to a project using the DomainService Wizard, the right Web Config entries are automatically made by the Wizard. However these entries sometimes get lost at deployment time, especially if the Web Config has to manually be merged for deployment.

Below are the Web Config sections need by RIA Services -

<configuration>
    <system.webServer>
        <modules runAllManagedModulesForAllRequests="true">
            <add name="DomainServiceModule" preCondition="managedHandler"
type="System.ServiceModel.DomainServices.Hosting.DomainServiceHttpModule, System.ServiceModel.DomainServices.Hosting, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
        </modules>
        <validation validateIntegratedModeConfiguration="false" />
    </system.webServer>
    <system.web>
        <httpModules>
            <add name="DomainServiceModule" 
type="System.ServiceModel.DomainServices.Hosting.DomainServiceHttpModule, System.ServiceModel.DomainServices.Hosting, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
        </httpModules>
        <compilation debug="true" targetFramework="4.0" />
    </system.web>

    <system.serviceModel>
        <serviceHostingEnvironment aspNetCompatibilityEnabled="true"
            multipleSiteBindingsEnabled="true" />
    </system.serviceModel>
</configuration>

If browsing to the .SVC succeeds just fine but communicating with the Domain Service from within the Silverlight Application returns a 404 response code, then most likely your DomainSerivce at runtime is running into an exception in the WCF stack. In the data/error Flow diagram at the beginning of this section I represent these exceptions with the dark blue box.

WCF Exceptions

Hitting exceptions in the WCF stack is rare for RIA Services applications.

One known cause is that you might be hitting the default WCF quota for Maximum number of nodes in a de-serialized graph - 'Maximum number of items that can be serialized or deserialized in an object graph is 65536'. If you are indeed inadvertently sending large amounts of data consider constraining it  

Another cause could be that RIA Services is running into an exception trying to (de)serialize your Object Graph, though this is very uncommon.

The only option to get to the bottom of these sort of issues is to enable WCF tracing in your Web Site. 

In Conclusion

Hopefully the deployment and troubleshooting information above will help you successfully deploy your RIA Services Application. Please do you the comments section to provide feedback or for items not addressed by this blog post.

In this post I plan to talk briefly about the motivation behind aligning RIA Services with WCF and then dig deep into how exactly RIA Services consumes WCF.

RIA Services on WCF: Best of both worlds

Ever since we announced RIA Services at MIX '09, we have heard strong customers feedback that they would like a consolidated services story from Microsoft. Acting on that feedback, over the last few months RIA Services has spent a significant amount of effort aligning closely with WCF. The Data Services team at their end has been working on a similar alignment with WCF as well.

By centering all our service offerings around WCF we are maximizing developer knowledge transfer and skill reuse, both in the short and the long term.

For more details on the alignment and the motivation behind it please also check out this post by the WCF team.

I strongly believe that with WCF RIA Services our users get the best of both worlds -

• They get all the simplicity and productivity of the RIA Services Prescriptive Programming Model and Tooling
• And if need be, they can dig deep into our services infrastructure and harness all the power and flexibility that WCF has to offer  

Understanding RIA Services use of WCF

To help users better understand how RIA Services uses WCF, in the following section I walkthrough what happens under the covers when a user creates a simple DomainService and then communicated with it.

1. ‘Add new DomainService Class’

Lets assume an application developer opens up the ‘Add new Domain Service Class’ item template and adds a new Domain Service.

The item template, besides producing a skeletal Domain Service Class, adds the right assembly references and registers an Http modules in the Web.Config. By default it registers an httpModule for Cassini (for Visual Studio F5 experience) and one for IIS, as shown below.

<?xml version="1.0"?>

<configuration>

  <system.web>

    <httpModules>

      <add name="DomainServiceModule" 

type="System.Web.Ria.Services.DomainServiceHttpModule, 

System.Web.Ria" />

    </httpModules>

    <compilation debug="true" targetFramework="4.0" /> 

  </system.web>

  <system.webServer>

    <validation validateIntegratedModeConfiguration="false"/>

    <modules runAllManagedModulesForAllRequests="true">

      <add name="DomainServiceModule" preCondition="managedHandler"

type="System.Web.Ria.Services.DomainServiceHttpModule, 

System.Web.Ria" />

    </modules>

    <validation validateIntegratedModeConfiguration="false" />

  </system.webServer>

2. Domain Service Code

The developer then goes ahead and adds Business logic to his DomainService.The methods exposed via the DomainService can be broken into two broad categories –

CRUD operations – Query, Update, Named Update and Delete operations. These operations follow the RIA Services prescriptive guideline and rely on the RIA Services framework. This is added functionality that RIA Services introduces on top of WCF and is not available to Core WCF Services.

Service Operation/ Invoke Operations - These are [Invoke] operation in the RIA Services terminology and Service Operations in WCF terminology. These methods are independent of the RIA Services concept of ChangeSet (ChangeSet applies only to the CRUD operations above) and are ‘Online/Direct’ methods that communicate with the Server immediately when invoked.

Below is the code for the OrganizationService DomainService we use in our canonical RIA Services walkthrough.

namespace HRApp.Web

{

    [EnableClientAccess()]

    public class OrganizationService : 

        LinqToEntitiesDomainService<AdventureWorks_DataEntities>

    {

        #region CRUD    

        public IQueryable<Employee> GetEmployee(){…}        

        public void InsertEmployee(Employee employee) {…}        

        public void UpdateEmployee(Employee currentEmployee) {…}        

        public void DeleteEmployee(Employee employee) {…}

        public IQueryable<Employee> GetSalariedEmployee(){…}

        [RequiresAuthentication()]

        public void ApproveSabbatical(Employee current) {…}   

        #endregion

       #region ServiceOperations

        public string Echo(string msg) {…}

        public DateTime GetServerDateTime(){…}

       #endregion

    }

}

3. WCF Channel on Client

The RIA Services Framework on the Client contains a WebDomainClient:DomainClient whose purpose is to help the SL client communicate with a WCF service represention of the Domain Service. The WebomainClient uses a WCF Client Chanel for this cummunication.

The Channel is created by using WCF’s ChannelFactory and by passing to it a WCF Service Contract that was generated from the Domain Service (more on the contract creation later). The ChanelFactory creates a WCF client proxy based on the supplied contract. The generated proxy takes care of communication/(de)serialization between Client and Server.

The RIA Services DomainContext utilizes the WebDomainClient for Client-Server communication and the context itself is WCF agnostic.

4. Dynamic .SVC generation

By default DomainServices do not have a physical .SVC file generated for them at Design Time.

However each DomainService has a virtual .SVC associated with it. The .SVC represents the WCF Service that services requests for that particular DomainService. For a given DomainService the path to its .SVC can be determined using the following convention:

[SilverlightApplicationBaseURI] + [DomainServiceFullName].svc (With all “.” replaced by “-“)

So HRApp.Web.OrganizationService is exposed as – https://[ApplicationBaseURI]/HRApp-Web-OrganizationService.svc

At RunTime when the first request (within a particular Application Domain) is made for a DomainService's .SVC file , the registered httpModules intercept the call and RIA Services writes out an in memory .SVC file on the fly.

Below is what the dynamically generated svc file looks like for the OrganizationService defined above -

<%@ ServiceHost Service=”HRApp.Web.OrganizationService” 

Factory=”System.Web.Ria.DomainServiceHostFactory”

%>

The .SVC refers to the DomainService Type and a ServiceHostFactory. The default RIA Services  HostFactory instantiates the default RIA Services ServiceHost, which in turn is responsible for extracting the WCF Service Contract from the DomainService (See the ‘Generating a WCF Contract’ paragraph below for more details) and also for hosting the service.

A request for the DomainService .SVC in any folder under the Web Application root is redirected to [WebAppRoot]/Services/[DomainService].svc using ASP.net URL rewriting. The service is thus accessible under any folder in the WebApp. Hence even if a .XAP is moved around under the hosting Web App Root, the Silverlight App's relative reference to the DomainService is not broken. 

NOTE - If a physical .svc file with the right file name (as per convention) is present in the ~/Services folder, that is used to define the Service Contract and no virtual .SVC file is generated.

5. Generating the WCF Contract:

Each WCF service needs to have a ServiceDescription and one or more ContractDescriptions for it.

ServiceHosts are responsible for extracting descriptions from a service and hosting the service. The standard ServiceHost in WCF produces descriptions based on WCF attributes such as [ServiceContract] and [OperationContract]. In RIA Services we provide a custom ServiceHost which does this based on a RIA Service Attributes and Conventions.

Here is how DomainService operations are mapped to the WCF Contract:

Query operations –

Each Query operation shows up as a ServiceOperation in the WCF Contract, but with its signature modified.

The ServiceHost creates an operation description for each query operation. The return type is changed to QueryResult<T> such that it can return additional information such as count. It also adds a QueryOperationBehavior which through a custom operation Invoker takes care of applying cache policies, validating parameters and composing queries.

Insert, Update, Delete operations –

For all CUD operations the ServiceHost generates one top-level SubmitChanges operation description. Again, it adds a custom behavior which injects a custom operation invoker. The signature of SubmitChanges is ChangeSet SubmitChanges(ChangeSet changeSet). The returned ChangeSet contains auto-generated values from the server.

Invoke Operations –

Invoke Operations are the RIA Services equivalent of WCF ServiceOperations. All Invoke Operations show up in the WCF Contract as Service Operations.

For the OrganizationService Domain Service we had defined earlier, below is what the WCF Contract looks like to the “Add Service Reference” dialog -

Attached to this post is also the full generated WCF Contract for the OrganizationService (the file was produced by doing an Add Service Reference to the Domain Service's WCF endpoint)

6. Default Endpoints:

The RIA Services ServiceHost creates the following endpoints by default - 

a) For Silverlight Client: SOAP w/binary endpoint. Address = “binary”, Binding = CustomBinding consisting of HttpTransportBindingElement and BinaryMessageEncodingBindingElement.

b) For AJAX Client: JSON REST endpoint. Address = “”, Binding = WebHttpBinding w/JSON as the format.

c) For other clients : SOAP w/XML endpoint. Address = “soap”, Binding = BasicHttpBinding consisting of HttpTransportBindingElement and TextMessageEncodingBindingElement.

The blog post here describes how one can consume the SOAP XML endpoint in a WindowsForms application. Here is a Sample of the same endpoint being consumed in a WPF application.

Summary

Above we discussed in some detail how RIA Services uses WCF under the covers. Hopefully this helps folks better understand the RIA Services alignment with WCF.

In a future post I  plan to discuss how WCF extensibility (e.g. custom behaviors) can be applied to Domain Services. In the meanwhile here is a Sample that demos this.

Add Service Reference Generated WCF Contract .cs

Brad Abrams does a great job on his blog of answering the obvious question you might have - What is .NET RIA Services?. Also be sure to check out his session at MIX on the same topic.

Nikhil Kothari presented a great session on .NET RIA Services at MIX as well.

A good resource for getting started with RIA Services is this wakthrough that guides you through building your first Silverlight RIA Services Application. Once you are ready to dig deeper into individual feature areas, this doc should help with that. If like me you learn by stepping through working code, you will find the sample applications here helpful.

As with any preview release feedback is welcome and greatly appreciated.

 .NET Framework 3.5 - Client Application Services

In .NET Framework 3.5, ASP.NET provides built in Web Application Services that provide access to features such as forms authentication, roles, and profile properties. These services provide building blocks to enable super-common scenarios and as a result can provide significant productivity wins and time-savings for developers.

The Client Application Services feature enables the Client developers to seamlessly leverage these Web Application Services from within their Client Applications. The feature also supports Occasionally Connect scenarios, enabling connected client applications to continue working even on loss of connectivity.

Consider the following scenario facilitated by this feature …

An enterprise leverages .NET 3.5 and exposes Authentication, Roles and Profile Application Services from their existing web servers. The enterprise has a mixture of Ajax, Silverlight and Rich Client applications, all of which are used by a typical employee on daily basis. The employee can now use one set of credentials to logon to all these applications and any preferences/settings modified at one location are reflects for all applications.  When the employee is away from the corporate network, say on a flight, she can still continues to use her Client Application by logging on in the offline mode using the same credentials. Also, say an employee gets promoted to be a manager, all the enterprise needs to do is add her to the manager role on the server and now managerial data is available to her across all her web and client applications.

The heavy lifting involved in enabling the scenario above today lies in the underlying plumbing code; With Client Application Services in .NET 3.5 this plumbing is now taken care of by the framework itself, significantly boosting developer productivity.

Let’s walk through a scenario and see how easy it is to now add Web Settings support to your application - 

Part 1: Create the web site –

1. In Orcas Beta2, Create a new ASP.NET Web Application

2. Set the authentication mode to Windows Authentication

<authentication mode="windows"/>

3. Fill in the profile section of the web.config. 

<profile enabled="true">

<properties>

<add name="Text" type="string" readOnly="false" defaultValue="DefaultText" serializeAs="String" allowAnonymous="false"/>

<add name="Color" type="string" readOnly="false" defaultValue="white" serializeAs="String" allowAnonymous="false" />

</properties>

</profile>

4. Enable this property to be accessed via web services by adding this section to Web Config

<system.web.extensions>

<scripting>

                                <webServices>

<profileService enabled="true" readAccessProperties="Text, Color" writeAccessProperties="Text, Color"/>

Part 2: Create the Client Application –

1. Right click on the solution and add a new project (works the same for WPF or WinForms)

2. Right click on the new client project and select properties

3. In the Services tab, enable application services, select windows auth and fill in the services url for the Web Settings Service. For now it is the development server URL, in production this would be your ASP.NET web site.

4. In the settings tab, click on “Load Web Settings” ... this will pull down all the metadata for the profile properties defined on the server for the Windows User you are currently working as. ( If you were using Forms Authentication in your Application you would be prompted by the designer to enter you Forms Credentials before being able to download the settings meta data)

We are now ready to go!  We can have strongly typed, async read-write access to your Web settings.  These settings will stay in sync no matter where you change them (WinForms/WPF/Asp.Net/AJAX/Silverlight Application), they are reflected everywhere!

Examples:

Windows Forms code –

private void Form1_Load(object sender, EventArgs e)

        {

            BackColor = Color.FromName(Properties.Settings.Default.Color);

        }

        private void button1_Click(object sender, EventArgs e)

        {

            Properties.Settings.Default.Color = this.textBox1.Text;  

            BackColor = Color.FromName(Properties.Settings.Default.Color);

            Properties.Settings.Default.Save();

        }

ASP.NET Server side code –

function loadColor()

                {                             

                                Sys.Services.ProfileService.load(["Color"], loadCompleteCallback, loadSaveFailed, "");                                  

                }

                function btnSaveColor()

                {

                                Sys.Services.ProfileService.properties["Color"] = document.form1.theColor.value;

                                Sys.Services.ProfileService.save(null, saveCompleteCallback, loadSaveFailed, "");

                }

Source Code:

The attached sample code contains the above Client scenario enabled with additional Forms Authentication (Login/Logout), Roles and Offline support.

It also contains a Web Site with using the same Authentication and Profile service.

Additional Resources:

Web Application Services Overview …

https://msdn2.microsoft.com/en-us/library/bb547119(VS.90).aspx#Examples

Client Application Services Overview …

https://msdn2.microsoft.com/en-us/library/bb384339(VS.90).aspx

Client Application Services end to end walkthrough …

https://blogs.msdn.com/winformsue/archive/2007/05/20/client-application-services-in-windows-forms-end-to-end-walkthrough-available.aspx

ClientApplicationServices - Sample.zip

Building Rich Internet Application using Microsoft Silverlight 2.0
In this session, we will build a Video Search Web Site using Silverlight 2.0. The session will demo – how to use Visual Studio to create a Sliverlight applications, how to create UI using XAML markup and code, how to retrieve data from a web service, how to manipulate  data with XML and LINQ, how to persist user settings using local storage, how to interact with browser using HTML DOM, how to use the SL OpenFile dialog etc …

Attached are the Source code/Presentaion/DemoScript for the talk .

Guthrie’s Silverlight Tips, Tricks, Tutorials and Links Page are available here. 

The MIX sessions I referred to are available online here.  

In particular, the talk above was modeled after Joe Stegman and Mike Harsh's MIX 08 session of the same name, the code for which is availabe here.

The UX Skin that I demoed was created by Corrina and she has bloged about it here.

The page demoing the Silverlight 2 Beta 1 controls is available here

Enjoy !!!

VS Live - Upload.zip

The App I plan to build on stage is the same one Joe Stegman and Mike Harsh built during their MIX 08 session of the same name, and the code for which is availabe here.

AvanadeSLTalk.pptx

VMS311: Smart Clients: What's New in Visual Studio "Orcas"?
Saurabh Pant
Visual Studio "Orcas" is about making the rapid application development experience even easier. In this overview we will introduce new features that allow Smart Clients to go where they never have before: including Occasionally Connected Systems, SQL Server Compact Edition, Client App Services, N-Tier Data, ClickOnce Deployment enhancements, as well as out-of-the-box ways to future proof your existing applications: including Windows Forms / WPF Integration, and Vista enhancements. Add to that the designer productivity enhancements and see an exciting new wave of smart client development.  

If you were at the session the side deck is attached to this post as promised.

As always feedback/thoughts are welcome. Feel free to contact me through this blog is you would like additional information on any of the technologies discussed. 

NewInOrcas_DevConn07.pptx

My introductory post to Client Application Services is available here https://blogs.msdn.com/saurabh/archive/2008/05/16/net-framework-3-5-client-application-services.aspx 

[Original Post] 

Continuing further along in with our "Live from Redmond" series I shall be presenting the following talk on Nov 27th ...

Have attached the slide deck from the talk. The actual presentation can be viewed online at any time through the registration link below.

Live From Redmond: Client Application Services in Orcas   

27th Nov 2006 [Click here to register] 

ClientApplicationServices MSDN Talk.ppt