Skip to content
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

Port Microsoft.Build to .NET Core #159

Merged
merged 2 commits into from
Aug 26, 2015
Merged

Conversation

dsplaisted
Copy link
Member

This pull request finishes the changes necessary to successfully compile Microsoft.Build for .NET Core. Lots of code which depended on features which weren't available was simply disabled, so more work will be needed to make sure that the code works on .NET Core.

path = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "MSBuild.exe");
#else
path = Path.GetDirectoryName(Process.GetCurrentProcess().MainModule.FileName);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it safe to just use this all the time? That'd be easier.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it safe to just use this all the time? That'd be easier.

@rainersigwald I'm not sure. In general I'm wary of changing things for the .NET Framework build unless I'm confident they won't cause breaking changes if we merge them back into the next release of MSBuild for .NET Framework.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like that philosophy. We need to figure out how to balance it with not creating too much long-term debt.

(This is mostly because I hit a similar issue and just changed the product code. 😇)

@rainersigwald
Copy link
Member

LGTM

<Compile Include="Definition\ToolsetConfigurationReader.cs" />
<Compile Include="..\Shared\ToolsetElement.cs">
<Compile Include="Definition\ToolsetConfigurationReader.cs" Condition="$(FeatureSystemConfiguration) == 'true'"/>
<Compile Include="..\Shared\ToolsetElement.cs" Condition="$(FeatureSystemConfiguration) == 'true'">
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think if I had to pick I would say #if the contents of the file over a condition in the csproj to avoid confusion in VS. If there's a good reason for this though I'm fine with it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wondered about that, too. I came down on the other side of it but not for any good reason.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So far what I've been doing is that if the whole file needs to be included or excluded based on a feature, I would do that with a condition in MSBuild. For groups of files like are in the SharedUtilities/Compat folder that feels better to me. For one-off (or two-off) files like this one I don't have much of a strong opinion.

I'm going to go ahead and merge this, we can always discuss and make a change later.

@AndyGerlicher
Copy link
Contributor

LGTM. I would just like to know the reasoning behind Compile include vs #if inside the file.

dsplaisted added a commit that referenced this pull request Aug 26, 2015
Port Microsoft.Build to .NET Core
@dsplaisted dsplaisted merged commit 3be2996 into dotnet:xplat Aug 26, 2015
radical added a commit to radical/msbuild that referenced this pull request Dec 4, 2019
commit 7b112c5

```
Microsoft.NET.Sdk.Web: 3.1.100-rtm.19570.3 (from 3.1.100-rtm.19569.1)
Microsoft.DotNet.Cli.Runtime: 3.1.100-rtm.19570.4 (from 3.1.100-rtm.19568.3)
```
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants