MSBuild, Visual Studio and 64-bit Windows == Huh?

So this is kind of lame. Let's say you've got a web app in VS on a 64-bit version of Windows. Everything's all good and you decide that instead of building from VS you now want to build the project directly from MSBuild, either by pointing at the .sln file or the .csproj. Should just work, right? Wrong.

Your build will fail with this:
"The imported project "C:\Program Files\MSBuild\Microsoft\VisualStudio\v9.0\WebApplications\Microsoft.WebApplication.targets" was not found."

You see, there's an element inside of your .csproj that looks like this:
<Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v9.0\WebApplications\Microsoft.WebApplication.targets" />

This apparently pulls in some additional targets that MSBuild needs to do its thing on web apps. Unfortunately, when running MSBuild from the command line on a 64-bit maching the $(MSBuildExtensionsPath) variable refers to:

C:\Program Files\MSBuild

but the stuff that it's looking for only exists in the 32-bit version of this directory at:

C:\Program Files (x86)\MSBuild\

Let me just say right now that:
1. I have no idea why this isn't an issue when building in VS. I believe it's still using MSBuild to execute, but maybe the variable is being correctly set to the 32-bit program files directory in this case. Or maybe it's running a 32-bit version of MSBuild?!
2. Why this stuff only lives in the 32-bit program files directory. The other directory exists but it only appears to house some WF stuff.

Anyway, I found an MS Connect report (from 2006!) on it but they're claiming that it's "by design" and not a bug. Their proposed work-around is simple, but really lame - copy the files over into the x64 program files directory. Like I said simple, but lame.

Here's the link: http://connect.microsoft.com/VisualStudio/feedback/details/109232/msbuild-msbuildextensionspath-returns-invalid-path-on-x64

I copied the stuff over and it did seem to solve the problem, but we'll see what sort of downstream issues come up later when some installer isn't expecting 32-bit versions of that stuff to be sitting in there...

Not impressed on this one MS.

♦Add to del.icio.us ♦DiggIt! ♦Reddit ♦Stumble This ♦Add to Google Bookmarks ♦Add to Yahoo MyWeb ♦Add to Technorati Faves ♦Slashdot it

The exquisite pain of obscure framework bugs

In hopes of preventing someone else the agony and wasted time I just suffered...

It appears that there's a bug in linq-to-sql with .SubmitChanges() not saving anything. If you implement the "extensibility method" for insert on any of your entities the SubmitChanges silently fails. Actually, I don't know that "fail" is the right word. It simply doesn't save the newly created entity.

Again, the source of the problem is that the insert (i.e. partial void Insert) in your DataContext. For every entity you have the data context will have Insert, Update and Delete methods. E.G.: if you have a Foo entity in your model, the DataContext will get partial void InsertFoo(), partial void UpdateFoo() and partial void DeleteFoo() methods that get triggered when each respective event happens. The only problem is that (at least with the Insert version) if you actually implement this partial in a corresponding partial DataContext class it will *prevent the action from actually happening*.

I don't know why and I don't know the work-around. Perhaps when I have a minute I'll circle back around and try out the Update and Delete versions to confirm the behavior there as well, and maybe try to figure out what the heck is going on.

I hope this just saved you several hours of debugging!

♦Add to del.icio.us ♦DiggIt! ♦Reddit ♦Stumble This ♦Add to Google Bookmarks ♦Add to Yahoo MyWeb ♦Add to Technorati Faves ♦Slashdot it