"Some of the properties associated with the solution could not be read"

Next to the message in the subject, one of the symptoms we encountered is that although the solution contains some test projects the ‘Create private accessor’ menu has disappeared. Also, selecting ‘Create unit tests…’ produces an error. And when editing a testrun config and selecting the ‘Code coverage’ option, the settings dialog simply closes, without any message.

All these (and probably more) symptoms can occur because of a corrupt solution file. In our case the nested projects section was corrupted. Chances are this is because of some project or solution folder not being removed the way it should have been. Anyway, I tried fixing the solution file by hand but because of too many projects and solution folders this wasn’t the way to go. Those GUIDs don’t make a file very readable… I made a new solution file, containing the same solution folder structure, and added the existing projects. I overwrote the existing solution file, and that was that. So when you’re experiencing any or all of the above symptoms, try building up a new solution file.

Hope this helps.

Technorati tags: , , ,

Project template doesn’t understand AssemblyName tag?

At my current project we made a project template for Visual Studio for our testers. We added all the references, folders and files a tester needs to add a new system tests project. One of the testers (!) extended our XML generator, which generated XML testcases based on data entered in Excel, to now generate a complete C# test class. Making (system) tests which are automatically run during the nightly build now really is just as simple as entering data in Excel.

In the project template, we added a default namespace followed by $safeprojectname$ in the RootNamespace tag and in the AssemblyName tag. For example, the RootNamespace and the AssemlyName tag contain the following: Namespace.SubNamespace.$safeprojectname$. When you create a project based on the template, named TestProject, the default namespace is filled in accordingly: Namespace.SubNamespace.TestProject. The AssemblyName however, only contains TestProject.

Maybe I’m missing a step where the (entire) AssemblyName is overwritten with the $safeprojectname$ value, but if it is, why isn’t that happening to the RootNamespace tag? These two fields look the same, but act differently. Today I didn’t have any time to discover why this happens, but I’m going to look for the reason. And if I find anything, I’ll let you know.

By the way, I’ll be checking this in Visual Studio 2008 asap.

Edit 21-11-2007 @ 18:07
The MSDN forums have done their job and brought me an answer about this issue and Visual Studio 2005. There is a workaround (see link in the MSDN forums post, or click here). Unfortunately, that involved developing a Guidance Package, which we don’t have time for at the moment. We already instructed our testers to copy the default namespace, and paste it as the assemblyname. That’s [wikipedia:pragmatism] for you ;)

Technorati tags: ,

Nerd alert?

I have lots of games for my Xbox 360 I still need to / want to finish, like The Orange Box and Bioshock. And despite this, I’ve been working ‘non-stop’ behind my laptop for the last two evenings to prepare it for Visual Studio 2008, and to download and install it. It’s almost time… ;)

I can’t wait to get busy with the final version of Visual Studio 2008 and stuff like LINQ, extension methods, anonymous types, lambda expressions and so on. Let’s do this!

This is NOT a test.

Test Driven Development is hot, just like unit testing your software and any other kinds of (automated) testing. And as we all know: sometimes stuff that’s hot is misinterpreted, explained wrong or just simply used in a really bad way. Unfortunately, testing is no exception to this rule…

Not too long ago I had a discussion with a project manager who told me the code in his project had a code coverage close to 100%. Because of that, so he felt, his software would be darn close to perfect. I then asked him if testers had validated the unit tests his developers had made. The answer was no, but he didn’t see the need for that because “the code coverage was so high”. I’ll spare you the details of the discussion, but let’s say it led to a few new insights for at least one of us ;).

I’l try to make my point over here with some examples. Let’s first make a very simple (trivial) method.

static string LowercaseConcatenateStrings(string first, string second)

    result = first.ToLower();
    result += second.ToLower();

    return result;

As you can see this is a simple method which converts both input parameters to lowercase and concatenates them. Now let’s see a unittest which will result in 100% code coverage:

public void TestLowercaseConcatenate()
string result = UnitTestSample.LowercaseConcatenateStrings(“test1”, “test2”);
Assert.IsNotNull(result, “Returnvalue is null!”);

