Software Developer Browser and Plugin Choices

Firefox
I do a lot of Asp.Net development and I use Firefox as part of my development toolkit when diagnosing performance and design issues with any website I'm working on. I'm not going to touch on various methods of developing a website as I feel that's akin to trying to change someone's religion. Most of the tools I use however are software development platform choice independent.

Firefox really shines as a development tool when you start utilizing some of the powerful developer-minded plug-ins that are available. I'm going to take the long view of some of these plug-ins in this post then drill down into some of the various features of some of the more comprehensive tools in future posts.

Yahoo! YSlow: I love it when powerhouses like Google, Yahoo, and Microsoft give back to the developer community by providing some free and useful tools. YSlow is a monster albeit a well designed one in that it's features aren't invoked until you ask for them thus keeping your average browsing experience relatively quick. This tool is indispensable for analyzing website speed bottlenecks and consequently design (layout) issues. Yahoo's YSlow relies on another must-have tool Firebug. Again, I will go into much greater detail about these tools soon but if you're not currently using them I highly recommend checking them out. They will make your website development a brighter world and neither are specific to Asp.Net.

Skynet's HTML Validator: Even if you're not a standards compliant centric developer (shame on you) this tool is invaluable. There have been countless times I've run into a layout or design flaw that I couldn't figure out even with FireBug. Sometimes the issue is, quite simply, that I have an artifact in my outgoing XHTML that is propogating down the DOM model to create very undesired results. The HTML Validator is a great tool for catching these flubs.
If you are a standards minded developer and strive to add the...

(or similar compliance) logo to your website then this tool offers huge time saving by bring the validation service to your local machine via Firefox.

Colorzilla: This is a handy tool for fetching HTML color codes in various formats. Although not a power tool in terms of performance analysis I couldn't live without this tool and use it daily.

LiveHttpHeaders: When I need information on what is being posted/received in the HTTP headers this is where I go.

IE Tab: Although I do my personal browsing and development testing in Firefox my target audience is typically an Internet Explorer browsing crowd. This tool is great for switching your gecko rendering engine over to IE to take a look at what the customer will see. I'd rather not load up IE 8 just to take a look at each web page I've designed to make sure it looks the same as my Firefox page, this is how. Also, if you've ever been to an ActiveX dependent web page, having filled in form information only to get stopped because the page requires IE, this is a great way to switch over, refresh the page and not lose everything you've typed in up to that point.

FireShot: I use this extensively for documentation provided to clients of the websites I'm working on. The ability to grab complete screen-shots of a web page, not just the portion visible on the screen/browser, is invaluable. It also provides powerful annotation/editing tools to make documentation simple and easy.

ShowIP: A nice quick tool that keeps me from having to dig up the IP Address of the server I'm working on.

Extended Statusbar: This is a useful one-stop shop for page download and render times.

Clear Cache Button: O.K., not really a developer tool but install it and try living without it. Often I need to clear the browser cache to ensure I'm looking at my last minute development changes.

Google Chrome: While Firefox will probably always remain my workhorse for development testing and debugging sometimes I need a light-weight browser just to take a quick test run through some code changes. Please note: Firefox is a very lightweight browser until you load a ton of plug-ins into it. As a contract software and web developer I do a lot of work on laptops when I'm not at home. When I'm working on a less than hardy development workstation such as a laptop I'll use a default, no frills,  install of Chrome to view and test website changes with. It carries a much lighter footprint than Internet Explorer of course, while also providing me with glaring design flaws under the WebKit rendering engine. The WebKit rendering engine is also used by Safari so if you don't have a Mac lying around somewhere this is a simple and easy way to get a look at what your Mac based audience is typically seeing. Please note that Chrome and Safari do not run parallel compliance to the WebKit versions so Chrome is not a replacement to Safari targeted development. So, until Firefox (or a plug-in) makes profile switching a breeze, allowing me to mindlessly run a stripped down version or bloated version of Firefox with ease I will continue to have a place for Chrome in my toolkit.

That's all for now. Soon I will do a much more detailed write up of FireBug and YSlow.

FIXED - Cannot eliminate warning VSP2013 when Code Coverage is enabled in TeamBuild builds

Code coverage instrumentation warning while processing file [Your Assembly]
Warning VSP2013 : Instrumenting this image requires it to run as a 32-bit process. The CLR header flags have been updated to reflect this.

This is something I ran into while writing unit tests for a project. The error pops up when you have code coverage enabled for your unit tests.

Workaround:

1) Open the project properties of the assembly you are instrumenting.

2) Go to the Build tab.

3) Make sure the combo configuration selection is set to the Debug (or equivalent) configuration.

4) Set the "Platform target" to x86.
Note: This sets the assembly to be compiled specifically as 32 bit but only the debug assembly so you do not alter the output of your production, deployment assembly.

