TFS: The download file is corrupt. Please get the file again

Came across this while working on a whole bunch of CI stuff....easy solution is to clear cache on the client and server.  FWIW, I cleared cache on the client and it didn't do anything...you may not need to do both ends, but it won't hurt, either...

Delete the contents of these directories:

Client: 

C:\Users\[UserName]\AppData\Local\Microsoft\Team Foundation\4.0\Cache

Server: 

C:\Program Files\Microsoft Team Foundation Server 11.0\Application Tier\Web Services\_tfs_data

WCF 4.0, IIS7 / 7.5, HTTP 404

Wow, that was fun. I just spent a solid two hours trying to get my pretty new WCF 4.0 service running, using the online REST template on IIS7.5. It worked without any isssue in the debugger, and, let's just say the error messages were less than helpful. Failed Request Logging, well, didn't log any failed requests. The solution? Run the following:

C:\Windows\Microsoft.NET\Framework\v4.0.30319>aspnet_regiis.exe -i –enable

C:\Windows\Microsoft.NET\Framework\v4.0.30319>ServiceModelReg.exe –r

Important Note....This may modify your existing app pools to use .NET 4.0. Check them immediately after running the above commands!!

Enjoy.

Ah, there was a time early on during the days of classic ASP when I absolutely despised JavaScript.  I'm not sure if it was because my untrained eyes invariably missed the periods, or my clumsy fingers were not used to the case-sensitivity, or...I just didn't quite "get it".  Actually, it was all of those things.

More time passed, I became slightly less naive when it came to programming.  More importantly, all the AJAX hype came to the forefront.  I found myself using JavaScript for more than just elementary client-side validation functions.  I suddenly realized I had to actually learn the language that I fostered such hatred for.  LEARN?!

Fast forward a few years...I can't really believe I hated JavaScript as much as I did.  JavaScript is a language that is sort of like single-malt scotch.  Totally disgusting if you aren't sure what you want.  Exquisite in every way if you do.  I do a good amount of work in JavaScript these days...both using pure JS and jQuery-magic when appropriate.  More often than not I'm writing some AJAX functionality to manipulate the DOM based on some response I get from a service/DB/dolphin/etc.

I've come to realize that it's easy to write a function, especially in JS, that is cumbersome and not-at-all conducive to being re-used.  A while back, I wrote a function that looked like this:






So, what is wrong with this picture?  It could be worse, right?  I'm passing in the ID of the DOM element that contains, in theory, the e-mail that should get subscribed to updates.  I run that through my ValidateEmail() function.  If the e-mail isn't valid, I go ahead and hide the success DIV, and show the error DIV..and vice versa.  What? It's clever, isn't it?

Sure. It's great...until a month later you need to use my function and come to the startling realization that the way I wrote my function forces you to have specific elements in your DOM.  A damn shame, really.  Let's count how many things I see wrong with this method:

1. It forces the caller to pass in an the IDs of DOM elements.  What happens if I want to pass by class?  The hard-coded "#" screws everything up.  This applies to all the parameters.  If I was going to do this at all, I should have passed selectors.

2. The function leaves me no choice but to have a DOM element for a valid e-mail address, as well as a DOM element for an invalid e-mail address. It's also not at all obvious what those DOM elements accomplish.  I happen to know the DOM elements contain validation success/error messages, but someone else wouldn't immediately know that.

3. Even if I have DOM elements for "success" and "error", I'm modifying the display attribute of my CSS.  What if I'd like to toggle a class instead using addClass()?

In summary, then, I am stupid.  But more specifically, I was entirely too short-sighted when I created this function.  Sure, it's just one lousy JS function.  It serves its purpose.  The issue is, it really only serves its purpose given very specific constraints.  This is far less than ideal.

Let's take another crack at this function and see what'd it look like if we incorporate the corrections I allude to above.




Okay.  That's a little better.

Now I can pass selectors instead of be bound to passing only DOM IDs.  I have also used the jQuery CSS(cssObj) method.  This let's you pass a JSON object that is essentially a list of your CSS Attributes and their values.  For example, the value of the successCssObj might be this:



At this point, you're probably wondering why I ignored problem number 2, above.  The caller is still bound to having a "success" and an "error" DOM element.  I could get around this downright silly requirement in a few ways.  I could easily check if I've passed a selector in for the "successSelector" and the "errorSelector", and proceed to modify their CSS if they exist.  But why bother?  That's ugly, it's more code, and it's just going to confuse the crap out of me when I come back to this in another month.

There is an easier way

And that way is by using callbacks.  If you've used jQuery, or any of the other popular JS frameworks floating around, you've been using them already without even thinking about it.  When you call $ajax in jQuery, you're providing both success and error callbacks.  Basically, you're optionally passing in a function you'd like to execute if an error occurs, and a function you'd like to execute if no error occurs.  The key here is you're passing in the function to execute, and the function contains the logic you to run given a certain condition (An invalid e-mail, in this case).  This means that my function is only responsible for doing what it is named....Subscribing an email address for updates.  It doesn't care about the caller's DOM, and it sure as hell doesn't care about CSS.  My function doesn't even like CSS.  Let's take a look at this glorious function after a makeover.



There we go, and we've even made the successCallback and errorCallback parameters optional if we'd prefer not to pass either or both of them.  As promised, we've totally separated the caller's context from the objective of the function.  Let's take a look at an example of calling this function.  Again, this will look very familiar to you if you're used jQuery.  That's a good thing.