This unittest does result in 100% code coverage, but does not test all the scenario’s applicable to the method. A null value for one of either parameters results in an unhandled exception. It doesn’t even check if the value of the returned string is anything like it should be! These tests (and the code) are far from perfect, even though the coverage is 100%.

This is a simple example where it’s easy to determine the flaws, but you can imagine a more complex method would require an expert’s eye to ensure the quality of the asserts is up to par. A method of 20 lines with lots of calculations and object modifications, cannot be asserted with a check to see if the object merely exists.
Of course, and this should come as no surprise, testers are able to look at a piece of code or software a little bit different than developers do, so why not use their expertise. In short: check the quality of your assertions!

HowTo: Set the Theme for a MasterPage (from code)

The MasterPage doesn’t have a property for setting the Theme at design time. Despite this, I wanted to set the Theme for a MasterPage, so I decided to set it from code. I was aware of the possibility to set the Theme through the web.config, but that wasn’t the way I wanted to set it. One of the reasons being it would result in the theme being applied to the entire website.

I tried to use the Page_Load, but that resulted in the error “The ‘Theme’ property can only be set in or before the ‘Page_PreInit’ event.”. That sounds logical, because the Theme makes the Page render in a specific way. So I added a Page_PreInit method with the right parameters, but that didn’t do anything. As it turns out, the Master Page doesn’t have a Page_PreInit…

To be able to set the Theme for a MasterPage from code, follow these steps:

  1. Add a class with the name ThemeModule (or any other name)
  2. Let the class inherit from IHttpModule
  3. Implement the init method as follows:

    public void Init(HttpApplication context)
        context.PreRequestHandlerExecute += HandlePreRequest;

  4. void HandlePreRequest (object sender, EventArgs e)
        Page page = HttpContext.Current.CurrentHandler as Page;
        if (page != null)
            page.PreInit += delegate
                                    page.Theme = DetermineTheme();

  5. Add the HttpModule to your web application through the web.config:

        <add name=ThemeModule type=Howtos.ThemeModule/>

That’s it! Hope this helps.

A week ago I came up with this solution together with a good friend of mine. The code was on his machine, so he said I had to add a ‘thanks to’ in this post. Well, here it is: thanks 2 Sander van Kemenade! ;)

By |October 20th, 2007|.Net, HowTo|1 Comment

Build problem – Solved

Yesterday, I posted about a problem with MSBuild building our solution. We solved it, so I wanted to let you in on the secret solution.

We use the Enterprise Library V1.2 in some of our projects. And because some of the projects are being re-used from other internal projects, not all the references in thos projects were checked for versions. As it turned out, another project had a reference to an enterprise library assembly with a runtime version of .Net 2.0. And allthough this project compiled succesfully, local and on the build server, it broke the build of one of the other projects. This project (the one with the wrong reference) didn’t need the EntLib reference, so it ‘disappeared’ because of optimization. But reference resolving had resolved it, and pointed to EntLib 3.0. Later in the build the project which failed did need the EntLib file, and used the allready resolved assembly location.

The problem occured after EntLib 3.0 was installed on the build server. I think the problem is there because of  breaking changes between EntLib 2.0 and 3.0, because you would think the assembly resolver would have found the EntLib 2.0 assembly earlier. I’ll be checking for that on monday. And if I’ll find anything weird, I’ll get back at you.

By the way, we solved this problem by using the verbose mode of MSBuild. This mode logs everything very extensively. Because of this, we could see the assembly reference resolving process, which lead us to the problem. You can make MSBuild more verbose by locating your build’s rsp file, and add /v:diagnostic to it. However: use this option with care. It made our buildlog 200+ Mb’s for a 71 project solution.

Technorati tags: , ,
By |June 2nd, 2007|.Net|0 Comments

MSBuild – Compilation error

Our current project uses the possibilities of MSBuild to have a daily build on a TFS server. This has been working up until yesterday somewhere around noon. Nobody knows what exactly happened, but it stopped working after our successful build of 11:42 am.

