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

Fixes `msbuild BuildRelease.msbuild` error with AutoFoq #178

Merged
merged 1 commit into from Sep 22, 2013

Conversation

4 participants
@adamchester
Member

adamchester commented Sep 22, 2013

These are the changes made automatically by Visual Studio 2013 RC. This fixed my problems reported in #177.

They seem geared towards fixing the build extensions path depending on which version of visual studio + framework tools you are using.

@adamchester

This comment has been minimized.

Show comment
Hide comment
@adamchester

adamchester Sep 22, 2013

Member

As you may have noticed, the problem appears to be related to VS 2013 RC, so perhaps we should wait and see what (if anything) changes in the final VS 2013 release before considering this change.

Member

adamchester commented Sep 22, 2013

As you may have noticed, the problem appears to be related to VS 2013 RC, so perhaps we should wait and see what (if anything) changes in the final VS 2013 release before considering this change.

@ploeh

This comment has been minimized.

Show comment
Hide comment
@ploeh

ploeh Sep 22, 2013

Member

Some of the changes recently implemented in the build file were made to enable the CI server to actually be able to build the project. @moodmosaic made those changes, so knows much more about these issues than I do. Here's hoping he'll take a look :)

Member

ploeh commented Sep 22, 2013

Some of the changes recently implemented in the build file were made to enable the CI server to actually be able to build the project. @moodmosaic made those changes, so knows much more about these issues than I do. Here's hoping he'll take a look :)

@moodmosaic

This comment has been minimized.

Show comment
Hide comment
@moodmosaic

moodmosaic Sep 22, 2013

Member

The proposed changes in this Pull Request seem to solve the problem with locating the F# build targets, compiler, and runtime (discussed in #177) :)

On my machine, without VS 2013, I could pull down the changes and run the BuildRelease.ps1 successfully :)

Member

moodmosaic commented Sep 22, 2013

The proposed changes in this Pull Request seem to solve the problem with locating the F# build targets, compiler, and runtime (discussed in #177) :)

On my machine, without VS 2013, I could pull down the changes and run the BuildRelease.ps1 successfully :)

@brianary

This comment has been minimized.

Show comment
Hide comment
@brianary

brianary May 8, 2018

This solution has created a time bomb in builds.

Using MSBuild 15 or VS 2017, this fails because Microsoft.FSharp.targets keeps moving around.

On my workstation, it's at:

  • C:\Program Files (x86)\Microsoft SDKs\F#\10.1\Framework\v4.0\Microsoft.FSharp.Targets
  • C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Microsoft\VisualStudio\v15.0\FSharp\Microsoft.FSharp.Targets
  • C:\Program Files\dotnet\sdk\2.1.104\FSharp\Microsoft.FSharp.Targets
  • C:\Program Files\dotnet\sdk\2.1.200\FSharp\Microsoft.FSharp.Targets

On one build server, it's at:

  • C:\Program Files (x86)\Microsoft SDKs\F#\3.0\Framework\v4.0\Microsoft.FSharp.targets
  • C:\Program Files (x86)\Microsoft SDKs\F#\3.1\Framework\v4.0\Microsoft.FSharp.targets
  • C:\Program Files (x86)\Microsoft SDKs\F#\4.0\Framework\v4.0\Microsoft.FSharp.targets
  • C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\FSharp\Microsoft.FSharp.targets
  • C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\FSharp\Microsoft.FSharp.targets
  • C:\Program Files\dotnet\sdk\2.1.104\FSharp\Microsoft.FSharp.Targets
  • C:\Program Files\dotnet\sdk\2.1.4\FSharp\Microsoft.FSharp.Targets

On another, it's at:

  • C:\Program Files (x86)\Microsoft SDKs\F#\4.0\Framework\v4.0\Microsoft.FSharp.targets
  • C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\FSharp\Microsoft.FSharp.targets
  • C:\Program Files\dotnet\sdk\2.1.104\FSharp\Microsoft.FSharp.Targets
  • C:\Program Files\dotnet\sdk\2.1.4\FSharp\Microsoft.FSharp.Targets

Anchoring paths using $(MSBuildExtensionsPath32)\.. to get to C:\Program Files (x86) isn't helpful, since that variable is C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild in VS2017. It seems like a more durable solution would be to use wildcards to search for the file, but I'm going to lose a whole lot of time figuring out the terrible, niche MSBuild syntax to make that happen.

brianary commented May 8, 2018

This solution has created a time bomb in builds.

Using MSBuild 15 or VS 2017, this fails because Microsoft.FSharp.targets keeps moving around.

On my workstation, it's at:

  • C:\Program Files (x86)\Microsoft SDKs\F#\10.1\Framework\v4.0\Microsoft.FSharp.Targets
  • C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Microsoft\VisualStudio\v15.0\FSharp\Microsoft.FSharp.Targets
  • C:\Program Files\dotnet\sdk\2.1.104\FSharp\Microsoft.FSharp.Targets
  • C:\Program Files\dotnet\sdk\2.1.200\FSharp\Microsoft.FSharp.Targets

On one build server, it's at:

  • C:\Program Files (x86)\Microsoft SDKs\F#\3.0\Framework\v4.0\Microsoft.FSharp.targets
  • C:\Program Files (x86)\Microsoft SDKs\F#\3.1\Framework\v4.0\Microsoft.FSharp.targets
  • C:\Program Files (x86)\Microsoft SDKs\F#\4.0\Framework\v4.0\Microsoft.FSharp.targets
  • C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\FSharp\Microsoft.FSharp.targets
  • C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\FSharp\Microsoft.FSharp.targets
  • C:\Program Files\dotnet\sdk\2.1.104\FSharp\Microsoft.FSharp.Targets
  • C:\Program Files\dotnet\sdk\2.1.4\FSharp\Microsoft.FSharp.Targets

On another, it's at:

  • C:\Program Files (x86)\Microsoft SDKs\F#\4.0\Framework\v4.0\Microsoft.FSharp.targets
  • C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\FSharp\Microsoft.FSharp.targets
  • C:\Program Files\dotnet\sdk\2.1.104\FSharp\Microsoft.FSharp.Targets
  • C:\Program Files\dotnet\sdk\2.1.4\FSharp\Microsoft.FSharp.Targets

Anchoring paths using $(MSBuildExtensionsPath32)\.. to get to C:\Program Files (x86) isn't helpful, since that variable is C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild in VS2017. It seems like a more durable solution would be to use wildcards to search for the file, but I'm going to lose a whole lot of time figuring out the terrible, niche MSBuild syntax to make that happen.

@moodmosaic

This comment has been minimized.

Show comment
Hide comment
@moodmosaic

moodmosaic May 9, 2018

Member

@brianary, thanks for reporting this. What would you propose, then? (Feel free to open an issue, if needed.)

Member

moodmosaic commented May 9, 2018

@brianary, thanks for reporting this. What would you propose, then? (Feel free to open an issue, if needed.)

@brianary

This comment has been minimized.

Show comment
Hide comment
@brianary

brianary May 9, 2018

I'm not sure yet, there may be a way to do this with ItemGroup wildcards, but I can't find the syntax to use only the first file when multiple are found. This is probably a Microsoft issue anyway (this workaround was automatically included in VS2015 .fsproj files).

brianary commented May 9, 2018

I'm not sure yet, there may be a way to do this with ItemGroup wildcards, but I can't find the syntax to use only the first file when multiple are found. This is probably a Microsoft issue anyway (this workaround was automatically included in VS2015 .fsproj files).

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