Dennis "D.C." Dietrich : Silverlight

EMTF 2.0 Beta released

ddietric — Tue, 14 Jul 2009 13:04:00 GMT

It's been a couple of months since I first blogged about EMTF. Since then I've been busy refining and extending the framework and I'm happy to announce that the beta release of version 2.0 is finally done! Special thanks to Josh Poley since a lot of the new functionality is based on his feedback. So, allow me to give you a tour of what's new in ~~Reality~~ EMTF 2.0:

Pre- and post-test actions

The PreTestActionAttribute and PostTestActionAttribute attributes have been added to allow defining methods that are executed before/after each test method in a test class. This is most commonly used for shared setup and teardown of the environment required by a set of tests.

[TestClass]

public class Tests

{

// Will be executed before every test in the Tests class

[PreTestAction]

public void PreTestAction() { }

// Will be executed after every passed test in the Tests class

[PostTestAction]

public void PostTestAction() { }

}

Aborting tests, custom logging and the TestContext

Test methods as well as pre- and post-test actions can take one parameter of the type TestContext. If they do an instance will be automatically provided by the runtime. The test context allows aborting a test from within the test implementation e.g. in case test initialization fails. It also allows adding arbitrary information to the test log.

[Test]

public void Test(TestContext context)

{

context.LogLine("Initialization failed");

context.AbortTest();

}

Test groups

The TestGroupsAttribute attribute allows tagging test methods as belonging to one or multiple test groups. At the same time, there are new TestExecutor.Execute() overloads which limit test execution to tests belonging to the specified group(s).

[TestClass]

public class Tests

{

[Test]

[TestGroups("BVT")]

public void Bvt() { }

[Test]

[TestGroups("BVT", "STRESS")]

public void StressBvt() { }

[Test]

[TestGroups("STRESS")]

public void Stress() { }

}

class Program