Our problem:
Compilation of one project (of a total of 71 projects) is failing. The project builds successful on the local machines of all the developers. It references EnterpriseLibrary.Common and EnterpriseLibrary.Configuration (among other assemblies), both of EntLib 1.2. In the csproj file, both references have a hintpath which is relative, indicating the references in the project file are right. The references are made to an ‘external references’ folder, where the entire EnterpriseLibrary can be found. This folder is also available in source control.

(Part of) the statement which makes the build fail:
Csc.exe /reference:”E:TFSBuildprojectname.DailyBinariesReleaseMicrosoft.Practices.EnterpriseLibrary.Common.dll” /reference:”….External ReferencesEntLib”

My main question is: what is making MSBuild pass one reference with a relative path, and one with an absolute one? And why to the binariesrelease folder? I tried cleaning up the project file, and I even made an entire new project and copied the files from the ‘old one’ there. But all of this to no avail. We’re currently further investigating this issue, and a thread has been started on the MSDN forums. I’ll keep you posted on any updates.

By |June 1st, 2007|.Net|1 Comment

MSBUILD : warning : Specified cast is not valid

At my current project we use Team Foundation Server together with the possibility to have a daily build through MSBuild. Over the weekend, the build failed. Because our ‘build master’ called in sick this morning, I took it upon me to fix the build. But compiling the sources was no problem, because that finished without any errors. And there were no failing (unit)tests. Even better: there were no tests which had run at all! There were ‘no test results to display’. The only thing I found in the build log (which is pretty big in a 70+ project solution!) that could indicate a problem was a warning from MSBuild:

MSBUILD : warning : Specified cast is not valid

And, just below that line, the following one:

The previous error was converted to a warning because the task was called with ContinueOnError=true.

After some searching and trying, I found out TFS / MSBuild doesn’t like it when your vsmdi file contains a list or sublist that doesn’t contain any tests to run. Somehow this feels like a bug, because parsing the testlist fails when it has no members. List != null && List.Count > 0 anyone?

Technorati tags: ,

By |May 21st, 2007|.Net|1 Comment

Unit Test Adapter threw an exception

“Unit Test Adapter threw exception: System.Reflection.ReflectionTypeLoadException: Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information..”

This error popped up at one of the testers of our project this morning. The unittests he selected worked fine on my machine, but all failed on his with the above message. After searching a bit we found that the only thing which was different between my testrunconfig and his was that he enabled code coverage for the assembly these unittests were pounding away at. As it turns out, this error appears when code coveraging (is that even a word?) a signed assembly without re-signing it.

To re-sing an assembly, open the testrunconfig you are using and go to the ‘code-coverage’ element in the left pane. Locate the textbox ‘re-signing key file’ and enter the path to the key file which should be used to re-sign the assembly (or browse for it, of course). Hit ‘Apply’ and then hit ‘Close’. You’re done now! Happy unittesting….

re-signing key file.jpg

My new configs, and more …

It took me a while, but in the end everything worked out and life’s good… Most important changes are I have my very own server now, containing all the general stuff like mail, music, development stuff and that kind of data.
My workstation received a small update (I was able to upgrade based on the ‘old’ machine of a friend) and is now running Vista quite smoothly. To be honest, I haven’t found any major issues yet.

I’m currently reading up on Aspect-Oriented Programming / Software Development. Next to that I am trying to find the time to get a bit further with my .Net magazine article about reflection. To be honest I’m quite busy, so maybe I’ll ask the nice people at the magazine if it’s possible for my article to appear in the issue after the upcoming one. On the other hand, if I can find an inspired day I’ll probably be done…

At my current project there’s lots of architecture-stuff to think about. We’re at a pretty abstract level, making it easier to think outside of the box. At least, that’s the way I experience it. I’m finding some of my co-workers don’t do so necessarily.

Last but not least: yesterday I attended a course in presentation skills. The thing that struck me most was the metaphor ‘feedback is a gift’. You receive it, unpack it, look at it, and then it’s yours. So it’s also yours to do with it as you please. That’s a way of looking at feedback that makes it just a bit easier to receive (negative) feedback…