Sara Ford posted a blog entry (which I got from the VS2008 Tip of the Day Gadget on Vista) which made me slap my forehead and say "... #$@#! why didn't I find that before."

Pretty much, you can show syntax highlighting for custom file extensions.

When I make build files, I like to name them .build or .msbuild (depends on whether its a NAnt script or MSBuild script).

Previously, I would edit my build script in Notepad++ and set the style to XML for syntax highlighting. It worked well, but I hated having to leave Visual Studio to edit my build file with nice pretty colors.

Now, with this tip (see the link above) I have set my build file extensions to open with the XML Editor.

Here's what I did:

Now when I open the build files I get the pretty colors.

Oh how the simple things impress me at times. I just wish I knew about this before. It just goes to show you that Visual Studio is a very in depth program.

Thanks for the tip Sara!

I'm getting ready to move over to BlogEngine.NET and I was working with the DasBlog Converter that comes with BlogEngine.

To get this tool to work you have to set your feed to something like 1000 items your RSS feed. That way the importer can read the feed, and then pull in everything from there. Well... here's the thing... I set my feed to 1000+ items and left it there on accident.

I use FeedBurner as my RSS feed provider and this week I noticed my feed on google.com/ig/ was showing VERY OLD posts. I couldn't figure out why off the top of my head. After some quick investigation I saw that Feed Burner was returning a 500 Server Error. The feed was too large - it was over 512K.

This was a problem for new subscribers... I couldn't get anyone new because feed burner was rejecting any requests because the feed was obnoxiously huge.

If you have already subscribed to the blog, you would have OLD posts showing up on Google.com/Ig/. BUT.. if you used Google.com/Reader/ or Bloglines, or RssBandit, or anything else, the feed worked as expected. But Google.com/IG/ just barfed on huge feeds.

I cut back the feed and then everything started working like normal. So, if you have weird things happening on google.com/ig/ with your feed, check your feed size!

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