{

static void Main(string[] args)

{

// Will only run Bvt() and StressBvt()

new TestExecutor().Execute(new String[] { "BVT" });

}

Concurrent test runs

EMTF now supports concurrent test runs in order to take advantage of multi-core CPUs. Concurrent test runs will execute tests on multiple threads instead of just one. The number of threads used is equal to the number of logical processors on the local machine.

TestExecutor executor = new TestExecutor();

executor.ConcurrentTestRuns = true;

executor.Execute();

Plain text logging to a stream

The logging library has also been extended and now includes the StreamLogger which writes a plain text log to a stream.

TestExecutor executor = new TestExecutor();

using (Stream stream = new FileStream("testrun.log", FileMode.Create))

{

StreamLogger logger = new StreamLogger(executor, stream);

executor.Execute();

logger.Close();

}

This posting is provided "AS IS" with no warranties, and confers no rights.

HTTP debugging for Silverlight developers (Mac OS X edition)

ddietric — Mon, 08 Jun 2009 13:00:00 GMT

Many posts have been written about how to debug problems with issuing HTTP requests from Silverlight applications, particularly in the context of web services and WCF (see for example Debugging Web Service Usage in Silverlight 2 or Faults and Exceptions when using Web Services in Silverlight 2). As they point out there are severe limitations to what information is passed to applications in case of non-200 HTTP status codes. And they also point out that sometimes you need to know what requests and responses are exactly sent over the wire in order to figure out what's going on, usually mentioning Fiddler for doing so. It is a very powerful tool allowing you to not only monitor HTTP traffic from certain applications but also letting you manipulate requests and responses (which is probably more than you need for "simple" debugging anyway).

This is all great until you hit an issue that only seems to repro on that other platform. Using a Windows application to debug on Mac OS X is impractical at best (impossible would be the better word in this case though). So, what to use instead? For my personal application development I use Wireshark which some of you may have encountered in the past under its old name, Ethereal. There are, however, a couple of differences. Wireshark is open source released under the GPL 2 but more importantly it is a sniffer and not an "HTTP debugging proxy". This means that in comparison to Fiddler it does not necessarily "know" HTTP as well since to Wireshark it is just another high-level protocol. It also means that a typical Wireshark capture picks up much more traffic than we care for (not using promiscuous mode in case of shared medium topologies at least reduces the amount of noise in the capture).

Wireshark is an X11 application so be sure that you have X11 installed and that it is up-to-date. Also, the OS X version of Wireshark uses BPFs to capture network traffic; however, access to those is denied for all users except for root (see also Enabling and using the "root" user in Mac OS X) so their permissions need to be changed first. This has to be redone after every reboot. While automatically making these changes during every startup or login has some appeal to it I prefer making them manually when they are needed. Given the nature of BPFs, keeping them locked down seems like a good idea to me.

Now we're finally ready to start Wireshark. The first start of the application can take a while (if I remember correctly this is due to X11 filling its font cache) so be patient. Also, all builds I have tried so far greet you with a nice pop-up error message. Luckily just ignoring it doesn't cause any trouble at least not in case of what I'm talking about in this post. At this point you can start capturing by simply selecting an interface from the list.

As mentioned before, this will give you much more information than you need since you'll see all traffic sent to/from your machine or all traffic hitting your interface if you are using promiscuous mode which is on by default. The screenshot below indicates 12752 captured packets after about 100 seconds which shouldn't surprise you since unlike Fiddler which is only concerned about HTTP Wireshark is capturing Ethernet frames. The simplest way to get to the information you really care about is to filter for http which is also shown in the screenshot. There's a lot more you can do like filtering for source or destination address so pay a visit to the Wireshark Wiki.

Lastly I'd like to mention that you can view a packet in its own window by selecting the command Show Packet in New Window from the View menu or by simply double-clicking on a packet in case you're running the latest development release.

This posting is provided "AS IS" with no warranties, and confers no rights.

Back from Portland Code Camp

ddietric — Mon, 01 Jun 2009 09:25:00 GMT

The Portland Code Camp yesterday was a blast. In fact, it was one of the best (un)conferences I've been to so far with a wide variety of topics and I'd like to share my personal Top 3 Best of Portland Code Camp 2009 (but keep in mind that that's 3 out of 5):

Patrick Cauldwell did a presentation titled Building Business Applications in Silverlight 3 which was a great introduction to what's new in Silverlight 3 for business application developers. He started by talking about what's already in Silverlight 2. His conclusion was that while the current version is a good platform for Rich Internet Applications implementing certain features is too much work. He then went on to talk about and demonstrate some of the new features in version 3 like navigation/deep linking and improved validation as well as the .NET RIA Services which are currently available as a preview.

Jason Kelly did an introduction to cloud computing focusing on two offerings which follow the utility computing model, Amazon EC2 and Microsoft Azure. After talking about the benefits and common usage patterns of cloud computing he compared EC2 and Azure in terms of the feature set and (dis)advantages of each platform. Jason also showed two versions of a simple application demonstrating how to use the Amazon and Microsoft cloud services. He has published his slides as well as the demo applications in a blog post (Portland Code Camp 2009 - Cloud Computing presentation).

The last session I attended was Brian Henderson's Implementing a Rich Interactive Application Design. The content was more general than the title suggests with many good tips on how to do good UI design and improve the user experience (UX) of your application. I highly recommend checking out the slides if you are developing applications without designers or UX engineers on your team and need some practical ideas that can help you deliver a better product; the slides can certainly not replace books or training but those two require time and money and who has those these days (unfortunately, the slides have not been uploaded yet but that should happen within the next day or two so keep checking the session page if they are still missing).

This posting is provided "AS IS" with no warranties, and confers no rights.

Introducing EMTF

ddietric — Tue, 17 Feb 2009 10:45:00 GMT

A while ago a needed to do what I like to call quick and dirty testing, i.e. getting as much test coverage as possible in a given period of time. To make things worse, I was working on a client-server feature requiring a bit of setup in order to work in the first place and wanted to cover both sides with my tests and be able to easily run all tests. So I thought, what if instead of trying to get this done with one of the existing test frameworks that typically host the test target as well as its tests, I just created a new solution which already had all the pieces in place to use the feature and put a tiny test runtime in there. I did exactly that and got my testing done the way I wanted to. Again, there is a reason why I call this kind of approach quick and dirty testing and I definitely wouldn't pitch it as a best practice but it has its place.

Because of my objective this "embedded" test runtime I created was extremely small but also highly specific to the test scenarios for which it was written and thus virtually impossible to reuse. That wasn't a surprise but rather one of the tradeoffs I had opted in for. Still, I was wondering what a generalized version would look like that, next time I wanted to do something like this, I could simply drop into my application and get going. The answer to that question is EMTF.

Yet another test framework called EMTF

The Embeddable Micro Test Framework is similar to its big brothers MSTest or NUnit though obviously smaller and simpler and with the twist of it being supposed to be hosted by the application under test rather than coming with its own test host. It is available in source and binary form on CodePlex and by now I'd say that its greatest value is actually in using it for educational purposes since the reduced complexity makes it easy to understand for people without prior API testing experience (that goes for both how to use it and - at the core - how it works). That said the rest of this post is an EMTF quickstart (though I do consider a small series on how to implement an API test framework using EMTF as an example).

The easiest way to add EMTF to your project (especially if you're not using C#) is to add references to the two assemblies Emtf.dll and Emtf.Logging.dll. The first assembly contains the actual test framework that doesn't even include any logging capabilities. The second one contains a logging base class, a logger writing to the debug output and a logger writing to the console (the latter one only for the .NET Framework). There are separate versions of the two assemblies for Silverlight and the .NET Framework with the Silverlight version being a subset.

Writing tests

Let's say your project is a console application, you added EMTF to it and now want to test the following class which is part of your project (once again, please ignore the fact that the class is completely useless):

public class LameExample

{

private String _string;

public String String

{

get

{

return _string;

}

set

{

if (value == String.Empty)

throw new ArgumentException(

"New value must not be an empty string.",

"value");

_string = value;

}

We need to verify that:

The default value of the String property is null
The setter of the String property throws an ArgumentException if we pass in String.Empty
We can set the property to arbitrary values (except for String.Empty)

Ideally we want the test framework to automatically find all the tests and execute them. So in order to tell EMTF which classes contain tests, they need to be marked with the TestClassAttribute. Furthermore, test classes must be public, non-abstract and non-generic since the runtime wouldn't know which type parameters to use. Similarly, test methods are marked with the TestAttribute and must be public, non-abstract and non-generic. In addition, their return type must be void and they must not take any parameters. Tests for state and behavior of an object are performed using assertions.

[TestClass]

public class LameExampleTests

{

[Test]

public void StringProperty()

{

LameExample le = new LameExample();

// Verifies the default value of LameExample.String

Assert.IsNull(le.String);

// Verifies that the setter throws

Assert.Throws(

// Action that is expected to cause the exception

() => le.String = String.Empty,

// Action(T) verifying the exception object where

// T is the type of the expected exception.

(ArgumentException e) =>

{

Assert.IsTrue(e.Message.StartsWith("New value must not be an empty string."));

Assert.AreEqual("value", e.ParamName);

});

// Verifies setting the property to a non-null,

// non-empty string.

le.String = "fhqwhgads";

Assert.AreEqual("fhqwhgads", le.String);

// Verifies resetting the property to null.

le.String = null;

Assert.IsNull(le.String);

}

Running the tests

Since EMTF does not include any sort of test host we need to instantiate the engine, the TestExecutor, ourselves. In addition, we need to hookup the engine's events so we actually get to know the outcome of the test run. The loggers in Emtf.Logging.dll do this out of the box. Finally, calling TestExecutor.Execute() will execute all the tests we have defined that conform to the rules explained above.

private static void RunTests()

{

TestExecutor executor = new TestExecutor();

ConsoleLogger logger = new ConsoleLogger(executor);

executor.Execute();

}

This posting is provided "AS IS" with no warranties, and confers no rights.

And another award for Skinkers...

ddietric — Fri, 21 Mar 2008 03:42:00 GMT

If you read my Silverlight-based P2P live streaming client wins MediaGuardian Innovation Award post you might say that this is getting old but at the same time I really think it's worth mentioning that there is a product and a partnership involving Silverlight resulting in two awards won in the UK within two weeks. This time it's the Partnering for Innovation Award which was one of the categories of the UK Technology Innovation and Growth 2008 Awards and it went to Skinkers and Microsoft for their joined effort on Livestation (see also Skinkers' press release).

This posting is provided "AS IS" with no warranties, and confers no rights.

Reflector add-in (proof of concept) for highlighting platform APIs

ddietric — Wed, 12 Mar 2008 06:58:00 GMT

I was talking to one of our partners at MIX about the new security model in Silverlight. In case you're not familiar with it yet I recommend reading The Silverlight Security Model (as well as part II and III if you're interested in the details) on Shawn's blog since he explains it very well (see also the documentation on SecurityCriticalAttribute, SecuritySafeCriticalAttribute and SecurityTreatAsSafeAttribute). In a nutshell: There is no CAS in Silverlight. Instead you are simply not allowed to call certain APIs in order to provide a robust sandbox which allows you to execute applications on a website without having to worry about the application possibly compromising your computer. For example a Silverlight application can't just access the file system or connect to any machine on the Internet.

After explaining this I was asked if there was a list with all APIs you can't call in Silverlight. While I'm not sure that there is really one list somewhere covering all APIs in Silverlight I noticed that it would be quite simple to generate one by writing some code that reflects on the Silverlight assemblies. However, that's when it hit me that this theoretical list would be rather long and consisting of information you don't care about most of the time. I guess a document basically describing the differences between the full .NET Framework and Silverlight (as far as the types they have in common go) would probably be more helpful (I'm still trying figure out if we indeed have something like that).

At the same time I thought it would be handy though to have something that allows me to browse APIs with the critical and safe critical APIs marked. And since many people use Reflector (yes, even me and others with access to the source code - it's just quicker to decompile an assembly than getting the right files out of the source control system) I looked into customizing it to do exactly this. The result was the following code:

using Reflector;

using Reflector.CodeModel;

using System;

using System.Windows.Forms;

using System.Drawing;

namespace Reflector.AddIns

{

public class SilverlightPlatformHighlighter : IPackage

{

#region Private Consts

private const string CriticalAttributeTypeName = "SecurityCriticalAttribute";

private const string CriticalAttributeTypeNamespace = "System.Security";

private const string SafeCriticalAttributeTypeName = "SecuritySafeCriticalAttribute";

private const string SafeCriticalAttributeTypeNamespace = "System.Security";

private const string TreatAsSafeAttributeTypeName = "SecurityTreatAsSafeAttribute";

private const string TreatAsSafeAttributeTypeNamespace = "System.Security";

private readonly Color CriticalAttributeColor = Color.FromArgb(0x00, 0xFF, 0xC0, 0xC0);

private readonly Color SafeCriticalAttributeColor = Color.FromArgb(0x00, 0xFF, 0xFF, 0x80);

#endregion Private Consts

#region Private Fields

private TreeView tree;

#endregion Private Fields

#region IPackage Members

public void Load(IServiceProvider serviceProvider)

{

tree = (TreeView)((IAssemblyBrowser)serviceProvider.GetService(typeof(IAssemblyBrowser)));

tree.AfterExpand += new TreeViewEventHandler(tree_AfterExpand);

}

public void Unload()

{

tree.AfterExpand -= new TreeViewEventHandler(tree_AfterExpand);

}

#endregion IPackage Members

#region Private Methods

private void tree_AfterExpand(object sender, TreeViewEventArgs e)

{

ICustomAttributeProvider attributeProvider;

ITypeDeclaration type;

foreach (TreeNode node in e.Node.Nodes)

if ((attributeProvider = node.Tag as ICustomAttributeProvider) != null)

{

bool isCritical = false;

bool isSafeCritical = false;

bool treatAsSafe = false;

foreach (ICustomAttribute attribute in attributeProvider.Attributes)

if (attribute.Constructor != null &&

((type = attribute.Constructor.DeclaringType as ITypeDeclaration) != null))

{

if (type.Name == CriticalAttributeTypeName &&

type.Namespace == CriticalAttributeTypeNamespace)

isCritical = true;

else if (type.Name == SafeCriticalAttributeTypeName &&

type.Namespace == SafeCriticalAttributeTypeNamespace)

isSafeCritical = true;

else if (type.Name == TreatAsSafeAttributeTypeName &&

type.Namespace == TreatAsSafeAttributeTypeNamespace)

treatAsSafe = true;

}

if (isSafeCritical || (isCritical && treatAsSafe))

node.BackColor = SafeCriticalAttributeColor;

else if (isCritical)

node.BackColor = CriticalAttributeColor;

}

#endregion Private Methods

}

While it technically is (the code for) a Reflector add-in I'd rather call it a proof of concept since it ignores the assembly nodes in the tree as well as the parent of any given node. The code is also a bit hacky since it relies on implementation details of Reflector which may change in the future. Compiling the code into an add-in and loading it into Reflector gives you an assembly browser which marks critical types and members in red and safe critical ones in yellow (which is more of an FYI anyway):

This posting is provided "AS IS" with no warranties, and confers no rights.

Silverlight-based P2P live streaming client wins MediaGuardian Innovation Award

ddietric — Sun, 09 Mar 2008 01:05:00 GMT

The first MediaGuardian Innovation Awards were held two days ago in London. Its motto - at least according to a big banner on their website - seems to be: "Some great ideas never see the light of day. We celebrate the ones that do." With that in mind I'm very pleased that one of the winners in the category Digital innovation - technology is Skinkers' Livestation, a Silverlight-based live streaming client which uses peer-to-peer networking to increase scalability (see also Skinkers' original press release from May 2007).

This posting is provided "AS IS" with no warranties, and confers no rights.

Setting up Silverlight 2 remote debugging on Mac OS X

ddietric — Thu, 06 Mar 2008 00:20:00 GMT

Let's face it: Silverlight is awesome! So are the Visual Studio Tools for Silverlight. One reason why it is so awesome is that you can run your applications on Windows and Mac OS X. But what if you need to debug an application while it is running on a Macintosh? Since there are no development tools for the Mac we have to resort to remote debugging which will allow us to debug the application running on OS X using Visual Studio on Windows. In order to do this we need to set up the CoreCLR debugging proxy on the Mac and then configure VS accordingly.

We start off by configuring the Mac. Everything we need on the Mac is part of the VS Tools for Silverlight installation and can be found in the directory %ProgramFiles%\Microsoft Visual Studio 9.0\Silverlight\MacIntel\ (or %ProgramFiles(x86)\Microsoft Visual Studio 9.0\Silverlight\MacIntel\ if you're running a 64-bit version of Windows). We just copy the whole folder over to the Mac e.g. into /Applications/ (you may also want to rename the copy on the Mac as MacIntel doesn't really describe the content that well). After that we have to mark the files configcoreclrdebug and coreclr_dbg_proxy as executable and then run configcoreclrdebug which will set up the debugging proxy and create a Windows executable containing all the information required to set up VS. It only requires two inputs: A port number in the range from 49152 to 65535 which will be used by the proxy to listen for incoming connections (you can also just hit Enter to accept the default in squared brackets) and a password used to protect the data in the Windows executable.

HOSTNAME:~ username$ cd /Applications/MacIntel/

HOSTNAME:MacIntel username$ ls -la

total 384

drwxr-x--- 6 username admin 204 Mar 3 05:25 .

drwxrwxr-x+ 42 root admin 1428 Mar 3 05:26 ..

-rw-r----- 1 username admin 62464 Mar 3 05:25 ConfigureWindowsCoreCLRDebuggingBase.exe

-rw-r----- 1 username admin 55383 Mar 3 05:25 MacDebuggingReadme.rtf

-rw-r----- 1 username admin 23604 Mar 3 05:25 configcoreclrdebug

-rw-r----- 1 username admin 48944 Mar 3 05:25 coreclr_dbg_proxy

HOSTNAME:MacIntel username$ chmod u+x configcoreclrdebug

HOSTNAME:MacIntel username$ chmod u+x coreclr_dbg_proxy

HOSTNAME:MacIntel username$ ./configcoreclrdebug

Generating debugger certificate and private key...

Done.

[...]

Select a TCP port number to be used for debugging: (49152-65535) [58752]:

[...]

Please specify a password at least eight characters long that will be used to

protect the debugging private key during transportation to the Windows machine

from which debugging will be performed.

Password:

Re-type password:

The CoreCLR debugging environment has been successfully configured on this

machine for the current user. In order to enable debugging from a remote machine

running Windows it will be necessary to propagate these same configuration

settings. To aid in this a Windows executable has been created in the following

file:

/Users/username/.coreclrdbg/ConfigureWindowsCoreCLRDebugging.exe

[...]

HOSTNAME:MacIntel username$

We now copy ConfigureWindowsCoreCLRDebugging.exe from the location mentioned in the output of configcoreclrdebug back to our Windows machine and execute it. All it will ask us for is the password we used to generate the executable.

C:\Users\username\Desktop>ConfigureWindowsCoreCLRDebugging.exe

Password: ********

This machine and user account has been successfully configured.

C:\Users\username\Desktop>

And we're done. We can now test this by creating a little app, copy the ClientBin folder over to the Mac and execute it there. Then we'll attach to it by using the Attach to Process... command from VS' Debug menu. We select CoreCLR Remote Cross-platform Debugging as the transport and enter the name or IP address of the Mac as the qualifier which will get us a list of the processes running on the remote machine. We just need to select the right instance of the web browser hosting the Silverlight runtime (its type will be CoreCLR Remote) and hit Attach. After that we can set breakpoints, check the value of variables and so on as usual.

This posting is provided "AS IS" with no warranties, and confers no rights.

The day before MIX...

ddietric — Wed, 05 Mar 2008 12:06:00 GMT

So, I finally made it to Las Vegas. However, not without a four hour delay in Portland due to a leaking lavatory which made it necessary to use another aircraft. That of course caused me to miss most of the presentation of The King of Kong meaning I got to watch the last three minutes of the documentary and now probably will end up ordering the DVD. But at least I saw the discussion/QA with Steve Wiebe, Ed Cunningham and Walter Day where they talked about professional gaming in general and beating Donkey Kong in particular.

Other than that I don't have much to report at this time since I can't talk about [you’ll], [have to] and [wait] yet. Except for pointing out a press release published by Nokia announcing "plans to make Microsoft Silverlight available for S60 on Symbian OS, the world's leading smartphone software, as well as for Series 40 devices and Nokia Internet tablets".

This posting is provided "AS IS" with no warranties, and confers no rights.