Skip to content
This repository has been archived by the owner on Aug 8, 2024. It is now read-only.

Fix TargetFrameworkRootPathFallback when MSBuild API is used in different process #22

Merged

Conversation

DustinCampbell
Copy link

When reading the TargetFrameworkRootPathFallback from the app.config, we need use the configuration file from the current MSBuild Exe Path rather than the one from the current process. This is consistent with the behavior of ToolsetConfigurationReaderHelpers.ConfigurationFileMayHaveToolsets().

This addresses the particular scenario of using MSBuild as an API within another application (in my case OmniSharp).

cc @radical

…rent process

When reading the TargetFrameworkRootPathFallback from the app.config, we need use the configuration file from the current MSBuild Exe Path rather than the one from the current process. This is consistent with the behavior of `ToolsetConfigurationReaderHelpers.ConfigurationFileMayHaveToolsets()`.
@radical radical merged commit 0f25092 into mono:xplat-master Jul 22, 2017
DustinCampbell added a commit to DustinCampbell/omnisharp-roslyn that referenced this pull request Jul 24, 2017
This includes PR mono/msbuild#22 to fix an issue with TargetFrameworkRootPath fallbacks.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants