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
Comments
For v3.8, setup should block on no v2.0 CLR or support multiple versions of MSBuild. For v3.9, remove v2.0 support.
|
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.
|
|
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.
|
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).
|
|
|
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.
|
Currently the tasks assembly is built against v3.5. We'd likely need two different assemblies.
|
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?
|
Doc bug to deprecate in v3.10 for blocking in v3.11.
|
|
Deprecation added for v3.10
|
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. 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.
|
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. |
Found a quick/dirty workaround to get past the above error (WixTasks.dll) and following steps were followed:
Hope it helps somebody, until an official solution arrives. |
@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. |
@robmen, Apologize for the late response, but yes, will try the v4.0 builds. |
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 |
Same issue here with a Windows Server 2012 R2 |
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.
The text was updated successfully, but these errors were encountered: