I was reading this weeks Code Project newsletter, when I came across an updated article named Versioning Controlled Build. The description so eloquently puts it: "A Visual Studio add-in that automates AssemblyVersion control."

One word, AWESOME! I downloaded the installer from the article, installed it, and launched VS.NET. Talk about an easy way of updating your version numbers for X number of projects. I know this is a daunting task for any developer that has more than 1 project that the version number needs to get updated.

Truly a great Add-In that will come handy for everyone!

Got another nasty bug relating to unsupported characters in VS.NET project files again, today. Unfortunately, my changes didn't handle ampersands, or other of those types of characters, and threw a nasty exception...not good.

Anyway, to test out how these files with ampersands actually get into the project files, I started a new project and was throwing things around. The good news, is that you cannot create a new file from within VS.NET and add it to your project if it contains invalid characters. VS.NET handles this situation very nicely telling you cannot create a file with that name because it contains one of the invalid characers.

The bad thing? Well, you can add an existing file with an invalid character to a project and not receive any error messages at all. Hmm, is that good practice? I don't think so. Maybe they can fix this in the realm (I actually haven't tried it in Whidbey, but my guess is that its probably the same) for Visual Studio 2005.

So, "Awesome Code of the Week"? Yeah, I think you'll agree after this blog post. Let's just say if there was an award for this, I'd take the cake - AND the cake pan.

So what is it? Well, its simply generating PDF reports and emailing them. Woooaah, how cool is that? Not really on its own, however its very cool in the whole process that I'm doing to generate those PDF reports.

History
Our company, over the past several years, have been developing and perfecting a ASP based application for one of our clients. In it, we have built a custom reporting engine that takes XML spit out from SQL Server, translates it into managable XML via another XML translation process, then formats it using XSLT. This process, cool indeedy, was a beast to bring into the .NET world.

One report is generated all the time, printed / and or saved directly from the browser. A new request came across to take this report and have selection of multiple different parameters to generate X number of reports, and be delivered to the user. For instance, you select 3 items from Item A, 4 items from Item B. The user wants reports for all the combinations, so in this instance we have 12 reporrts that are generated. The current report, as-is, cannot handle this, and would take a lot to modify.

The Design
Back in June of this year, we decided that the users would come to a new ASP.NET application (under the realm of the ASP application), make their selections, and a PDF will be created while the users waited. As time went on, we realized that some of these combinations (upwards into the 100s) could take a long time to process.

As such, we had to come up with a new way of handling it. I realized at that point, that it may be best to spawn a new thread, let the user see that the request has been submitted, and then process the reports in the background. Ultimately, it would email the user the PDF report once finished. All was well, and a tremendous time was estimated.

The Coding
This week, I sat out to start this project, I didn't want it to become a daunting task, and then it hit me (or a lightbulb actually turned on in my head (which is very odd (and scary) since who wants a lightbulb in your head)). I realized that the easiest solution was to call the ASP report for each combination, creating the PDF on the fly.

So, there I sat, figuring out how to use WebRequest and WebResponse to POST and retrieve the HTML from the page. Success! I was able to post my different parameters in the format the underlying ASP page knew about, cool.

Next step, creating that pesky PDF file. I ran across several different PDF components, and WebSupergoo provided ABCPdf for .NET that would allow me to stick the HTML into a page, and continue on.

