Normally when you try to unit test a method from an internal class, u will receive a message saying something like ‘… is inaccessible due to its protectionlevel’. The typical response in these kind of situations is either ‘ah, f.. it. I’ll just skip this test’ or ‘I’ll just make the class public. Who cares.’.

What you actually want to do is to make the internal method accessible to your unit test project. As it turns out, that this isn’t really all that difficult. Visual Studio will do most work for you. There are however a few things u have to keep in mind. In this article I will stretch out on those things.

First, let’s make a little console app which contains an internal class. (The entire solution can be downloaded here).

We enter the value false into the method and we expect to receive a value false back. If that is true, then the test passed.

The following steps are only necessary when you have a strongly signed project:

Find the public key of your unit test project

There was a time where finding the public key token using sn –T was enough. Now however, the InternalsVisibleTo attribute uses the public key.
We can retrieve that key in two steps by using the sn.exe tool.
First create a file with the public key from the assembly key file using the following command (inside a Visual Studio command prompt)

sn –p NameOfYourKeyFile.snk NameOfYourOutputFile.PublicKey.

Use the output file to retrieve the public key with the –tp option of sn.exe:

Here you copy-paste the public key from the previous step into the marked section. You will have to remove the linebreaks, but that should be rather obvious. Don’t copy the key shown here, you have to use your own key…

Recently I got several questions about this topic, so I thought it would be nice to write a little bit about how to use XML inside SQL Server.

First of all: *don’t* query XML using substring(), pos() and other string manipulations. If you still do ugly stuff like that then you have to read this article and you also have to buy a big pie for your co-workers.

So we had this project where we had several nvarchar(max) fields which actually contained xml documents. This way of storing XML is fine when you don’t need to look inside the xml data itself. But when you want to use the data inside the xml documents its convenient to use the xml datatype. This datatype is available from Sql Server 2005 and up. In this post i’ll try to introduce you to the magical world of XML inside sql server.

Xml Datatype

The Xml datatype allows you to perform several operations on the xml data from within t-sql. Although this is not very fast, it’s often better than round-tripping and doing the xml parsing in your application layers.

You can use the xml datatype just like any other datatype. You can use it for tables, table variables and also for regular variables and procedure/function parameters.

Example

This creates a table with one column of the xml datatype and inserts one row with a (simple) XML document:

<document><header>Alphabet</header><items><itemid="a">a is for apple</item><itemid="b">b is for balloon</item></items></document>

Now the cool thing is that there are several methods that can be executed on the Xml datatype, such as:

Query

Value

Exists

Modify

Nodes

In this brief introduction I’ll highlight the usage of the Value and Query methods. All methods are well documented in the MSDN library.

Query

To get the “header” tag from our example xml document a query like this could be used:

select field1.query('/document/header') from #demo

This would return only the <header> element, with its contents. The language used to write the query is called “XQuery”, which is an XPath based query language defined by W3C. But be warned, only a subset of the official language is supported.

Say you’d like to get the xml node which has an “id” attribute with a value of “a”. You can use a query like this:

select field1.query('/document/items/item[@id="a"]') from #demo

This would return only the first of the two <item> elements, as an XML fragment in an XML field. If you are puzzeled by the syntax here, then please take a moment to look at these examples, that’ll give you a quick start.

Value

The value method is one of the methods that I personally have used the most. With this method you can select contents from an XML field and convert it to a “regular” sql datatype (also known as scalar values).

This statement would return all records which have an xml document in their “field1” column where the value first “item” tag starts with “a”. Please remember: this is nice but it will kill performance if you attempt this on a large table with loads of xml documents in it: in sql 2005 you cannot put indexes on values inside XML field! Sql server 2008 (and up) will let you create XML indexes as well.

Namespaces

One of the things I get asked most is how to query xml documents which have one or more xml namespaces associated.

Please notice that the only difference is the addition of a namespace.

Running the first .value method example query on this record will return a NULL value. This is because the xml elements now live inside the “http://www.brokenwire.net/xmldemo” namespace, and the “/document/items/item” xpath expression looks for these elements without a namespace, so it doesn’t find anything in this document.

To be able to query with namespaces there are (at least) 2 possibilities. You can either completely ignore the namespaces and go directly to the elements you need, or you can declare the namespace and use it properly in your expressions.

This expression will only work for the document WITH the namespace, because in the other document the elements live in the default namespace.

More details

If you can’t get enough of this then this introduction to XQuery article on MSDN is worth reading too. You’ll need a lot more Xpath and Xquery knowledge than covered here to make really good use of the potential powers that are enabled by the xml datatype. Fortunately these are both standardized by W3C, so learning them will enable you to do much more cool stuff.

And don’t forget, you can post your ideas, notes, thoughts and “please send me the codez” requests in the comments, that’s what they are for.

So because the Team Explorer doesn’t allow you to copy Build Definitions without manually copying all the fields I had to write a small tool to do so. In this post I’ll show you how that works.

First of all, the user-friendly designed-by-a-developer user interface:

First you connect to the TFS server then you select the Build Definition that you’d like to copy. Optionally you can add some find/replace values and finally you hit the button. As easy as 1-2-3. The interesting bit is of course how this is done.

The tree view at the left hand side is populated by this little piece of code:

Basically it connects to the TFS server and iterates through the projects. For each project the Build Definitions are queried and the results are added as child nodes to the tree.
Behind the the copy button this piece of code does the real super-time-saver magic:

The FindReplace function takes care of replacing the values from the find/replace list. The copying of most properties is rather straightforward. Of the the things to take into account is that the paths to the workspace and the Build Script (ConfigurationFolderPath) have to exist before you copy (create) the build definition.

I use this tool on TFS2008, but converting this to TFS2010 shouldn’t be hard. Of course it would be nice to see this kind of functionality in the next version of the Team Explorer. Until then, you can save a lot of typing and mouse clicks (and $$$) by using a tool like this.

Just to be clear what’s happening here: when an exception is thrown in the .Elapsed event of a System.Timers.Timer object then the exception gets silenced by an empty catch block within the framework code surrounding this event. You can see the sample code for reproducing this in my previous post.

Recently Olav Kwakman and I collaborated for the challenge to build .NET 1.1 code with a TFS 2008 build environment.

After configuring the build server we asked Captain Google what to do, and we implemented approach two described in the following blog post but the important thing is that we added one extra feature.

In approach #2 of Nagaraju's blog he modifies the output directory by adding an <ItemGroup> in the build script and writes the output to that directory in the After Compile Target Group. The problem with this solution is that the list of file in the ItemGroup is being initialized before the solution is being build. Therefore when your solution output changes the build will not pick this up the first time around. (This is a common "issue" with listing files in itemgroups, many have been tricked into this problem before)

By creating the ItemGroup at runtime (using an CreateItem task) this problem will not occur. Here's how you do just that: