Argh! Nearly an hour wasted,

I was building a source tree today for a new TFS installation and in the middle of my workday VS2005 decided to puke on the screen. It straight up died, froze, hung, whatever you want to call it, it was gone and it wasn't coming back. I was forced to kill the process after taking a 10 minute break and seeing it still hung.

Prior to the crash, the solution built fine. The solution had 32 projects in it and everything was running smoothly. After the crash I restarted VS2005 and then re-built the solution. VS2005 BARFs on a file.

The error I get is something like this:

"metadata file could not be opened (... file path ..) -- file is corrupt"

Huh? So I try moving references, adding them, deleting them, changing namespaces, changing dll names, everything.

I then try to open up the DLL in Reflector and I get the gem:

"File is not a portable executable. DOS header does not contain 'MZ' signature"

What? This solution just build 5 minutes ago, I didn't change anything except a crash.

Well, apparently when the crash happened, that particular project GOT HOSED, BAD. Who knows how, who knows why, but it did. I took a back up copy, replaced it on top of that project and rebuilt the solution and like magic it starts working again.

So, if this happens to you, just drop the project get another copy, then re-add it and hopefully it works. I hate giving these types of answers, but unless I go digging into the root cause of the crash (would could take forever in a project like VS2005) I wont know what exactly caused it. CRAPPY MAN, CRAPPY.

Moral of the story: This takes it back to the "K.I.S.S." principle. I spent nearly an hour trying to fix this problem by tracking it down and moving things around, troubleshooting, etc. I should have just tried the "replace" first and I would have saved an hour.

So, Next time...

Keep it simple, stupid.

I recently help set up a CI (Continuous Integration) environment using CC.NET (Cruise Control.NET) at a client that I'm at. We're in the process of implementing TFS (Team Foundation Server) but until some red tape is cleared we're still stuck on VSS (Visual Source Safe).

While setting up the environment we were given a test VSS account to work with until everything worked as expected. Well the user they gave me had a blank password.

Example -

User: ccnet Pass: (no password)

The visual source safe source control block looked like this:

<sourcecontrol type="vss" autoGetSource="true" applyLabel="true">
   <executable>C:\Program Files\Microsoft Visual Studio\VSS\win32\SS.EXE</executable>
   <project>$/CCNET</project>
   <username>ccnet</username>
   <password> </password>
   <ssdir>c:\repos\</ssdir>
   <workingDirectory>c:\myBuild</workingDirectory>
   <culture>en-us</culture>
   <cleanCopy>false</cleanCopy>
</sourcecontrol>

When I fired up the CC.NET Service, everything started off fine. The project said "Checking For Modifications" and then it HUNG there, forever. It never stopped. I had to stop the service and then kill SS.exe (source safes process).

Solution

The reason this happened is because of this line:

   <password> </password>

The password was left as " ". It was a space. If I fired up VSS and typed in ccnet and put a space into the password, it would let me in, no problem. But if I did that with CC.NET SS.EXE would hang.

Pretty much, here's what's happening - Source Safe is firing up and its trying to log in and its giving an invalid password. SS.EXE is trying to raise a dialog box, but its running under the context of the Cruise Control.NET service, therefore it cannot open that dialog box.

I changed the password field to this:

   <password></password>

and then it worked flawlessly.

Simple solution to a simple mistake. :)

I'm not going to lie, I'm a NUnit guy. I've used it for years. But just recently I've decided to start using MSTest. I run Team Suite and I've been using it for some basic integration and functional tests, but not full on TDD. Well this weekend I embarked on a task that utilizes full on TDD and I decided to make the jump and try to do it with MS Test.

So the first thing I had to do was reference and import Rhino Mocks. I then ran the test real quick (I had a test that did not depend on mocks yet) to make sure nothing in the import broke it (it shouldn't, but hey, I'm ADD when it comes to this TDD business). To my utter amazement, something broke. I was seeing red.

This was the beautiful error:

Microsoft.VisualStudio.TestTools.TestManagement.ExecutionException: Test Run deployment issue: The location of the file or directory '(path omitted)\main\Source\SharedBinaries\Rhino.Mocks.dll' is not trusted.

WTF? It's on my local machine. It's not a file share, hell, its even included in my project in my SharedBinaries folder. WTF MAN!?

After some looking around, I was able to figure it out.

If you download a DLL from the Internet, or get it in an email or where ever and you saved it to your disk (including a DLL in a zip too) it has some extra info attached to it called an "AES" file. (see my reference below for more info)...

