Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WiX 3.6 Requires .NET 2.0 #3872

Closed
wixbot opened this issue Dec 22, 2012 · 20 comments
Closed

WiX 3.6 Requires .NET 2.0 #3872

wixbot opened this issue Dec 22, 2012 · 20 comments
Assignees
Milestone

Comments

@wixbot
Copy link

wixbot commented Dec 22, 2012

This was tested with v3.6 (sorry, didn't test 3.7 since I stick with final releases). Basically I was setting up a minimalistic build server for TFS Service. I installed Windows 8, Team Foundation Server and WiX 3.6. This left me with ONLY .NET 4.5. My first build threw the following error:

C:\Program Files (x86)\MSBuild\Microsoft\WiX\v3.x\wix2010.targets (2339): The "WixAssignCulture" task could not be loaded from the assembly C:\Program Files (x86)\WiX Toolset v3.6\bin\WixTasks.dll. Could not load file or assembly 'Microsoft.Build.Utilities, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified. Confirm that the declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask.

I was able to add the .NET 3.5 feature and green up the build. It seems like this should work with only .NET 4.5 installed OR the WiX installer should detect a missing prereq.

Originally opened by chrpai from http://sourceforge.net/p/wix/bugs/3175/

@wixbot
Copy link
Author

wixbot commented Oct 10, 2013

For v3.8, setup should block on no v2.0 CLR or support multiple versions of MSBuild. For v3.9, remove v2.0 support.

Originally posted by barnson
Area set to installer

@wixbot
Copy link
Author

wixbot commented Oct 26, 2013

FYI I retested with Win 8.1 and TFS 2013. The error message is similar but now comes out of the ReadRegistry task.

C:\Program Files (x86)\MSBuild\Microsoft\WiX\v3.x\Wix.CA.targets (52): The "ReadRegistry" task could not be loaded from the assembly C:\Program Files (x86)\MSBuild..\WiX Toolset v3.8\bin\WixTasks.dll. Could not load file or assembly 'Microsoft.Build.Utilities, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified. Confirm that the declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask.

Originally posted by chrpai

@wixbot
Copy link
Author

wixbot commented Oct 28, 2013

Originally changed by bmurri
AssignedTo set to wixsupport

@wixbot
Copy link
Author

wixbot commented Oct 29, 2013

I tried a slightly different environment (VS 2013 instead of TFS) on Windows 8.1 without any .NET 2/3.x anything installed (just the 4.x that is installed by default on win8.1) and did not repro.

I will try again without VS (both with and without TFS), now that I have a project on that windows box. I confirmed with each repro that the .NET 3.5 feature is disabled.

Originally posted by bmurri

@wixbot
Copy link
Author

wixbot commented Oct 31, 2013

This does repro.

Out of the box a couple of the Microsoft.Build.~ assemblies have policies associated with the v4 MSBuild.exe set to force 2.x versions to use the v4 assembly, but Microsoft.Build.Utilities isn't one of them. Obviously something installed when installing VS2013 adds a policy covering that assembly, so this can be solved easily, but given the short time frame for 3.8 release I'm going to go with Bob's suggestion of blocking on no v2 CLR and then change this bug to 3.9 and duplicate the policies there in a manner compatible with whatever installer is adding them (removing the blocks at that time).

Originally posted by bmurri

@wixbot
Copy link
Author

wixbot commented Nov 3, 2013

Originally changed by barnson
Resolution set to fixed
Status changed from Open to Resolved

@wixbot
Copy link
Author

wixbot commented Nov 3, 2013

Originally changed by barnson
AssignedTo changed from wixsupport to bobarnson

@wixbot
Copy link
Author

wixbot commented Jan 29, 2015

I was able to reproduce this issue today with a fresh install of Windows Server 2012 R2. The server has only .NET 4.5, the .NET 4.5 SDK, and Build Tools 2013 installed on it (the WiX binaries are checked into source control). I tried WiX 3.8 and 3.9 and got the same result. Installing the .NET 3.5 features worked around the problem.

wix2010.targets(1848,5): error MSB4062: The "HeatDirectory" task could not be loaded from the assembly wixtasks.dll. Could not load file or assembly 'Microsoft.Build.Utilities, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified. Confirm that the <UsingTask> declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask.

Originally posted by dan
Status changed from Resolved to Untriaged

@wixbot
Copy link
Author

wixbot commented Feb 3, 2015

Currently the tasks assembly is built against v3.5. We'd likely need two different assemblies.

AssignedTo changed from bobarnson to
Releasechanged fromv3.8tov3.x
Statuschanged fromUntriagedtoResolved

@wixbot
Copy link
Author

wixbot commented Feb 4, 2015

I hear what you're saying, and I agree that separate .NET 2/.NET 4 assemblies will work, but I'm not sure that's actually necessary. When I upgraded the project I was trying to build here from .NET 3.5 to .NET 4, I did not have to upgrade all of the build tools I was using to .NET 4 versions. In fact, I'm still using an ancient version of MSBuild.Community.Tasks (1.2.0.306) that has a reference to Microsoft.Build.Utilities, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a and it gave me no problems when .NET 4.5 only was installed. Could there be something different about the way WiXTasks is referencing the MSBuild assembly that would cause this?

Originally posted by dan
Status changed from Resolved to Untriaged

@wixbot
Copy link
Author

wixbot commented Feb 17, 2015

Doc bug to deprecate in v3.10 for blocking in v3.11.

AssignedTo set to bobarnson
Release changed from v3.x to v3.10
Resolution changed from fixed to

@wixbot
Copy link
Author

wixbot commented Feb 22, 2015

wixtoolset/wix3#209

Originally posted by barnson

@wixbot
Copy link
Author

wixbot commented Feb 22, 2015

Deprecation added for v3.10

Originally posted by barnson
Release changed from v3.10 to v3.11

@wixbot
Copy link
Author

wixbot commented Dec 16, 2015

I also seem to have had this problem with my VS 2015 configuration and WiX 3.10.1 and also WiX 4.0.3430. On my computer I had a co-existence scenario of VS 2012 and VS 2015 and maybe some leftovers of an even earlier version of Visual Studio.
Uninstalling of all earlier versions didn't help. The only thing that fixed the problem was copying the required MSBUILD assembly (2.0.0.0__b03f5f7f11d50a3a) from an old (Win7) backup of my computer before I migrated to Win8 and then Win10.
To workaround the problem I copied the Microsoft.Build.Utilities folder residing in \Windows\assembly\GAC_MSIL to the destination computer and then everything worked like a charm.

What I still don't know is who in that chain requires and calls that old 2.0 dll. I think it must have something to do with WiX because I don't seem to have any problems with building other VS project types.

I didn't add .NET 3.5 nor did I install anything else specifically related to .NET.

Originally posted by cpalm

@wixbot wixbot added this to the v3.11 milestone Dec 20, 2015
@rajasekarshanmugam
Copy link

WixTasks.dll from version (WiX Toolset v3.10.2) also has a reference to Microsoft.Build.Utilities, Version=2.0.0.0, Microsoft.Build.Framework, Version=3.5.0.0. Got the same error on a new Win10/VS2015+Update 1 setup with only 4.6+ framework installed. Hope this info is of some help. I am wondering if any *.config, assembly redirections will help. Last choice is to install the older version of .NET.

@rajasekarshanmugam
Copy link

Found a quick/dirty workaround to get past the above error (WixTasks.dll) and following steps were followed:

  • Close VS
  • Copy wixtasks.dll from official build to a temp folder, keep a backup copy of the original.
  • Open VS developer command prompt, cd to temp folder created above - run command - ildasm /out=WixTasks.il WixTasks.dll
  • Open WixTasks.il using a good text editor. Replace - .assembly extern 'Microsoft.Build.Utilities' with .assembly extern 'Microsoft.Build.Utilities.v4.0' at the very top of the file. Find and replace [Microsoft.Build.Utilities'] with ['Microsoft.Build.Utilities.v4.0'](approx 209 replacements)
  • Download key from https://github.com/wixtoolset/wix3/blob/develop/tools/publickey_wix.snk
  • Run command - ilasm /dll /key:publickey_wix.snk /output=WixTasks.dll WixTasks.il
  • Replace the official copy with the new WixTasks.dll (typically found at an equivalent location 'C:\Program Files (x86)\WiX Toolset v3.10\bin' unless default directory was changed)
  • Try MSBuild or VS, should at least get past only WixTasks.dll was bothering

Hope it helps somebody, until an official solution arrives.

@robmen
Copy link
Member

robmen commented Jan 23, 2016

@rajasekarshanmugam WiX v3.x still supports MSBuild v3.5 thus the NETFX v3.5 build dependency. MSBuild v3.5 support is cut in WiX v4.0.

@rajasekarshanmugam
Copy link

@robmen, Apologize for the late response, but yes, will try the v4.0 builds.

@ahaid
Copy link

ahaid commented Apr 11, 2016

I tried with this 4.0 build on a fresh Windows 10 machine with Visual Studio 2015 Update 2. The dependency on .NET Framework 3.5 is still present. I was unable to compile my wix project until I turned on the 3.5 framework feature. After enabling it and changing the schema of my .wxs file to <Wix xmlns="http://wixtoolset.org/schemas/v4/wxs">, it compiled fine.

@roji
Copy link

roji commented Aug 26, 2016

Same issue here with a Windows Server 2012 R2

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants