Monday, December 10, 2012

UPDATE: EntityFramework 6 has lots of Resiliency enhancements, but one of the side effects is that this needs a tweak to keep EF from spinning up a transaction around the SQL statement. Essentially, you have to call ExecuteSqlCommand and request that it does NOT ensure the a transaction exists with the first parameter of TransactionalBehavior.DoNotEnsureTransaction. If still running EF 5 or below, omit that argument.

This enables larger files to be uploaded (in this case, 40MB... if your database backup is bigger than that, you have no business hacking around with a LocalDB... get a real SQL Server instance to point at.

If you have the MVC 4 package available, you can use the convenient Crypto.GenerateSalt method as a shorthand as it essentially does the above code.

This, of course, limits the returned string to the Base-64 characters.

When should I care about the contents?

In general, you don't care about the contents of the random string. The one generated by logic above is pretty useful as it is a wide set of all-ASCII characters that will not get you in trouble when crossing code-pages.

The biggest downside of this approach is that the string is only using the a 64 character set, so you're excluding a lot of other possible characters, but in most applications that isn't a problem. In fact, quite the opposite is true. In many cases, we might want to avoid specific characters like the + character because this might be used in a URL In other cases, you might want to generate a fuller character set (or a specific set like an all-emoji string).

A more common need, though, would be if you need to put something on screen for a user to type (such as a registration code) that should not be easy to mistake characters. In some fonts, the characters 1, l and I or 0, o and 0 are very easily mistaken. For such cases, you can use a function like the following to generate a reasonably readable string

Tuesday, November 27, 2012

UPDATE: EntityFramework 6 has lots of Resiliency enhancements, but one of the side effects is that this needs a tweak to keep EF from spinning up a transaction around the SQL statement. Essentially, you have to call ExecuteSqlCommand and request that it does NOT ensure the a transaction exists with the first parameter of TransactionalBehavior.DoNotEnsureTransaction. If still running EF 5 or below, omit that argument.

I have a smallish MVC 4 site with a database. In this case it isn't worthy of a dedicated SQL Server, so I decided to try out the new LocalDb database feature.

While the database isn't particularly mission critical, I would like to be able to easily back it up on demand to allow some level of disaster recovery.