Build Failing. (Win2k3svr 64bit) Error: ".NET Framework v1.1 is not installed"

Topics: For MSBee Users
Aug 16, 2006 at 10:16 PM
migrated from power toy forums
originally posted by Jonathan Waller

I'm trying to build a class library with MSBee on a Win2003 Server 64bit system. It fails with the error ".NET Framework v1.1 is not installed". Looking at Add/Remove programs, the .NET 1.1 framework is installed. (As well as 1.1 SDK, 2.0 SDK and 2.0 Framework), so I'm a little stumped.

Previous to this error, it failed with an error looking for either MSBuild or MSBee within a subdirectory of "c:\program files\". I didn't have the directory it was looking for as my MSBuild and MSBee files were installed to "c:\program files (x86)\". (As is the way on 64bit Windows versions). I copied the MSBuild directory and subdirectories to "c:\program files\" so MSBuild could find the files it was looking for. But was then confronted with this new error.

All references are valid for a .NET 1.1 application.

This project builds perfectly under VS2005. (As a 2.0 class library)

This project builds perfectly on another machine with MSBee. (Win2003svr 32bit)

Any ideas?


Build output follows: (on 64bit)

>msbuild TestFixtureUIBase.csproj /t:Rebuild /p:TargetFX1_1=true

Microsoft (R) Build Engine Version 2.0.50727.42
Microsoft .NET Framework, Version 2.0.50727.42
Copyright (C) Microsoft Corporation 2005. All rights reserved.

Build started 07/04/2006 13:03:14.
Project "D:\Jon\VC#\WebTestingToolsCollection\TestFixtureUIBase\TestFixtureUIBas
e.csproj" (Rebuild target(s)):

Target GetFrameworkPaths:
,9): error : The .NET Framework v1.1 is not installed.
Done building target "GetFrameworkPaths" in project "TestFixtureUIBase.csproj" -

Done building project "TestFixtureUIBase.csproj" -- FAILED.

error : The .NET Framework v1.1 is not installed.
0 Warning(s)
1 Error(s)

Time Elapsed 00:00:00.98
Aug 16, 2006 at 10:16 PM
originally posted by Craig Lichtenstein - MSFT

We haven't tested MSBee on 64 bit Windows yet and unfortunately you seem to have encountered some nuisance bugs. I'll contact the MSBuild team on both of these.

For the ProgramFiles related issue, we install to the location contained in MSBuildExtensionsPath (which is %ProgramFiles%\MSBuild). While this works on 32-bit platforms, apparently there's a difference on 64-bit platforms. What will likely happen is that I'll change the installer to use C:\ProgramFiles on 64-bit as well - so the use of $(MSBuildExtensionsPath) for importing the MSBee targets files remains consistent.

For your current problem, I'll need to review how the .NET 1.1 path is obtained by MSBuild.

As to a workaround, you can try this:

1. Set the TargetFrameworkDirectory and TargetFrameworkSDKDirectory properties directly in the MSBuildExtras.FX1_1.Common.targets file. Naturally, these should be the paths to your 1.1 Framework and 1.1 SDK directories, respectively. You may also need to set _TargetFrameworkDirectoryItem and _TargetFrameworkSDKDirectoryItem to the same values as their corresponding properties.

2. Remove the UsingTask elements for GetFrameworkPath and GetFrameworkSDKPath from the top of the MSBuildExtras.FX1_1.Common.targets file.
Aug 16, 2006 at 10:16 PM
originally posted by Jonathan Waller

Your workaround was successful, I now have a .NET 1.1 DLL, freshly generated on my 64 bit system. Thanks.
Aug 16, 2006 at 10:17 PM
originally posted by Craig Lichtenstein - MSFT

Here's the deal on the 64 bit stuff:

The value of $(MSBuildExtensionsPath) depends on the architecture you're running on. If you're using the .NET 2.0 redist for 64 bit (which you seem to be using), the property is set to "C:\Program Files". If you're running under WOW, it will look in "C:\Program Files (x86)"; which is where we install to since MSBee is 32 bit only.

The ".NET framework v1.1 can't be found" error is because there is no .NET 1.1 redist for 64 bit. When running MSBee in a 64-bit environment, the APIs it uses to find framework directories look in 64-bit locations. This fails since there isn't a .NET 1.1 for 64-bit; hence the error you're receiving.
Oct 13, 2006 at 9:51 AM
I came across this discussion when looking for something in another context. Remember that MSBuildExtensionsPath can also be set by an environment variable, and that should also be taken into account by an installer.

There is good reason to use this environment variable if, for example, you want to keep any modifications (or additions) to MSBuild extensions in a source control directory tree.