I’ve been playing about with Azure at work recently to test it out and see if it will work as we need for clients. For the most part it has been blindingly easy to set up. But one thing I had a few issues with was migrating my SQL data to SQL Azure (on the Azure platform there are 2 database types, rather helpfully named Windows Azure - which is a noSQL database and SQL Azure - which is based on SQL server).
As we have developed a site using Umbraco, we wanted to package the database and just restore it on Azure. You can connect to SQL Azure by SQL Server Management Studio (if you do, be sure to install SSMS 2008R2 as 2008 will not work properly) but you can’t backup and restore an Azure DB using this method. Enter the SQL Azure Migration tool, which is very simple to use. You connect to your SQL server, choose your database, then connect to your SQL Azure instance and select which DB you want to restore to. Easy life. One gotcha though: You can only restore SQL server 2008 R2 database. If you try an older DB you will get errors, so try and upgrade before even considering Azure.
Today I was working on a generic method which gets a querystring and converts it. If the querystring exists, it would convert the type and return it. However, I’d also need to return a default if the querystring doesn’t exist. As it was a generic method, I couldn’t rely on just returning a null as if the type was an integer, this wouldn’t work (assuming not a nullable integer).
I disovered this nifty little method though:
returndefault(T);
Lovely, it will then respond appropriately, if an integer, it would return a 0, if a string, a null.
AAAAAHHHH! This fix, I hope, will save you a lot of time. Recently we have been upgrading some clients to the latest Sitecore. Generally that works fine, however, on re-compile, then running the application, I get a nasty StructureMap Exception Code: 202 (we use this lovely little nugget for IoC). Panic ensues. You check everything, it’s all in place. You check the Global.asax in Visual Studio (where we kick off Structuremap and any application wide methods), it has all the code there. And there’s the problem. Visual Studio opens global.asax.cs by default, which is correct really, code should really only be in there. However, if you open the global.asax file in your favourite text editor, you see the issue. Sitecore replaces the global.asax file with a default, which has default, empty code and methods in it! It looks like:
<%@Application Language='C#' Inherits="Sitecore.Web.Application" %>
<scriptrunat="server">
public void Application_Start() {
}
public void Application_End() {
}
public void Application_Error(object sender, EventArgs args) {
}
</script>
What this means is, although Visual Studio sees all your code in global.asax.cs, that code is not running because it isn’t even referenced by the global.asax in the first place, it should look something like this instead:
Recently, one my team mates discovered the TestCaseSource attribute in Nunit 2.5. I have been using the TestCase attribute for a little while. It enables you to tes multiple inputs with one test:
This is useful for various reasons, mainly that you don’t have to write a separate test for each input. TestCaseSource is a different way of doing this by allowing the user to build up an IEnumerable of test cases and just add that to the test.
While working on a site recently, I noticed that trying to get to the Desktop version of Sitecore, it would get stuck just in a request state, nothing happening. This was always after logging in, the Sitecore login page itself worked fine. It would also not log any issues in the log files. The thing that fixed it was to make C:\Windows\Temp a writable folder for the IIS user. Almost immediately it worked. Phew!