There's a reason jQuery and other libraries are created in this manner.  It makes it much easier to reuse your code.  The combination of using callbacks and optional parameters really inspires a shift in the way I analyze requirements and code methods in general...especially in JavaScript.  Furthermore, it doesn't increase complexity.  If anything, it is easier to read methods when they truly have one purpose.  You don't want to force any method caller/client to have additional requirements, be it DOM elements or anything else.

Error Handling in ASP.NET MVC 1 [Part 2 of 2]

In the first post in this series, I provided a little info on the HandleError attribute in MVC 1.  In case you don’t want to flip back, the HandleError attribute can decorate a method or a class and will push your users to a generic errors view provided customErrors is “On” or “RemoteOnly”.  There’s a little more to it, but that’s all the background we need for this post.
The out-of-the-box HandleError attribute works well, until you’re in a scenario where you need to do more than hide your errors.  Typically, you may want to do some logging or fire-off some alerts.  Now, as luck should have it, I did some searching before writing this up and Danny Tuppeny already has a great post on this very subject…I encourage you to take a peak at his post, as I’ve provided a very high-level, yet functional summary below.
The facts are these…
- System.Web.Mvc.Controller contains an OnException method that gets fired when an exception occurs [provided custom errors are On/RemoteOnly in the web.config]
- The OnException method can easily be overridden, allowing you to either completely change behavior or add behavior (by calling base.OnException)
- This method will fire regardless of whether your class or method is decorated with HandleError
This means that your could will look like this:



To get the above code to work you’d simply make your controller inherit from ControllerBase.  Of course, you’d likely have additional utility-methods in this class that you’d need in multiple controllers.

Lines 17 and 18 can be used to push the user to your error view after you execute the DoSomeOtherStuff() method – this would not require the HandleError attribute.  Alternatively, you can execute System.Web.Mvc.Controller’s OnException by calling it explicitly as it’s done on line 21.  In this case, the HandleError would be required to push your use down the custom-error path you’ve got configured.

And that’s pretty much all there is to centralizing & customizing your error-handling in MVC 1. 

If you came from somewhere else, you may want to take a look at part 1...

Error Handling in ASP.NET MVC 1 [Part 1 of 2]

I’ve been using ASP.NET MVC Release 1 for a bit now, and while it’s definitely not for every application, I happen to like it quite a bit.  There has been a lot of activity on MS-centric blogs regarding MVC, but there are still some really mundane tasks that there could be more information on.  So, this series of posts isn’t going to be anything crazy; it will, however, illustrate what options you have to do centralized error-handling using MVC
We’ll start at the beginning…
The System.Web.Mvc.dll comes with the HandleErrorAttribute class, which contains..wait for it…the HandleError attribute.   This information won’t be important until later in this series, but the HandleErrorAttribute class inherits from the FilterAttribute class, and implements the IExceptionFilter interface – the interface requires a method with the following signature.

public virtual void OnException(ExceptionContext filterContext);

This method is really where the brunt of the work is done when you use the provided [HandleError] attribute.  In case you’ve never taken a look using Reflector, this HandleErrorAttribute’s implementation of OnException looks like this



Essentially, you’re grabbing some information from the ExceptionContext, and you’re using the HandleErrorInfo class to pass this information back to your view.

Using [HandleError] is really as easy as using any other attribute.  You simply decorate your method or class with the attribute and your errors will be pushed to the default view for errors (Views/Shared/Error.aspx)
 Alternatively, you can provide the HandleError attribute with some arguments to specify a view other than the default error-view, or specify a specific view based on the exception type. 

The only other thing you’ll want to make sure you do is ensure your web.config <customErrors> section is configured appropriately.  That is, you’ll want to make sure customErrors mode=”On” to test this out.

Hope this helps somebody; the next part in this series will demonstrate how to add functionality to the existing OnException method that the HandleErrorAttribute class implements, such as logging.

Don't forget to take a look at part 2!

ASP.NET Image / Photo Cropper in C#

For my current project I needed to create some logic for users to upload an image...only problem was the image had to be of a fixed size, and therefore aspect ratio.  Enter the need for an image cropper.  You've seen them before on a number of sites, like linkedIn, facebook, and everywhere else.  I began my journey of trying to find one.  There are a fair amount of tutorials/code snippets on the web that illustrate how to do this from the client-side using JavaScript.  I also came across some articles on codeProject and such as that explained how to crop images on the server-side.  What I couldn't find was an article that tied the client-side JavaScript and the server-side cropping together.  And that's exactly what this article is.
Before I get into the fun stuff...the process is really as follows

    User crops image on the client-side
    Track the X & Y coordinates, as well as the height and width of the box the user drags over the image
    Use the server-side code to actually crop the image [providing the coordinates and dimensions from step 2]

That's really about it.  I should also say that all the JavaScript I used was obtained from http://www.defusion.org.uk/code/javascript-image-cropper-ui-using-prototype-scriptaculous/

It's a slick piece of code - please check out the site for updates (I believe version 2 is a work in progress) and to donate.
As for the .NET code (C#) - you can obtain it from here:

You'll need to make sure that you provide write permissions to the directory where you want to save the new, cropped image.  Check out line 19, where I set the value for the CROPPED_SAMPLE_PHOTO_URL constant string.

Note: The demo and the download work slightly differently.  This is mainly because I'm saving the image to a session variable for the demo, but using the file system in the download.

As for the code, the heart of it is really the CropImageFile method, where you re-draw the image taking into account our coordinates and dimensions.


Enjoy!