To keep track of Silverlight resources and solutions, I created a new web site called www.silverlightkb.com.  I am also going to present at Socal Code Camp on developing line of business applications with Silverlight 2.

Silverlight 2 Release Candidiate is a developer-only release.

The official information can be found here. One the page, we can download the RC0 SDK and Tools for VS2008 SP1. It does not work with Expression Blend 2.5 Preview any more. Instead, it works with Expression Blend 2.0 + sp1 preview.

The RC0 offline document can be downloaded here.

The Silverlight Unit Testing framework has been updated for RC0 and can be downloaded here. Detail information can be found here. As for today, the Visual Studio 2008 Silverlight Unit Testing Project Template has not been updated, it works fine if you follow the option 1 path in this Jeff Wilcox's post.

There isn't a RC0 version of Deep Zoom Composer. Instead, we just need an updated project template.

Some projects are already porting to RC0, for example:

Siverlight multi-file uploader.

ExpandoHeaderControl.

There is an interesting form layout tool called XAML Power Toys and it supports RC0. 

Subscribe my Silverlight 2 Newsletter and get updated daily!

When develping a large UI project, Composite Application Guidance is a great framework for breaking large pieces into smaller chuncks using model-view-presenter pattern so that multiple developers can work on it at the same time. However, the current Composite Application Guidance for WPF, Prism 1.0, does not support Silverlight. Luckily, Prism 2.0 is on the work so hopefully we will see Composite UI for Silverlight soon.

Silverlight 2 could be an interesting platform for business applications. It comes with a set of VB like controls, yet it could be deployed like a web application. The silverlight 2 runtime is only 3.5 MB, yet it supports C#/VB language and client-side library with good set of functionalities, includding LINQ and web service communication library.

A Silverlight 2 business application would typically communicate with back-end via web service calls. Interestingly, .NET 3.5 sp1 also comes with ADO.NET data service that allows us quickly turn database into a web service. The following are the resources, from the front-end to the back end, that allows us to construct application using architecture:

Silverlight 2 control demo Download

Using ASP.NET authentication in Web Service with Silverlight

Accessing ASP.NET membership, role and profile from Silverlight

ADO.NET Entity Framework and ADO.NET Data Service Framework

The following are additional resources that allows us to create rich applications:

Silverlight Rich TextBox

Silverlight and Virtual Earth and Album Atlas (Created with VIEWS)

Silverlight File Browser and Upload and Silverlgiht File Uploader

Unit Testing: Silverlight unit testing, Silverlight NUnit

Dependency injection or IOC: SLUnity, Bloom, ninject

Model view presenter framework: MVC#

AOP for Silverlight: PostSharp

Lastly, there is an MSDN casts on this subject by Shawn Wildermuth. I would also recommend Shawn's blog.

Today, The ASP.NET MVP NewsLetter at blognewschannel.com brought me attention to PInvoke Interop Assistant at http://www.codeplex.com/clrinterop/Release/ProjectReleases.aspx?ReleaseId=14120. It is a valuable tool.

The WebRequest class in .Net 2.0 uses IE connection settings by default. So if the IE is already setup with proxy settings, WebRequest will use it. The only thing that WebRequest does not do automatically is to authenticate with the proxy server. The following code will use the local network credential to authenticate with proxy server:

It is relatively easy to create ASMX web services from WSDL, it has not been so easy with WCF. With ASMX, we can use wsdl command to create the both client-side proxy and server-side template, we can only create client-side proxy with svcutil in WCF.

Microsoft Web Service Software Factory (WSSF) for VS 2005 does allow WSDL-first approach. Unfortunately, Microsoft has removed the feature in the Feb 2008 release of the WSSF Modeling edition. The WSSF 2005 does not work with VS 2008. When I import a VS 2005 project into VS 2008, I lost the Guidance. If PNP team is not going to maintain the continuity for their tools, we cannot use it. Otherwsie, we either get stuck with the old tool or upgrade to the new tool but cannot do anything more.

