I have discovered the source of the problem, and a (not such a great) around:
1. The problem is due to the fact that the "Microsoft.Silverlight.Common.targets" file calls a .dll in the same directory "Microsoft.VisualStudio.Silverlight.Build.Tasks.dll" to retrieve the path to the Silverlight CLR assemblies. (That directory is C:\Program Files\MSBuild\Microsoft\VisualStudio\v9.0). This dll is throwing an error with the "The framework is not installed" message. I am thinking that a Registry key is not being set, or (gasp) an environment variable is not not set. So the problem is either a bad dll build (note that the .target files predate the dll by 3 months, so maybe they are just out of step), or the installer is not setting/resetting an HKEY value properly.
2. The workaround is to open the "Microsoft.Silverlight.Common.targets" and change this section:
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<UsingTask TaskName="Microsoft.VisualStudio.Silverlight.Build.Tasks.GetSilverlightFrameworkPath" AssemblyFile="Microsoft.VisualStudio.Silverlight.Build.Tasks.dll" />
<UsingTask TaskName="Microsoft.VisualStudio.Silverlight.Build.Tasks.CompileXaml" AssemblyFile="Microsoft.VisualStudio.Silverlight.Build.Tasks.dll" />
<!--
Add Silverlight specific Item names to AvailableItemName item, so that they can show up
in a drop-down menu for Build Action field of the properties window in VisualStudio.
-->
<ItemGroup Condition="'$(BuildingInsideVisualStudio)'=='true'">
<AvailableItemName Include="SilverlightPage" />
</ItemGroup>
<!--
================================================================
GetFrameworkPaths
Override GetFrameworkPaths in Microsoft.Common.targets so that
references resolve to the silverlight assemblies rather than the
desktop CLR assemblies
================================================================
-->
<Target
Name="GetFrameworkPaths"
DependsOnTargets="$(GetFrameworkPathsDependsOn)"
>
<GetSilverlightFrameworkPath>
<Output TaskParameter="Path" PropertyName="TargetFrameworkDirectory"/>
<Output TaskParameter="Path" ItemName="TargetFrameworkDirectoryItem"/>
<Output TaskParameter="Path" PropertyName="TargetFrameworkSDKDirectory"/>
<Output TaskParameter="Path" ItemName="TargetFrameworkSDKDirectoryItem"/>
</GetSilverlightFrameworkPath>
<CreateProperty Value="$(TargetFrameworkDirectory)">
<Output TaskParameter="Value" PropertyName="FrameworkPathOverride"/>
</CreateProperty>
<CreateProperty Value="$(TargetFrameworkDirectory)">
<Output TaskParameter="Value" PropertyName="SdkPath"/>
</CreateProperty>
</Target>
TO THIS:
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<UsingTask TaskName="Microsoft.VisualStudio.Silverlight.Build.Tasks.CompileXaml" AssemblyFile="Microsoft.VisualStudio.Silverlight.Build.Tasks.dll" />
<!--
Add Silverlight specific Item names to AvailableItemName item, so that they can show up
in a drop-down menu for Build Action field of the properties window in VisualStudio.
-->
<ItemGroup Condition="'$(BuildingInsideVisualStudio)'=='true'">
<AvailableItemName Include="SilverlightPage" />
</ItemGroup>
<!--
================================================================
GetFrameworkPaths
Override GetFrameworkPaths in Microsoft.Common.targets so that
references resolve to the silverlight assemblies rather than the
desktop CLR assemblies
================================================================
-->
<Target
Name="GetFrameworkPaths"
DependsOnTargets="$(GetFrameworkPathsDependsOn)"
>
<CreateProperty Value="C:\Program Files\Microsoft Silverlight">
<Output TaskParameter="Value" PropertyName="FrameworkPathOverride"/>
</CreateProperty>
<CreateProperty Value="C:\Program Files\Microsoft Silverlight">
<Output TaskParameter="Value" PropertyName="SdkPath"/>
</CreateProperty>
</Target>
Then you place the contents of the C:\Program Files\Microsoft Silverlight\*.dll in your project's clientbin (target file output) directory. This is an awful hack but at least it will build and successfully run Silverlight 1.1 projects. I will also admit that this hack does not properly locate the directory (hence placing the path to the Silverlight .dlls in the propertyvalue is moot, but I am still trying to find a workaround for the bad build.dll or the missing HKEY value).
I hope someone at MS notes this and has an "aha" moment. In the meantime, I hope this helps other avoid, or who have already spent, lots of valuable time trying to fix it.