Today I was struggling to figure out why I kept getting this error message when downloading a ClickOnce app:

The file 'C:\Documents and Settings\[user]\Local Settings\Temp\2\Deployment\RCAX3K4W.T8E\GRY27V4Q.GBE\SomeDll.dll' already exists.

First, let me just say that I don't use Visual Studio to create the ClickOnce deployment, but the Mage.exe utility. If you use Visual Studio this problem will be solved on Publish in Visual Studio.

I knew there was only one of this dll present on the server where ClickOnce downloads its files, but still it insisted that it was already downloaded. I checked my application manifest and there where only one entry for my dll. The dll causing this problem is a COM dll with generated manifest files (Reg-Free COM) as described here.

I started to inspect the Reg-Free COM manifest file generated by Visual Studio. It turns out that this manifest file use the same syntax as ClickOnce, or actually ClickOnce use the existing manifest schema that was introduced with Windows XP and Reg-Free COM. So in my ClickOnce manifest I had this:

...
<file name="My.dll" size="1121280">
  <hash>
    <dsig:Transforms>
      <dsig:Transform Algorithm="urn:schemas-microsoft-com:HashTransforms.Identity" />
    </dsig:Transforms>
    <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
    <dsig:DigestValue>UwpS1EpkD7aJk3uWdOtX+3BHiOA=</dsig:DigestValue>
  </hash>
</file>
...

...and in my Reg-Free COM manifest I had this:

...
<file name="My.dll" asmv2:size="1121280">
    <hash xmlns="urn:schemas-microsoft-com:asm.v2">
      <dsig:Transforms>
        <dsig:Transform Algorithm="urn:schemas-microsoft-com:HashTransforms.Identity" />
      </dsig:Transforms>
      <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
      <dsig:DigestValue>UwpS1EpkD7aJk3uWdOtX+3BHiOA=</dsig:DigestValue>
    </hash>
    <typelib tlbid="{2d5e2d34-bed5-4b9f-9793-a31e26e6806e}" version="4.1" helpdir="" resourceid="0" flags="HASDISKIMAGE" />
    ...COM Registry Entries...
</file>
...

It's exactly the same as ClickOnce except from the <typelib> part which is used by Reg-Free COM. ClickOnce treated this as any other ClickOnce manifest, and correctly stated that the file is about to be downloaded twice. The surprising part for me though was that the Reg-Free COM manifest was read at all. Since the deployment manifest is only linked to the application manifest...

So what's the solution? Just delete the file entry in the ClickOnce manifest and re-sign it! Deleting can be done like this:

ApplicationManifest manifest = (ApplicationManifest) ManifestReader.ReadManifest("ApplicationManifest", @"My.exe.manifest", false);
FileReference fileRef = manifest.FileReferences.FindTargetPath("My.dll");
manifest.FileReferences.Remove(fileRef);
ManifestWriter.WriteManifest(manifest);

Curious about how Visual Studio solves this? It merges all the manifest files into the application manifest and use the imported manifest entries instead (or something like that). At least that happened when I created a sample program to test this.

Rune Grothaug from Microsoft and NDC has interviewed Scott Hanselman with questions from the Norwegian .Net User Group! Scott will do the keynote at the Norwegian Developer Conference this year and will also have sessions on IIS7 and ASP.NET MVC.

I just wanted to welcome our latest member of the Norwegian .Net User Group community; Haugesund. Welcome! This is especially fun for me since Haugesund is where I grew up and lived for my first 18 years. Looking forward to see an active user group down there and promise to drop by if I'm ever in town when you have a meeting.

Live in Haugesund and want to be a member? Go here to sign up.

