You ever see this when doing Add|New Item in VS 2008?

The details in the Event Log entry spell out the solution to the problem (if not the root cause): (click to enlarge)

Note that running the indicated command from the VS 2008 Command Prompt gives no feedback that it worked or failed:

However, closing and re-opening VS 2008 got me my templates back!

Moral: if a Windows error message makes any reference whatsoever to the Event Viewer, go there.  Read the message.  The devs wouldn’t have pointed you there if they didn’t think that the message contained useful information.

I’m not the only one with this problem. Greg Knierim posted some feedback to the VS 2008 team about what appears to be the exact same issue.

At this point I think I have two options:

1. Assiduously save each .sql file in code page 1200 (Unicode, UTF-16)
2. Write up some garbage script in my custom MSBuild task that saves the input files in an acceptable encoding before SQLCMD gets to them.

Any other ideas?

I’m porting over a project I created a couple years ago in VS 2005 to VS 2008 in preparation for a major front-end upgrade. So far the process has been pretty painless, but have run into huge problems today with my custom MSBuild scripts that build the database. These utilize a series of simple custom MSBuild tasks I wrote such as OsqlFile, DropTable, GrantExec, etc. which have worked darned near flawlessly thus far.

In VS2008, I’m getting exceptions that look like they are encoding-related, such as “Incorrect syntax near ‘X’” (the Greek letter eta), or “Incorrect syntax near “Y” (some double-dotted i character). Totally wild. I tried saving in a couple different codepages with no luck. The SQL runs just fine in SQL Management Studio. I even took the opportunity to upgrade my old OsqlFile task to SqlCmdTask, but no luck. I don’t think the task is even getting called at all — something about MSBuild is working against me here. However, other of my custom tasks (DropTable for one) DO work.

• I’ve checked the encodings in TextPad and both the .build file and the .sql file are UTF-8, no BOM.
• Running the exact same command line as the MSBuild custom task is running (SQLCMD.EXE plus options) works from the VS 2008 command prompt.

So I fired up profiler, and guess what? Look here:

Those little BOMs (I assume that’s what they are) that start with the “greek eta” character are getting passed in from MSBuild to SQL Server, via SQLCMD. Strange that the same command works outside of MSBuild.

So I attempted to force SQLCMD to use the right codepage with the -f 65001 option, which didn’t work. However, forcing VS 2008 to save the .sql file in codepage Windows 1252, and forcing SQLCMD to use 1252 via the -f option, worked!

What a hunk of junky junk. How about a little piece of code, like 10 lines long, that mediates codepage conflicts in EVERY piece of software. Hm….

Real odd: TextPad 5.1 is still showing the .sql file as UTF-8 encoded, even though it’s Windows 1252. Also, TextPad never showed me the BOMs in the original 65001-encoded version.

UPDATE: it turns out that if I save the files as Unicode codepage 1200 both SqlCmd.exe and Osql.exe work, no matter what I set the encoding to with the -f option.  Both -f 65001 and -f 1200 work against those files.   TextPad is now reporting “Unicode” encoding instead of “UTF-8″ encoding.

UPDATE 2: I find encoding stuff to be about as fun as flossing.

I have a VS 2005 solution that I just converted over to VS 2008 using the built-in Conversion Wizard.  This starts automatically when you open the VS 2005 solution in the 2008 IDE.  I run as a local Administrator and so I didn’t have any problems with the conversion.

However, a couple unit tests are failing.  One is a simple sort test to make sure that in-place sorting returns the same results when you sort on a field that has the same value across both collection items.  For example, sorting the input collection

{ “A”, “foo” }

{ “B”, “foo” }

by the second column should return the same list in the same order.  What is actually happening is that the list is reversed.  All of my CompareTo() calls in the body of my custom Sort() class return zero when I step through the code, but for some reason the framework is seeing fit to swap my items anyway.

This test worked in VS 2005 / .NET 2.0.

In the Microsoft Silverlight 1.1 SDK Alpha September Refresh there’s a note in the welcome.htm file that says:

To enable intellisense in Visual Studio, place the Silverlight.xsd in your visual studio Xml directory.

This sounds familiar: intellisense gotchas were something everybody tried to figure out in VS 2005. I’m guessing that the proper directory is:

c:\program files\microsoft visual studio 9.0\xml\schemas\

.. since I see a ton of other .xsd files in there.

How do you know if you’ve copied it to the right location? Fire up the sample solution SilverlightControlsStarterKit.sln that came with the SDK in the \tools\ directory. Open the Page.xaml file. WITHOUT the .xsd in the right location, you’ll see an error like this. With the .xsd in the right location, that Intellisense error goes away.

I installed Visual Studio 2008 Professional this morning. That installation went without a hitch. Just now I installed the Silverlight 1.1 Tools Alpha for Visual Studio 2008, which Scott Guthrie let us know about a couple weeks ago.

To test, I created a new Silverlight C# project in VS 2008, and built it. Immediate problem:

The type or namespace name 'Windows' does not exist in the namespace 'System'.

Thanks to Google, I found a forum post from samsp that pointed out the problem: I didn’t have the Silverlight 1.1 Alpha Runtime (September Refresh) installed. This required an uninstall of the Silverlight 1.0 runtime, which was easy.