Last night I worked my way through some dev tool updates and happened to install both SQL Server 2014 and the new Azure SDK 2.3. I prefer to host the databases for the storage emulator in my primary SQL Server instance instead of the default LocalDB, and had grown accustomed to running the command-line DSInit.exe tool to accomplish this.
It turns out that as of version 2.3 DSInit is no longer included in the Azure SDK tooling (a fact that might have been useful to include in the release notes 
). Instead, the storage emulator functionality has been unified into a single command-line executable WAStorageEmulator.exe, found by default at c:Program Files (x86)Microsoft SDKsWindows AzureStorage Emulator. WAStorageEmulator includes switches for initializing the storage database, starting and stopping the emulator, etc.
No problem, I think to myself… I’ll just run the ‘init’ command for WAStorageEmulator.exe and point it toward my default SQL instance:
WAStorageEmulator.exe init –sqlinstance .
This immediately resulted in a crash… not very user-friendly. Debugging into Visual Studio showed the problem to be an unhandled ArgumentException… hmm, maybe it doesn’t like the period specifier for the local instance. Let’s try (local) instead:
WAStorageEmulator.exe init –sqlinstance (local)
Okay, no crash this time, but now the process just hangs and seemingly does nothing. Taking a closer look using the totally awesome Process Monitor revealed no major problems with file or registry access.
Stumped, I then took another look at the command line help for WAStorageEmulator:
WAStorageEmulator.exe help init
Which yields this:
Windows Azure Storage Emulator 3.0.0.0 command line tool
WAStorageEmulator.exe init [-server serverName] [-sqlinstance instanceName] [-forcecreate]
Performs one-time initialization to set up the emulator.
-server serverName : Specifies the server hosting the SQL instance.
-sqlinstance instanceName : Specifies the name of the SQL instance to be used.
-forcecreate : Forces creation of the SQL database, even if it already exists.
-inprocess : Performs initialization in the current process instead of spawning a new process. This requires the current process to have been launched with elevated permissions.
Okay, so there’s an option to specify machine name, too… seems like it could figure out that I want the local machine by default, but whatever:
WAStorageEmulator.exe init –server MyMachine –sqlinstance . –forcecreate –inprocess
(I threw in –forcecreate and –inprocess for good measure)
Success! This worked correctly and I finally had my emulator databases installed in my default SQL Server instance. That’s 90 minutes of my life I’ll never have back. <sigh> Moral of the story… tread lightly with WAStorageEmulator in Azure SDK 2.3… it seems slightly dodgy and still has a few rough spots.
Hope this saves someone else a bit of time and trouble.