Support project harvesting in Heat with MSBuild 15

[rseanhall]

• Describe the scenario and benefits that the feature supports.

Heat uses the ToolsVersion attribute in the project file to determine which version of MSBuild to use when harvesting a project. VS 2017/MSBuild 15 adds the new 15.0 option.

• Describe how you're accomplishing the feature today (if possible).

Heat currently falls back to MSBuild 3.5, which fails on certain kinds of projects (see #4279). The ToolsVersion can normally be changed to 14.0 as long as that version of MSBuild is installed.

• Describe what you'd like the new feature to do.

Since MSBuild 15 is not installed to the GAC or the registry, Heat needs to somehow find where it is installed.

[rseanhall]

I already did the work to build the wrapper for 15.0 here. I'm not interested in figuring out how to get Heat to intelligently figure out which installation of MSBuild 15 should be chosen (not only do you have to find MSBuild15, but you have to find an instance that can build the chosen project type). I would be willing to do the work of requiring the user to specify the location of MSBuild to use when harvesting, and getting the Heat msbuild task to automatically pass in the current instance.

[barnson]

Assume the user's running the instance of MSBuild they want/need to use. That's what I did for building WiX. I'm not sure there's a reasonable alternative.

[rseanhall]

Heat.exe doesn't have to run inside of MSBuild.

[barnson]

Ah, right. I was thinking of the tasks.

[johnbuuck]

I support rseanhall enhancement(s) as a good resolution to this problem.

[rojasc]

Is there any update to this?

[rseanhall]

This is a non-breaking change. I have been spending my time on breaking changes in v4. This issue is available for someone to pick up.

[rojasc]

Yeah, I was hoping there something to help me. I'm trying to move my project from v12 to v15, but when i build, I get the error "Failed to load project: The attribute "Label" in element is unrecognized." I haven't really been able to find anything to workaround this yet.

[rojasc]

Oh man. I know noticed this is tagged for the v4.0. Is this something that won't make it in to v3.x?

[adaviding]

@rseanhall I was getting ready to plan this work for myself when I noticed that @barnson tagged this for V4. If I took the approach shown in your msbuild15 branch could it get accepted into V3? (I know you said it is not a breaking change.)

[rseanhall]

No. v3 is pretty much done, we are only taking things that help people migrate to (the still in development) v4.

[vnkishortech]

By following all this thread, I got that msbuild 15 changes have been already done in MSBUILD15 branch. Would it possible to generate new installer (binaries) and make it available in the wixtoolset site?

[adaviding]

According to the comment from @rseanhall at the top of this thread (his second comment actually), there is still something missing. That is: Heat cannot find which version of MS Build 15 to use.

[vnkishortech]

so, what's the workaround because we have already migrated our codebase to vs2017 and running into this issue. Please advise? also, we are using wix4 (not 3)

[adaviding]

I am in the process of getting a quote to have FireGiant do the work (capitalism is involved).

If the FireGiant bid comes in too high then I need to work on it myself. As far as I know there are two problems with the msbuild15 branch.

1. It is out of sync with the master branch.
2. They have not solved the problem of finding msbuild.exe on the msbuild15 branch.

This codebase is a bit mysterious to me so I am hoping that the FireGiant bid will be reasonable.

[adaviding]

@vnkishortech I am making progress here. This is basically equivalent to the most recent commit in the msbuild 15 branch, except that I am based off of master (which is at Wix 3.11.1).

So far heat.exe is able to load a .net framework projects for msbuild 15, but not .net standard projects. I will work on the .net standard tomorrow.

[vnkishortech]

Thank you so much for you help, adaviding! Meanwhile, would it possible to share build out (binaries and installer)? I can also check form my end and confirm?

[rojasc]

This all so awesome. I really hope it makes it to main v3 release.

[adaviding]

@vnkishortech I have not taken time to read the license but I am guessing that I would get in trouble for distributing binaries. The license was written by Microsoft so I don't want to take any chances.

[TheNybbler]

Any update on when this will be fixed? I'm trying to build in VS2017 and it fails unless I install VS2015 as well.

[robmen]

This issue is open and unassigned. That means it is waiting for someone to investigate the root problem, discuss possible solutions to that problem then implement the decided solution.

If you are interested in doing so yourself, our developer documentation provides a great checklist for getting started.

If you are not interested then you are waiting for someone else to become interested. If this issue has been open for a long time then there probably isn't much interest in this particular issue. In that case, you'll want to consider how to motivate others to fix it for you. This is a pretty good list of support options.

[leemw1977]

I appreciate there is not a lot of interest in this, but whilst I was falling into the trap of not having my machine setup with MSBuild etc. I came across the Microsoft.Build.Locator and wondered if that was a potential solution to the outstanding issue of not knowing which MSBuild to use - it may not be relevant but thought I'd link it just in case someone comes here and does have a need:

https://docs.microsoft.com/en-us/visualstudio/msbuild/updating-an-existing-application?view=vs-2019#use-microsoftbuildlocator

[BiplabK]

Hi Sean,

We are getting an issue with wix setup project for web application while upgrading from VS 2017 to VS 2019.

Background.

VS 2017 - Web Application and Wix setup project building and running fine. VS 2019 - Web Application building and running fine without any code change. VS 2019 – Wix setup project not building and getting below error. (We are using heat.exe for harvesting the contents in project Build events.)

Error: “The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v16.0\WebApplications\Microsoft.WebApplication.targets" was not found.”

As checked, folder C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v16.0 not available in our system.

As go through the internet found two solution as below but we are not willing to copy the folder manually or hardcode any value for VisualStudioVersion in web application project file. Would like to know is there any alternative workaround for this issue? Thanks in advance.

Solution 1 : Update Web application project file: From

$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)

To

$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v14.0 - VSToolsPath is not empty so removed the condition and VisualStudioVersion value is 16.0 Solution 2 : C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\MSBuild\Microsoft\VisualStudio\v14.0 to C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\MSBuild\Microsoft\VisualStudio\v16.0 Reference : https://developercommunity.visualstudio.com/content/problem/414282/vs-2019-webapplication-projects-fail-to-load.html Operating System Windows Server 2012 R2 Standard Microsoft Visual Studio Professional 2017 Version 15.9.11 Microsoft Visual Studio Professional 2019 Version 16.4.3

[rseanhall]

The WiX Toolset does not use GitHub issues for support. Please ask your question on the wix-users mailing list.

[vnkishortech]

Was the MSBUILD15 issue addressed in "v3.11.2"?

[robmen]

This issue is open and unassigned. That means it is waiting for someone to investigate the root problem, discuss possible solutions to that problem then implement the decided solution.

If you are interested in doing so yourself, our developer documentation provides a great checklist for getting started.

If you are not interested then you are waiting for someone else to become interested. If this issue has been open for a long time then there probably isn't much interest in this particular issue. In that case, you'll want to consider how to motivate others to fix it for you. This is a pretty good list of support options.

[rseanhall]

Implemented in v4.