Pierre-Emmanuel Dautreppe

Depending of the browser, some control may need to be rendered differently. By default the .NET framework works with "Control Adapters", id est, some classes that will be plugged into the rendering process.

How does it works ? When the server receives a request, it will try to find which browser does the request, based on the user agent or on HTTP headers for example. To do it rely on some browser definition files (of extension .browser). To see them, please go on %windir%/Microsoft.NET/Framework//CONFIG/Browsers.

When the server has identified the browser (at worse, it would be identified as a "Default" browser), and that it needs to render a control, it will look if there is some control adapters plugged for this kind of control. If there are some, they will be in charge of the rendering. If not, the control will render himself. Note that an adapter can redirect / delegate some treatment to the control.

In this post, I will show
- how to create a basic control adapter
- how to use the adapter in a website (ie how to create a ".browser" file)
- how we can use this for testing purpose (by adapting the user agent used for testing requests) [Plus]

As you will be writing code, you will probably be writing tests. And you will probably come to writing internal methods to limit their visibility. And it will be necessary in lots of cases to test also these internal methods. How to do that ? You won't be able to access them from your test project.

It's not a big problem as Visual Studio 2005 (and 2008) will generate accessors for you using reflection. VS 2005 will generate a code file (that will have the big disadvantage that when you will change the name of a method, the file won't gets generated and your project will continue to compile. VS 2008 will generate an accessor DLL that will gets compiled (and so re-generated) at the same time you build your project.

But there is also another way to test the internal members : using the InternalsVisibleToAttribute.
I will show here in this post how you can do that for an unsigned DLL but also for an assembly signed with a strong name. [Plus]

When you run tests from command line, directly with the MsTest tool, you can include the reason of the failure (which is called the TestOutcome).
This value is coming from an enum TestOutcome declared in Microsoft.VisualStudio.QualityTools.Common.
Check in this post the different possible values and how you can retrieve it in the TRX file. [Plus]

I'm just back from the CITCON in Brussels, my first experience in CITCON.
Find here some comments about the session I have assisted to during this event ! [Plus]

CITCON (Continuous Integration & Testing Conference) comes to Brussels in October 19th & 20th (friday evening and saturday).

Interested in 1-day of great conference about CI and testing ? Join me there !

Be careful, it's limited to the first 100 subscribee so hurry up.

Need more information about CITCON ? Visit their website dedicated to Brussels ! [Plus]