There are a few approaches to do @SDL-first web service development in VS 2008. The first is carefully tweak data contract and service contract to generate the desire WSDL, as suggested in http://blogs.msdn.com/donsmith/archive/2006/10/06/Handcrafting-WCF_2D00_friendly-WSDLs.aspx and http://www.theserverside.net/articles/showarticle.tss?id=DesignServiceContracts. However, this approach is tedious and not recommended as an WSDL-first approach. The second approach is to use svcutil to generate the service contract and data contract, and do the rest manually, as suggested in this discussion. This is easier, but is still difficult to automize with tools.

So the easiest the way to do WSDL-first development is still with the good old ASMX. The XML serializer supports various XSD better than the data contract serializer in WCF. Although you might lose some features in WCF, you are unlikely to miss the feature if WSDL-first is your focus. This is the only approach that will survive all the tool upgrades.

In the Java world, there is an excellent object-to-object mapping tool in dozer. I have been looking for similar tool in .net. After googling around, I found several interesting ones:

otis

NBearMapping

Earlier, I posted the interoperability between .net and Java web service. I will continue on how to access secured Java web service from legacy apps created with VB6 COM objects or classic Active Server Pages. Since we have already solved the interoperability issues between .net and securied Java web service, the next challenge is to register the .net proxy as COM object so it is accessible from VB6 and ASP pages.

Not all the .net classes can be registered as COM object. ASP can only work with COM objects that supports OLE automation so the it can work with even more limited .net classes. Proxy classes derived from WSE2 Microsoft.Web.Services2.WebServicesClientProtocol cannot be registered with dual interface. Fortunately, it is possible to define explicit interface for COM clients. The Visual Studio refactor feature made it pretty easy to create an explicit interface. After creating the interface, mark the class itself with [ClassInterface(ClassInterfaceType.None)] attribute. It is important that the explicit interface must be public. Another important step is do not forget to set ComVisible(true) in AssemblyInfo.cs.

The next step is to register the .net assembly as COM using "regasm myassembly.dll" or unregister with "regasm /u myassembly.dll". If we do private assembly deployment (that is, not registering the assembly into the global assembly catch with gacutil", the dll and the config files need to be copied into the directory of the exe that hosts the assembly. That means, for VB6 development, they need to go into the directory where VB6 resides. Furthermore, we need to rename myassembly.dll.config into HostExeName.exe.config.

With this technique, we can access fairly complicated, securied web services from our legacy apps.

Earlier, I posted that WSE 3.0 does not interoperate with Websphere web service. It turns out that WSE 2.0 would work just fine because different algorithm used to generate the keyid. Here are the procedures:

1. Import the keys into the Windows key store: Import the key as mentioned in this post. For testing purpose, I imported both certificates into Current User store. I imported the client private key/certificate into the Personal store. I imported the server key into the Other People store.
2. Create the client proxy. What made it a bit more complicated is that I use .Net framework 2.0 and Visual Studio 2005. While WSE2 works with .Net 2.0 runtime, the tools do not integrate with Visual Studio 2005. So I have to do things manually. From the Visual Studio 2005 Command Prompt, I changed to my project directory, and then ran "wsdl UrlToMyWSDL". This will generate a proxy class.
3. Change the base class of the generated proxy: change the base class to Microsoft.Web.Services2.WebServicesClientProtocol. This allows the proxy to support WSE.
4. Configurate app.config with Configuration Editor: Run WSE2 Configuration Editor. Open my project app.config file. Enable the project for WSE. Then under security tab, select CurrentUser for store location. Also check "Use RFC3280". This will allow the keyid algorithm with to be compatible with Websphere.
5. Add a policy file: From the Policy tab of Configuration Editor, select "Enable Policy". Add a policy for <DefaultEndPoint>. In the wizard, select "Secure a client application" and click Next. In our test case, we encrypt the message but do not sign the message. So just select Required Encryption under Request Message and click Next. Then add the service certificate and click Next and then click finish.
6. WSE2 by default uses different encryption algorithm as Websphere. So we need to add the following XML inside the security element in app.config:
<binarySecurityTokenManager valueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"> <sessionKeyAlgorithm name="TripleDES" />

</binarySecurityTokenManager>

7. Add usernameToken: in our test case, we send username token in cleartext. So we need to add the following code:

UsernameToken usernameToken = new UsernameToken(userName, password, PasswordOption.SendPlainText);

myProxy.RequestSoapContext.Security.Tokens.Add(usernameToken);

That it is! WSE2 is pretty easy to work with.