I found this to be quite a thorny problem recently. I have a fully working Box-Sphere system up and running now though.
My solution was to represent my rectangle as 4 planes. I test the sphere centre's distance from each plane and compare this to the sphere radius to see if there is an intersection (you do this with the framework Plane.DotCoordinate method). At the same time I count how many distances are positive - this is effectively a check to see if the point is in front of each plane. Finally I accumulate the the normals & distances of the intersecting planes to make a single composite 'collision vector' to deal with edge and corner collisions with multiple planes.
Once you have these 3 bits of info you can check a few things:
1) If you are in front of none of the planes, definitely a collision and just check to see which one is intersecting to find which side was hit.
1b) In front of no planes, but no intersections - complete containment. This is the worst case and I cast back a ray along the objects velocity vector to see which side it hit on its way in.
2) In front of the same number of planes as there are intersections. This maybe a collision, but only if the intersection distance along the collision vector is less than the sphere radius. This case actually deals with face, edge and corner collisions (1, 2 or 3+ planes) in one go.
I hope you can follow such a long-description, but the logic is probably more important than the code.
Plus, a major upside of this this approach is it is trivially generalisable to 3D and you can add as many planes as you like to define the collision volume - provided your shape always remains convex. This technique is a version of the pattern often called Discrete Orientated Polytopes - or DOP if you want to look it up in the literature I think.
By coincidence, I am presenting online on Wed 24 March on this very topic for Microsoft UK Tech Days. If you want to see the system in action, see some slides detailing the process above, or ask questions then you can register here.