search

mikefourie-zz / MSBuildExtensionPack

MIT License
366 stars 104 forks source link

Doesn't work with VS2017 #67

Closed AndreyAlifanov closed 6 years ago

AndreyAlifanov commented 7 years ago

Microsoft has changed path to MSBuild in VS2017. So this version of Studio can't find installed version of MSBuild Extension Pack. Manual copying of Extension Pack to VS2017 MSBuild folder helps, but it's not a good solution. Especially in enterprise environment.

mikefourie-zz commented 7 years ago

do you have a log?

AndreyAlifanov commented 7 years ago

Can you explain: how to get it?

2017-03-02 10:17 GMT+05:00 Mike Fourie notifications@github.com:

do you have a log?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/mikefourie/MSBuildExtensionPack/issues/67#issuecomment-283558988, or mute the thread https://github.com/notifications/unsubscribe-auth/APTVZrmavlth6nRrbVxd3OzZztI88eTAks5rhlEFgaJpZM4MPNmQ .

-- С уважением, Алифанов Андрей.

frankracis-work commented 7 years ago

It's a change in how MSBuild 15 is installed. On my system, it wasn't installed in the C:\program files (x86)\msbuild folder. Instead, it was installed under my VS2017 root (I have a non-default C:\vs15)

The $(MsBuildExtensionPath) will be set to the VS2017 install (C:\vs15\msbuild). This causes $(ExtensionTasksPath) to be C:\VS15\MSBuild\ExtensionPack\4.0\ which is not where the DLLs are.

This is odd, because the import statement is <Import Project="$(MSBuildExtensionsPath)\ExtensionPack\4.0\MSBuild.ExtensionPack.tasks"/> and that file doesn't exist, but it still manages to load somehow.

It turns out there is now special logic in MSBuild to search for imported projects: https://github.com/Microsoft/msbuild/blob/6851538897f5d7b08024a6d8435bc44be5869e53/src/Build/Evaluation/Evaluator.cs#L2227-L2267 When importing a project, it will also search in the old location, which is how it manages to find the .tasks file.

This can be easily fixed. In MSBuild.ExtensionPack.tasks is a line <ExtensionTasksPath Condition="'$(ExtensionTasksPath)' == ''">$(MSBuildExtensionsPath)\ExtensionPack\4.0\</ExtensionTasksPath>

This will use the MSbuild 15 folder, without any search paths, and will not find the DLLs. If you change it to <ExtensionTasksPath Condition="'$(ExtensionTasksPath)' == ''">$(MSBuildThisFileDirectory)</ExtensionTasksPath>

it will set $(ExtensionTasksPath) to the location of the .tasks file, and load the DLLs from that folder.

@AndreyAlifanov as a quick workaround, you can add

<PropertyGroup>
    <ExtensionTasksPath>C:\program files (x86)\msbuild\ExtensionPack\4.0\</ExtensionTasksPath>
</PropertyGroup>

to your msbuild file before your import, which will accomplish the same thing.

AndreyAlifanov commented 7 years ago

It's not good solution. We have about 50 developers and I'm not sure about every installation of Visual Studio. So I can't write absolute path to .targets-file.

frankracis-work commented 7 years ago

For VS prior to 2017, the MSBuild path is not related to your VS path.

I agree it's not a perfect solution, just a possible alternative to copying the files or waiting for an updated build extensions. Put a Condition on the property, and you're no worse off

yuriy-nelipovich commented 7 years ago

Same issue for me. Any updates?

mikefourie-zz commented 7 years ago

Sorry for delay. Seems like we need to change the install location then. Something like %programfiles%\MSBuildExtensionPack

mikefourie-zz commented 6 years ago

Please try 4.0.15.0 which changes the install location. https://github.com/mikefourie/MSBuildExtensionPack/releases/tag/4.0.15.0

AndreyAlifanov commented 6 years ago

I can't try 4.0.15.0, because Windows 10 Defender blocks these msi files.

mikefourie-zz commented 6 years ago

@AndreyAlifanov in what way? you can't run or download?

AndreyAlifanov commented 6 years ago

I can't run msi-file. I can attach message box from Windows Defender, but it will be in russian.

Xiard commented 6 years ago

4.0.15 does not appear to resolve the issue for me. We are working on creating a build machine. We have installed just the build tools for VS2017. This is the install by the "Build Tools for Visual Studio 2017" at https://www.visualstudio.com/downloads/.

That install places the msbuild files at C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild. When I try to build my solution, $(MSBuildExtensionsPath) expands to:

C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild

...which means "C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\ExtensionPack\4.0\MSBuild.ExtensionPack.tasks" can't be found.

Installing 4.0.15 installs to C:\Program Files\MSBuildExtensionPack\4.0 by default.

I could change the install folder when installing 4.0.15 to place the install directly in C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\ExtensionPack\4.0\, but that doesn't seem right.

Any suggestions on the right way to install with the 2017 build tools?

Xiard commented 6 years ago

Note that I worked around the issue by installing 4.0.13 of the MS Build Extension Pack (to go back to the c:\program files\MsBuild install path), and then overriding the environment variables in the call to msbuild using the /property parameter:

'"C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin\MSBuild.exe" fullIDTTest.sln "/property:MSBuildExtensionsPath=C:\program files\MSBuild;MSBuildExtensionsPath32=C:\Program Files (x86)\MSBuild"'

That allowed me to override the env variables in one place instead of having to worry about overriding them in default.targets, my sln file, various csproj & Wix setup projects, etc.

Xiard commented 6 years ago

I ended up having some issues in Wix caused by overriding the MSBuild variables like I did above. I ended up resolving all issues by simply adding symbolic links on my build machine:

mklink "C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\Microsoft\Wix" "C:\Program Files (x86)\MSBuild\Microsoft\Wix" mklink "C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\ExtensionPack" "C:\Program Files\MSBuild\ExtensionPack"

That means I am no longer using /property to override the build paths on the msbuild.exe command line.

amiyaaloke commented 5 years ago

What's latest on this issues? I am facing similar issue where msbuild on teamcity server is not able to find Microsoft.NET.Build.Extensions. It has only msbuild tools installed. On my local machine with VS 2017 15.8 installed, project solution builds fine. By renaming Extensions folder, I can reproduce the teamcity issue locally. I tried supplying extension folder path on command line, however I ran into other build issues. Any suggestions here?