Sunday, August 08, 2010

Configuring IIS Development Environment for HTTPS

When testing code for https on development environments its usually an annoyance to skip the browser page which states that certificate is not trusted. But in many scenarios where we are dealing with https requested out side of the browser it make development and testing very tedious. Although this post applies to https configuration in IIS, my most recent requirement was to enable message level security on WCF channel.

This might be applicable to other development environments but my assumptions are:

1. Window 7 64 bit.
1. Visual Studio 2010 (this installs makecert.exe)
2. IIS

Important: The certificate we are going to create is used on IIS site and will be tied to the FQDN of the site you are going to use it on.
[Main directions were originally taken from]

I am adding some more context and fixing some roadblocks I faced while addressing the problems on my local environment…

1. Run Visual Studio 2010 > Visual Studio Tools > Visual Studio Command Prompt (right click and run as Administrator)

2. Optionally change to working directory to root drive just to make it easy to access files > cd\

1. Create a Certificate which represent our fake version of Root Certification Authority (in real world this will be Versign, Geotrust etc and will cost $$)

makecert -r -pe -n "CN=Development Root Certification Authority" -ss Root -sr localMachine -a sha1 -sky signature -sv DevelopmentRoot.pvk DevelopmentRoot.cer

[Passwords are optional. I chose none.]

Type “certmgr” at command prompt and verify if this certificate was installed in “Trusted Root Certification Authority”.

2. Now that we have a Certification Authority, we can use this certification authority to issue certificate to ourselves.

makecert -pe -n "CN=REPLACE THIS WITH YOUR FULL COMPUTER" -a sha1 -sky exchange -eku -ic DevelopmentRoot.cer -iv DevelopmentRoot.pvk -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12 –sv DevelopmentSite.pvk DevelopmentSite.cer
pvk2pfx -pvk DevelopmentSite.pvk -spc DevelopmentSite.cer -pfx DevelopmentSite.pfx

Then go back to certmgr and import the pfx file created in this step to Root Certification Authority store. (This can probably go in some other store but due to shortage of time I just added it to Root Cert Auth. By doing this it shows up in IIS as available certificate to be associated with https binding).

Also import the pfx file created in step 2b. into IIS. Run inetmgr, click on the root node and then click on Server Certificates in the right pane.

note that for –n “CN=REPLACE THIS WITH YOUR FULL COMPUTER” you must make sure that you use Full computer name here. For example if your computer is part of a domain then you should use MachineName.DomanName as the cn name. (You can also verify this by right clicking on my computer > properties > FullComputerName)

3. Create HTTPS binding for the site and use DevelopmentSite certificate created above.

4. To test the certificate browse to and you should not get any certificate errors.

Note that https support is not available in Cassini. Although I have heard that there is a VS2010 solution in works. Until we hear more about that and https support this requires that you configure your site in IIS.

Wednesday, June 23, 2010

Mocking Web Service For Silverlight Consumption

One of my colleague ran into this typical dependency chain. The requirement was to show data in a Silverlight 3.0 data grid. Picture below summarizes the dependency chain. This picture is the very reason why we have IOC frameworks and how they make life easy. I mean, why should my Datagrid care about the fact that Synch framework is doing its job properly or not.













You can imagine how much time it would take for the developer working on the datagrid to resolve all the preceding 8 dependencies just to bind to the grid. Welcome to IOC (for those of you going “oh not again” please read on, there is little twist, at least it was for me).

Ideally we should only be concerned about our ViewModel and nothing else. Since ViewModel is using a WCF Proxy we already have an interface that we can mock. And here lies the key:

Mock the web service interface and inject it using the UnityBootstrapper

If you have basic Prism project injection should be straight forward. This is what we did in our bootstrapper:

this.Container.RegisterType<IMyService, MyServiceMock>();
myModel = IMyService.GetData();

Everything was smooth until this point in refactoring. Than I ran into trouble with actual mock implementation of the interface serialized in WCF proxy. Since all the methods get serialized into their corresponding Begin and End versions and the fact that everything in Silverlight 3.0 framework requires you to make asynchronous calls, you cannot just create straight interface mock and start binding.

Basically you have to be aware that you are mocking the asynchronous version of the interface and should not attempt to capture the underlying channel details in the mock. Given below is the code and new (much shorter and required) dependency chain I ended up with:

public class MyServiceMock : IMyService
public MyServiceMock()
{ }

#region IMyServiceMembers

public IAsyncResult BeginMyMethod(AsyncCallback callback, object asyncState)
callback.Invoke(null); // <—Trick your caller and tell them async operation complete right away
return null;

public ObservableCollection<MyClass> EndMyMethod(IAsyncResult result)
ObservableCollection<MyClass> mockedList = new ObservableCollection<MyClass>();
mockedList.Add(new MyClass());
return mockedList;

Technorati Tags: ,,,


*I am assuming no mocking framework is being used but the notion will still translate.

Here is the new dependency chain for testing my UI.

Short, Sweet and Testable.