[release/5.0] Switch between either WinFX targets #4255
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ghost
added
the
ghost
requested review from
Nirmal4G
changed the title
Nirmal4G
changed the title
Nirmal4G
force-pushed
the
hotfix/disable-netfx-winfx-v5.0
branch
3 times, most recently
from
d2c63da to
bb5799a
Compare
Nirmal4G
force-pushed
the
hotfix/disable-netfx-winfx-v5.0
branch
from
bb5799a to
ff4a0cc
Compare
Nirmal4G
force-pushed
the
hotfix/disable-netfx-winfx-v5.0
branch
2 times, most recently
from
6c0f230 to
0a6051c
Compare
Only in Desktop SDK and WinFX props/targets Respect EditorConfig preferences for whitespace and new-lines
The MSBuild items & targets that were defined after the WinFX targets import doesn't depend on anything from the WinFX targets. So, it is safe and better to declare the import after those items and targets definitions.
When the SDK's implementation is being used.
Currently there's no way to properly switch between NETFX's and CoreCLR's WinFX targets. This adds an opt-out, just in case, if we want to use the NETFX's WinFX targets instead.
Nirmal4G
force-pushed
the
hotfix/disable-netfx-winfx-v5.0
branch
from
0a6051c to
cb0e626
Compare
|
Can someone/anyone (please) take a look at this patch at priority? 🧐 Been asking for months. Any feedback or response would be nice… 😔 |
pchaurasia14
added
the
Community Contribution
|
This doesn't look good on you, M$FT! Not even taking a look at a patch and then closing it when it becomes irrelevant. Not a good open-source practice! Very disappointed here!! |
|
@Nirmal4G - Since Also, we recommend all PRs to be made against We apologize for the inconvenience you have experienced. If the PR addresses an issue that is still relevant, you may open the same against |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Closes #4253
Master PRs: #2976, #4629, #4630
Description
When using the Desktop SDK, the build double imports both Full framework and Core
WinFXtargets, leading to build break.Also, there's no straight forward way to switch between either
WinFXtargets as needed. This patch provides such mechanism throughImportFrameworkWinFXTargets.Although there is a workaround for the above issue, they require modifying the installation of the .NET SDKs. So, it's preferable to have them fixed at least for Current (
v5.0) .NET SDK.Customer Impact
We (and possibly many others like me) have a large set of NETCLR WPF projects that can't move to CoreCLR right now. I have recently converted them to sdk-style projects with the
WindowsDesktopSDK which includes custom tasks that are meant for Full framework projects. We also have some silverlight projects to maintain and I recently converted them to sdk-style too. Seems they also need WinFX targets.So, to use the official
WindowsDesktop, we want to switch between eitherWinFXtargets for our custom tasks to take effect. This patch is just allowing that. We're migrating our projects and tools to.NETCoreCLR and it'll take some time. Until then, we need this ability to maintain our projects.Regression
Yes, Desktop SDK and WinFX targets were introduced since v3.0!
Testing
Manual testing and mostly with our WPF projects builds against both .NET
CoreandFullframework CLRs.Risk
There should be minimal to no risk to most when taking this patch.
But, if you're building both Full framework and Core projects with heavily modified build like ours, depending on the behaviour of the double import, then Yes, the build will break.
However, if you already have your workarounds placed, then there should be no problem. You can also remove those workarounds when updating to the SDK with this patch as it fixes the issue.