This will remove the warning when you are performing code coverage on the debug version of your assembly.

Hermes Java File Uploader for Asp.Net Multiple Large File Uploads with Resume Capability

I needed a control that would upload multiple, large files (100+ MB), resume on error AND allow me to "catch" the uploaded files in C# code so I could perform my own manipulations, and I needed it fast. Hermes Java File Uploader was the answer, the only answer.

Here I am working on this web site for my current contractor and we determine that we have a need for uploading large files to the web server via. a public web page. In years of Asp.Net development I have actually never ran into this requirement on a website. I was lucky. This sounded to me like a very common task requiring a simple solution even though I had never come across the need in my development endeavors.

I was wrong.

The Asp.Net built-in methods for uploading large files is lacking at best. While the provided FileUpload may be sufficient for small uploads and certainly simplifies uploads from previous .Net versions it's not suitable for large file uploads, resuming interrupted uploads, or managing multiple uploads effectively.

The age old question comes "to develop, or not to develop". I started reading into the problem, and concurrently pricing 3rd party controls. To my dismay, while researching pure Asp.Net upload controls that would effectively solve all of my requirements I determined only one thing - such a thing doesn't exist! Well, that put quite a damper on my hopes of writing some quick elegant control in C#/Asp.Net that would handle all of my needs. Time is always of the essence and I just don't have the time to pull off a RYO control of this scale on the fly, especially with no samples of other people's working controls on CodeProject to get me started.

I swallow hard and realize I'm going to have to enter that scary untrustworthy world of JavaScript for my solution. I tried a few controls of varied prices and nothing really sat very well with me. Then I came across the Hermes Java File Uploader control.

I was instantly a little more comfortable with a Java control vs. a JavaScript control for obvious reasons.

The requirements I discovered I actually needed as I tested various controls were the following.

• Be able to browse the user's local file system and select multiple files easily.
• Manage selected files easily - add to, remove, etc. before clicking the upload button.
• Resume a broken upload no matter what happened, user clicks the back button AND says "Yes, I'm absolutely sure I know exactly what I'm doing even though we're at 99% complete on my upload" -or- my dedicated server which I manage that NEVER goes down because of an oversight on my part spontaneously combusts thus breaking the download through no fault of my own.
• Handle very large files up to a possible 100 MB.
• This is the kicker - be able to upload the file through the control but pass the handling off to C# code where I can further massage the upload.

I've got to admit by the time I found the Hermes control I was a bit jaded and getting that distant churn in my stomach that this wasn't going to be possible without some kind of Enterprise Solution intervention. We all know if you slap the word Enterprise on something the price jumps $10,000. So I start fumbling around with the Hermes control and instantly I'm uploading multiple files, breaking connection, resuming, handling large files and then I get to the killer. I need to catch the upload in C# code. I found Hermes because of this capability while Googling so I start looking at their provided Asp.Net page.

It didn't do what I wanted right away. I should preface this with the fact that I am Java retarded and have about 2 hours of Google knowledge on how uploads work behind the scenes in Asp.Net. Which, in reality, isn't Asp.Net specific at all and is pretty much the same old HTML way of doing things with not much wrapping going on.

I try to smash round peg into square hole for a while and realize I don't know what the heck I'm doing so I contact the guys over at Hermes and this is where I'm blown away. I explain what I'm trying to do and the crunch I'm under, "please help me asap". I get a reply immediately telling me to try a couple of things so I do and it's still not working. I eat a big fat slice of humble pie and email back explaining how Java and Upload challenged I am and that I'm really in a bind and this control just has to work because there's nothing else even close, it just HAS TO.

Their team emails me back and suggests this: We open up an FTP account for them to access my server and they will take a look at what's going on, find the issue, fix it, upload it, solve it, and email me back when they're done. My jaw hit the floor. In 12 years of software development I can honestly say: never. Not only did they do exactly that but it was done that day!

You know what, this is a shameless plug for the Hermes team and their control. It's the least I could do for the unbelievable support and solution they provided. It's also not hard to get behind a control I'm using and very happy with. Kudos to Marek and the development and support teams over at Hermes for going light years above and beyond the call of duty to help out a single customer who incidentally was purchasing the cheapest version of their control.

A note for Asp.Net web developers. One thing that we did run into that I was unaware of... If you're going to be uploading large files to your website you will need to change a setting in your web.config to account for this.

HttpRuntimeSection..::.MaxRequestLength Property

I would suggest setting this in the code behind file where you "catch" your uploads.

The alternative is setting the value in your web.config file as found on MSDN. Making this a global setting in your web.config is probably not wise however and you should at least constrain the setting to a specific location on your website as a precaution.

Thanks and happy uploading.