vsdbcmd.exe fails with error 0x8007000B

In our setup program, we have recently changed to use vsdbcmd to deploy our dbschema file. I followed the steps in this Microsoft MSDN article on how to deploy vsdbcmd.exe on a machine that doesn’t have Visual Studio installed. However, I kept getting the follow error when I tested the program on a non-developer machine: An unexpected failure occurred: An attempt was made to load a program with an in correct format. (Exception from HRESULT: 0x8007000B). After doing some research, I got it working by following the instructions in this blog article. Basically, you do not need to copy any of the SQL CE libraries or the BatchParser library. Simply copy all the Visual Studio files listed in the MSDN article, then install SQL SMO and SQL Compact on the machine where you run vsdbcmd. That should work.

vsdbcmd.exe gets blocked by its calling process

In my setup program, I was calling vsdbcmd.exe, a very wonderful database tool from Microsoft, to deploy my dbschema file in C#. I used a System.Diagnostics.Process object to invoke the tool, as I’ve always done with calling command-line utilities. And as always, I redirected the process’s output and error so I could display them in my setup log file. Unexpectedly this did not work. My program was hanging, still alive, but hanging. The database was created half way, and vsdbcmd.exe was still live in task manager. However there was no CPU activities from vsdbcmd.exe. After a bunch of experiments, I found out that redirecting the process’ output was the cause of the blockage. Redirecting error was okay. Gah why can’t vsdbcmd.exe work like all the other programs?

Project not selected to build for this solution configuration

If you get this message during compilation, right click on the solution and select Configuration Manager. For the build configuration you have selected, check the box of the project that compiler complained about.

A potentially dangerous Request.Form value was detected from the client

I had a data string that used “<w>” as the delimiter passed into a javascript function from an event handler in HTML, and that was totally legal in .NET Framework 3.5. However, .NET Framework 4.0 detected that as a potentially dangerous value. By changing the delimiter to a string without the angle brackets, I stopped getting the run-time error. I thought that was a good improvement made in .NET 4.0.