AutoFixture/AutoFixture

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.

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

Merged
merged 1 commit into from Sep 22, 2013

Conversation

4 participants
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.
``` Fixes #177 BuildRelease.msbuild AutoFoq ```
``` 0338d4e ```
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.
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 :)
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 :)

Closed

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.
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 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).
to join this conversation on GitHub. Already have an account? Sign in to comment