I just found out that it's possible to restore a database that doesn't exist. That is, create a database directly from a backup. I randomly found that this can be done from the command line, so I looked for it in SQL Server Management Studio. Right click on Databases in the Object Explorer and choose "Restore Database..." Now type the name of the database to create, then choose the backup file.

The great thing about this it determines from the backup which data files it needs to create, so if these are non-standard you don't have to worry about it.

All this time I've been creating a blank database and restoring over it. :-(

I'm hosting a WCF service in IIS, on the same development machine as the client application. I was getting a delay of several seconds in my service calls, and a little message in my output window:

A first chance exception of type 'System.Net.Sockets.SocketException' occurred in System.dll

The framework was just swallowing this exception, and my data come through just fine - except for the delay, that is.

I had to run on the option to break when an exception is thrown (Debug->Exceptions in Visual Studio) in order to get some more details:

System.Net.Sockets.SocketException: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond
at System.Net.Sockets.Socket.DoConnect(EndPoint endPointSnapshot, SocketAddress socketAddress)

The error code is 10060. But I didn't see anything that helped me understand what was going on, even after digging around in the framework. If it wasn't for the delay, I could "fix" it by just ignoring it, which seems to be Microsoft's solution to these swallowed exceptions.

It turned out that the solution was just to turn off the windows firewall, though I never did figure out exactly what was running into the firewall, or why this didn't prevent the call from succeeding.

Also, if I check the "Enable Just My Code" option in Tools->Options->Debugging, then I get no message whatsoever! An exception is thrown and swallowed by the framework, causing several seconds of delay, but with Visual Studio's default configuration, there is no indication during debugging that anything happened.

Based on the MSDN documentation on pack URIs, I would expect that code in my library which references a local resource would use the "local assembly" version of the pack URI:

pack://application:,,,/ResourceImage.png

But that's not the case; code that is in the library has to use the "referenced assembly" version of the pack URI, just like code in the main application which uses the library:

pack://application:,,,/ReferencedAssembly;component/ResourceImage.png

So a relative pack URI is supposed to be relative to the code, but an absolute URI is based not on the code's location, but that of the main assembly in which it runs.

I was using a relative URI when my resources and base class were in the application, but when I moved them to the library this no longer worked. This doesn't seem right, since the image and code that referenced it were were still in the same assembly, and MSDN says the following:

By default, a relative pack URI is considered relative to the location of the markup or code that contains the reference.