Today I had a problem. At work we had a SCSI Raid controller that failed and we lost a logical device. Man I was pissed off! On top of this the raid was RAID 0 (striped), meaning there was no chance of getting any data back. This was the drive(s) hosting the OS which we had to reinstall :-( Anyway, this resulted in me having to spend quite some time in a freezing and noisy server room fixing the problems. While doing stuff like this (reinstalling OS, software and a pointless effort of restoring data) there is a bit of waiting time, so I figured I might as well work on our new server waiting to get TFS 2008 up and running. A brand new server (see spec below) dedicated to protect the heart of our company; the source code!

So I started digging around for the TFS 2008 DVD, knowing it should be on my desk with the MSDN subscription we get through the Microsoft Gold Partner program, but it was nowhere to be found. After a call to MSDN it turns out that the DVD's are now being shipped to our headquarters in Oslo, which was the case for TFS 2008 as well, but they couldn't find it. The guy who knew was of course away that day. You might wonder why not download? Well, you can't. TFS versions available on MSDN subscription is only Workgroup and trial editions.

My last attempt before giving the whole thing up was calling my friend John from NNUG and ask if they had a DVD I could use. He had a much better idea:

"Just use the trial and upgrade with your key at a later time".

Dooh! Why didn't I think of that. Check out Brian Harry's blog for more details: http://blogs.msdn.com/bharry/archive/2007/11/22/2008-installation-questions.aspx

Server spec:

• HP ProLiant DL380 G5 Intel® Xeon® E5440 Quad Core Processor 2.83 GHz 12MB 2GB 1P Rack Server
• HP 4 GB PC2 5300 DDR2 DIMM Memory
• 6 HP 72GB 2.5 inch 15K rpm Hot Plug DP SAS Hard Drives
• 2 HP 146GB 2.5 inch 10K rpm Hot Plug DP SAS Hard Drives

I think this should keep our source code safe for a while...

The first .Net user group ever (as far as I could find out) was started by Ruth Walther in Seattle December 2000. It seams like this group is no longer active and I was unable to find out why. Anyway, today you'll find a user group in almost every major city in any country. And if you don't have a user group where you live, I think it's about time you start one! :-) Seriously, it's not that hard and you'll be a hero where you live! :-)  I can really recommend the experience and people will defiantly appreciate someone taking the first step to get your city on the user group map.

After the first user group started up in the US many others soon followed during 2001. To pick a few other countries I'm familiar with I can say that my home country Norway started their first user group in Oslo October 2001 and in my city Bergen we started up in December 2002, the London .Net User Group was started in 2002 and Sydney Australia in April 2002, .

It's free
Most user groups I know of don't charge for membership. Many don't even have memberships, but use the word of the people to announce their meeting or that "everybody" knows that their having a meeting last Wednesday in every month, and it's just to show up. User groups rely on local, national and/or international sponsorship. If your country have a Microsoft company present, they usually help out. This can be to help you get in touch with speakers, sponsor travel costs (for speakers), pizza and the like. The user group I run in Bergen use local sponsors for pizza, but get some help from Microsoft for travel costs. When requesting speakers it's often smart to provide them with consulting when they visit your city. This is a nice way of helping your local companies get excellent consulting and it make the speakers trip to your city a bit more attractive.

Why are user groups so popular?
There are many reasons for this and they vary from user group to user group. But from my experience there are some general things that should more or less apply to all user groups:

• It's free
• You get free food (usually pizza)
• You get to meet other people from other companies to share experience with, that you would usually not meet outside the user group
• You learn a lot
• Keeps you up to date on what's going on
• Communities in general are popular

INETA
INETA is the mother organization for all .Net user groups. Its an acronym short for International .NET Association. You will find user group related to SQL server, VB, SharePoint and other .Net related products. They all have in common that they focus on some type of Microsoft .Net related technology. INETA is divided into five geographical areas; North America, Latin America, Middle East and Africa, Asia Pacific and Europe. My experience is with INETA Europe, but I expect it to work much the same in the rest of the world. INETA Europe have among other things a Speaker Bureau with lots of good speakers. As a member your user group can request two speakers per year. These are top notch speakers! In Europe you'll see names like Ingo Rammer, Christian Weyer, Dino Esposito to mention a few. As a member your user group will also get a quarterly kit where you can select some books, cd's and other stuff to use as giveaways for you members, prizes etc. INETA also helps getting user groups started, especially if it's the first user group in the country. If there are existing groups in the country, the other groups usually helps you getting started in your city. That's how communities work!

"Why would you need a tester today? When you truly learn to master Test Driven Development their should be no need for a tester. You have a test for everything and you even got it covered in your continuous integration that will alert you if someone checks in something that breaks existing behavior. Shipping software now days is a breeze compared to some years ago when you had those testers nagging you about small details that where totally irrelevant for the end product. Not only that, they didn't understand the process around coding at all and how hard it is to develop perfect code. Well, at least we are there now. The perfect code has arrived with TDD! Yeah!"

Something like the above was stated by a senior consultant that I met some weeks ago. I added some extra stuff to emphasize my point, but the overall meaning did not change. He where convinced that today there is no need for testers.

I think that TDD has made the job easier for testers, allowing us developers to produce better code quality. However, TDD don't test much of what a traditional tester would test. TDD is not something that a tester would think of to begin with. Maybe that's why Dan North came around with the concept of BDD (Behavior Driven Development), replacing test with behavior. Behavior is a much better description of what we're trying to accomplish (from a testers perspective), though BDD is not necessarily a replacement of TDD, but more a response to TDD. TDD really don't have anything to do with testing as a tester sees it. BDD however focuses more on the business aspect of what your trying to solve. It "forces" you to look at things from the outside and in.

Another aspect that TDD does not cover is of course the look and feel of the application that only a human can tell is right, wrong or bad. Much of the functional logic is also impossible to test with TDD. There are other tools one can use for that, but not TDD. I think that this kind of thinking really puts TDD into a bad light. I'm pretty confident that TDD was never intended to replace testers.

Talking about automating tests and the like. Automation is often done by developers or testers with developer skills. Automation is a tool for the testers to make their job easier, not a replacement. Code help testers automate stuff that they do time and time over. The good thing about automation is that testers can focus on other things than the manual tests which is now automated. Not all tests can be automated and not all tests will add value if automated. Some you will just spend to much time maintaining and is just not worth the effort of automating. Testers needs to be careful with how they approach test automation and the tools used in the process.

We now also see that tester more often make use of dynamic languages as their preferred language. Why? Because you can achieve more with less code. Also dynamic languages (as they are today) is often in beta, and developers have a hard time convincing their boss (and even themselves) to put it into production code. But it's easier to except using beta stuff for code that is not going to production.

In all fairness there is one situation where I see little or even no need for a tester. That is on very small scale projects where the product is very simple or where it's an API or service of some sort. You can probably manage without a tester for some time on these types of projects, but at some stage I believe you would need more than just TDD.

Instead of fighting this battle with the tester, we should help the testers more by utilizing our knowledge helping them to be more effective. Include your testers into your team instead of handing over functionality to be tested, and get it back when it does not work. Include the testers in the planning.

I recommend reading an interview with Jonathan Kohl by J. Bruce Daley about test automation. And you should of course check out Jonathan's blog as well as Bruce's.

Lately I've been shifting focus back and forth between development and project management. 2 years ago I took the initiative to start Scrum where I work, and this has turned out to be such an interesting and demanding process that I'm having problems letting go (not that there is any reason to). During this process I've been reading a lot of books about Scrum, Agile, XP, planning, estimating and so on. All the books I've read has been very theoretical. Most of them were based on experience by very experienced practitioners, but still they tend to be very general in their advice and cautious of telling you how to do things.

Today I was looking at some Scrum resources over at ScrumAlliance and found a presentation by Henrik Kniberg called "The Manager's Role in Scrum" (access requires membership). In his presentation I saw a book he had written (Scrum and XP from the Trenches) and found it freely available at InfoQ. The interesting thing about this book (which I by the way have not read but just skimmed through) is that it focusing on "this is how we did it" on a very detailed level. The nice thing about these kinds of books (or even presentations) is that you might not agree with everything that they've done, but it gives you input like: "we've tried this and it worked!" or "we tried that, but it failed miserably!". And if you're lucky you also get "we think this worked for us because..." or "it did not work very well because..." and so on. You also often discover things that you haven't thought about before. "Ahhh... that's right, why haven't I thought of that?".

I've seen the same things at NNUG where we typically have two types of presentations; new technology, or someone's experience within a certain topic. New technology talks are very interesting and motivating, but often lack experience. Experience based talks are popular because everyone knows the value behind time spent and experience gained, and that this information is given to you for free, helping you do avoid common mistakes.

Hopefully I will get time to read Henriks book soon and maybe I'll post a short review as well.

At Contiki we started doing Scrum in November 2006 and I wanted to post an update on how we're doing, and at the same time look back and see what we have accomplished. Quite a few things have happened since I held my presentation about how Contiki is doing Scrum in February 07 at NNUG. After skimming through my emails from the last 2 years I was able to find an interesting progress on what and when we have introduced the different aspects of Scrum:

• Daily stand-ups/Daily Scrum (Oct 06)
• Daily Scrum in Campfire to improve communication with our offshore team (Nov 06)
• Started using ScrumWorks (basic) as our Scrum management tool (Dec 06)
• Started our first test sprint (Jan 07)
• Read Mike Cohn's book, Agile Estimating and Planning, which I've used as a guideline from that day (Jan 07)
• Started sprinting for real including all meetings (planning meeting, review meeting and retrospective meeting) (Feb 07)
• I got certified as Scrum Master (March 07)
• Started using Planning Poker and www.planningpoker.com (March 07)
• The word Scrum became a buzz word in our company (April 07)
• Our current dev team at the time got split into 3 Scrum teams because the team had grown to big (Nov 07)
• Started having fixed lengths on all sprints to get an accurate velocity (Nov 07)
• Started using release planning for long term planning (Nov 07)
• Started calculating cost based on number of sprints and team resources (Jan 08)
• Our Product Owner got certified (March 08)

It's taken time and we're still not quite there, but I feel we have achieved a lot. Not only that, I also think (and are quite confident) that we have improved our development process enormously.

If you look at the list above we can shorten it down to:

We started with Daily Scrum, continued with Sprints and "ended" with Release Planning.

For me this have been a very logical approach to introduce Scrum to our organization. The easy part was getting the development team to adapt Scrum. You might argue that we spent a long time doing so, but the process has evolved over time (for us that is) and we've adapted the different aspects of Scrum as we felt ready for it. It also has to do with the team getting more and more mature and gaining new knowledge about the process which increases the willingness to adapt new things. I also feel that we did right in not pushing everything at once. We could for instance have started with Release Planning earlier, but we had several good reasons for not doing this. It's also about letting the whole organization getting used to Scrum and it's way of doing things. Getting used to communicating with User Stories and Story Points instead of features, use cases, days, gant charts etc. The development team hasn't changed how they do Scrum for quite some time, but the rest of the organization has needed this time to adapt. The time spent also reflect our learning curve as we have moved forward. The most important thing of all is that the Scrum initiative came from the developers themselves, and not from management, and there was a mutual agreement for us to try this out.

In addition to focusing on the development process of Scrum, we have also adapted many things from XP. As you probably know Scrum does not say much about how a developer should adapt to the agile way of working. Scrum is a management process is my eyes. XP however are very practical and fits nicely with Scrum. You might ask why we decided to do Scrum and not XP? The answer is coincidence. At the time when we started looking at a new process, Scrum had a lot of attention and it was Scrum I started to read and learn about first. Later I found that XP is not as extreme as one might think.

The hard part for us (developers) has been to be effective with TDD or Unit Testing in general. Actually not only effective, but to get "acceptance" from all the developers to spend time on writing tests instead of being "effective" with coding. We have a lot of legacy code (as defined by Michael Feathers; legacy code is code without tests), and making major changes to our application for the sake of automated testing was just not an option. The cost would be to high and our ability to deliver new functionality would have decreased to much. Sometimes I really envy the consultants out there that get to work with new products more often than not. We are however aiming for improving our existing code with tests as we touch the code fixing bugs or creating new features, but this is a long running process.