To fix this annoying issue, go to the DLL, right click and then click "Unblock". See the screen shot below. Once that is done, your test will work.

Source: MSDN Forums

It's common to see a developer use a StringBuilder or basic string concatenation to concatenate strings in .NET code.

You'll usually see something like this:

string comma = ",";
StringBuilder sb = new StringBuilder();
sb.Append("Donn");
sb.Append(comma);
sb.Append("Felker");
sb.Append(comma);
sb.Append("Jiu-Jitsu");
sb.ToString(); 

And this will return "Donn,Felker,Jiu-Jitsu"

But the .NET framework has something built in just for doing this type of operation.

Its called the CommaDelimitedStringCollection and it's located in System.Configuration namespace. What it allows you to do is to add items to a collection and then just access the "ToString" method of the class to return the value of the collection, delimited by comma's.

Here it is, in action:

CommaDelimitedStringCollection coll = new CommaDelimitedStringCollection();
coll.Add("Donn");
coll.Add("Felker");
coll.Add("Jiu-Jitsu");
coll.ToString();

This will return "Donn,Felker,Jiu-Jitsu".

Much easier, much nicer.

Enjoy.

As developers we're constantly inundated with requests like this ....

• Can you add a button that does does ________
• On this screen _________ I need to have a chart of ________ displaying data ...
• I need a report that shows me _________
• Can we add _______ to this page?
• It shouldn't be too hard to add this, its just a field on the screen .... (then they explain what its supposed to do)...

(classic scope creep)

Prioritization

The order in which a developer prioritizes items in their "todo" list is often determined by the urgency placed on them by their direct managers (or higher ups). More often than not we find a high level executive or decision maker wants a feature implemented because they "think" it will add value to the product. Again, more often than not, the executives theory of how this feature is a viable request has no data to back it up. Therefore a feature is implemented with no verification that its a needed or requested feature. Please remember, this doesn't always fall upon the shoulders of the decision makers... as developers we're enamored with making things sparkly and shiny. If we think of a cool new "hot key" that we can add to our app, we'll do it, even though it might take four hours to implement, we're confident it will be the feature that saves the world.

Uhhhhh, Nope. Afraid not McFly.

What's the root of the issue?

We need to ask ourselves a simple question....

Question: Is this feature a vitamin or is it a prescription?

Before we can answer this... lets look at some simple definitions...

Vitamin - A supplement that helps you, its good for you, its nice to have, but its not required.

Prescription - Medicine that helps you. Its required, it helps you survive.

 

Answer: It depends. (the classic developer answer... well... it depends... :)   )

The Process of the Request

When an feature request comes in you need to ask (as well as the client who requested it) ...

Is this feature/request a Vitamin or a Prescription?

This is the same as asking...

Is this feature request a "nice to have" or a "requirement to survive"?

This is going to determine if the request is worth putting into the system immediately. If you have 10 tasks, ask this question ten times and  you might some up with something that looks like this:

(This mimics a fake Online Order Management system - for example purposes)

As you can see, we see that everything on the LEFT is a requirement for the system "requirement to survive" (prescription). Everything on the right is a "nice to have" (vitamin).

We may need graphs of data, but we don't need 3-d graphs. We may need Web Access to the Order Management System, but we don't need a Silverlight implementation to get this project to work. It would be "nice to have" a Silverlight implementation, but its not required.

Conclusion

The next time you're asked to implement a feature, ask yourself...

Is this a vitamin or a prescription? Then put it in that bucket. Then, once that's figured out, go into the prescription bucket and prioritize those upon business requirements. Then, when you've taken all of your prescriptions (all of those items are complete), ask yourself if the "vitamins" are going to add value to the project. if they are, then ask that question again (is this a vitamin or a prescription).

This ultimately comes down to an agile type of development process. We should only be implementing the things that add value and that are required for the app to serve its purpose. Most of the time a lot of these "Vitamins" will never make it into the system because its just not cost effective or necessary. Eventually some vitamins will make it into the system and sometimes its these Vitamins that make your system a step above the other systems, but this cannot be established until you've taken all of your prescriptions. If you're sick and bed-ridden, you can't take muscle vitamin supplements to get muscles big. You have to take the prescription to get well, then you can take the muscle supplements to get muscular.

Next time you get ready to implement a feature/request - ask yourself ...

Is this a Vitamin, or a Prescription?