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

Support project harvesting in Heat with MSBuild 15 #5490

Open
rseanhall opened this Issue Feb 13, 2017 · 9 comments

Comments

Projects
None yet
4 participants
@rseanhall
Member

rseanhall commented Feb 13, 2017

  • 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

This comment has been minimized.

Show comment
Hide comment
@rseanhall

rseanhall Feb 13, 2017

Member

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.

Member

rseanhall commented Feb 13, 2017

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

This comment has been minimized.

Show comment
Hide comment
@barnson

barnson Feb 13, 2017

Member

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.

Member

barnson commented Feb 13, 2017

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

This comment has been minimized.

Show comment
Hide comment
@rseanhall

rseanhall Feb 13, 2017

Member

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

Member

rseanhall commented Feb 13, 2017

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

@barnson

This comment has been minimized.

Show comment
Hide comment
@barnson

barnson Feb 13, 2017

Member

Ah, right. I was thinking of the tasks.

Member

barnson commented Feb 13, 2017

Ah, right. I was thinking of the tasks.

@barnson barnson added this to the v4.x milestone Feb 14, 2017

@johnbuuck

This comment has been minimized.

Show comment
Hide comment
@johnbuuck

johnbuuck Mar 20, 2017

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

johnbuuck commented Mar 20, 2017

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

@rojasc

This comment has been minimized.

Show comment
Hide comment
@rojasc

rojasc May 31, 2018

Is there any update to this?

rojasc commented May 31, 2018

Is there any update to this?

@rseanhall

This comment has been minimized.

Show comment
Hide comment
@rseanhall

rseanhall May 31, 2018

Member

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.

Member

rseanhall commented May 31, 2018

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

This comment has been minimized.

Show comment
Hide comment
@rojasc

rojasc May 31, 2018

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 commented May 31, 2018

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

This comment has been minimized.

Show comment
Hide comment
@rojasc

rojasc May 31, 2018

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

rojasc commented May 31, 2018

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

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