Last steps, zipping up the file and emailing. Now, here's where the tricky part came, not due to complexity of zipping the file, but due to how VB.NET handles declarazations of arrays. Boy, it was pain to figure out that in VB.NET, when you declare an array, you're actually setting the upper bounds of the array, not the size. After about 30 min, I finally figured that out (which is why I like C# so much), things started working again. I used #zipLib to do my zip compression, and all was well. The email got the attachment and was sent out...simple as pie.

Performance Testing
Now, this subject is super tricky in our development environment at work, due to the fact that our development server is a Pentium II 333Mhz with 256MB of RAM. Can you say screeching fast? Well, you couldn't on this machine (we really need new hardware). Anyway, as of the writing of this blog post, I started a combination that will generate roughly 6045 reports, which (if I did the math correct for our dev server with 30 reports for 15 min), its going to take about 50 hours to complete. Wow, is right...do I need to say that we need newer hardware?

The Cool Factor
So, what's cool about this? Well, I'm using an ASP.NET application that spawns a thread to POST a webpage to an ASP application, retrieve its HTML, stick it in a PDF, zip that PDF up, and email it to the user. How fricking cool is that.

Way back when I implemented VS.NET project files as a source for Unleash It, a few users submitted bugs that stated they were receiving error messages when loading their VS.NET project file in Unleash It. I looked into it, and noted that their problems related to non-encoded properly characters in the project file.

Sure, the project files look like XML - but don't get fooled, most of the time they will be valid, but those very few pesky project files will blow the top off of Mount St. Helens (again). It seems that Microsoft decided to roll their own XML parsing engine for reading / writing these project files.

So, onward I went with a temporary fix that allowed me to bypass the few exceptions...then today, another user stated they were having the same problem. What! No! Huh! Yeah, the problem still existed, but this time it wouldn't complain, just throw a nasty error message that Unleash It couldn't handle.

So I turned a new leaf, tried many new different things, then resorted talking to my buddy Jeff Key (who now I owe so many beers that he'll be drinking for free on several occasions). We both cracked down and figured it was something to do with the encoding...hmm, what if we encoded it to UTF-8? Ahh, yes, that works - but now, how can we do this on the fly without modifying the Users' project file? Store the UTF-8 version in memory of course. And so, 5 minutes later, Jeff had a working example of how to do this. I quickly plugged it into my code base...and WAHLA! It works!

So, below is the code to read in a Project file using XmlTextReader that will (hopefully) not cause any problems...

StreamReader sr = File.Open(projectFileLocation);
MemoryStream ms = new MemoryStream();
StreamWriter sw = new StreamWriter(ms, System.Text.Encoding.UTF8);
sw.Write(sr.ReadToEnd());
sw.Flush();

ms.Position = 0;
XmlTextReader reader = new XmlTextReader(ms);

while (reader.Read())
{
    ....
}

reader.Close();
ms.Close();
sw.Close();

One of the things most of us have to do at one point or another, is generate a random password. I once thought this was a daunting task, however found some code at some point or another that gave me great headway into creating a good password generator.

private static string CreatePassword(int lengthOfPassword)
{
     string[] characters = new string[32] {"a", "b", "c", "d", "e", "f", "g", "h", "i", "j", "k", "m", "n", "p", "q", "r", "s", "t", "u", "v", "w", "x", "y", "z", "2", "3", "4", "5", "6", "7", "8", "9"};     string password = "";
     Random rnd = new Random();
     while(password.Length < lengthofpassword)
     {
           // choose a random character from the array and add it to the password
           password +="" characters[rnd.next(36)];
     }

     // return the generated password
     return password;
}

So I just finished competing in the qualification round for Google's Top Coder contest, and well, damn there are some quick coders out there. You basically had 1 hour to code solutions for 2 problems, 1 being worth 400 points and the other worth being 1000 points. Points are based on how fast you submit your code, but are later tested against system tests and code reviews in which they can remove points from you.

Lets just say I got 311 points total (in 14 minutes), and that was for problem 1. Problem #2 was difficult, but I just needed more time than 46 minutes to complete it...I was close darnit! It truly is a test of ones ability to code accurately under a time crunch.

Since the qualification round is still going on, I can't really divulge my problems as it could give other coders out there an advantage against me. 500 participants will continue on (they take 100 participants from each of the 5 different problem sets), so I can only cross my fingers that I advance, however I won't be heartbroken if I don't. I set out merely to see if I could actually code under a time crunch like this, and I feel I didn't do too bad. Other coders out there that actually submit both solutions just amaze me, but who knows if their solutions are correct...only time will tell.

So, wish me luck and cross your fingers for me, I'd really like to get that "free plane trip" to compete in the final round.

So I ran into a bit of a speedbump this afternoon while working on Unleash It. I was trying to add menu items to a sub menu of a context menu for the Notify Icon (boy is that a mouthful to say (and also to write)). Well, it seems that there is a bit of a known bug that isn't broadly stated when creating sub-menu items dynamically...and that is that once you've created them, and try to recreate them, they never appear.

So, after a bit of googling, I came across this thread and determined that the easiest hack around this is to set your sub-menu's visibility to false then to true again. This, of course, was much easier than having to recreate the entire context menu, which is the other proposed solution.

So, if you've never ran across this problem before, make a mental note of this if you should ever happen to want to do something so remotely insane as me, or other people out there that do it as well.