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

Fixed: WPF workaround for importing extensions does not always work #201

Merged
merged 2 commits into from Jul 24, 2020

Conversation

ivan-danilov
Copy link
Contributor

The issue happens when BaseIntermediateOutputPath is overridden, thus
MSBuildProjectExtensionsPath gets assigned without generated suffix
even in *_wpftmp.*proj file.
Since _SdkOriginalProjectExtensionsPath didn't have a fallback value -
that prevented importing project extensions. This change adds the
fallback, making it effectively like "if there's a suffix - remove it,
otherwise use as is".

@ivan-danilov ivan-danilov force-pushed the fix-wpf-workaround branch 2 times, most recently from 02dec26 to 533a735 Compare January 11, 2020 05:05
@ivan-danilov
Copy link
Contributor Author

The error does not seem to be related to my changes. Am I expected to do something with it?

@ivan-danilov
Copy link
Contributor Author

@clairernovotny any comments on this PR?

@clairernovotny
Copy link
Collaborator

Please rebase or bring in master and then I can merge

@clairernovotny
Copy link
Collaborator

Question: Have you tried the main .NET Core 3.1 SDK with the WindowsDesktop SDK an UseWpf set to true? Does that work?

Curious as to why you need the extras for WPF currently?

@ivan-danilov
Copy link
Contributor Author

@clairernovotny it is for 1.6 branch and it is up to date with rel/1.6. master might need the same fix but I don't have a project to check it on, therefore reluctant to make unchecked changes there.

We use .NET Core build process for an old WPF project. For technical reasons the project can't switch to .NET Core completely (binaries must be loadable into .NET Framework process) but using .NET Core build tools allows to use newer NuGet, SDK-style project files with csproj-specified NuGet dependencies (rather than package.config) etc.

@clairernovotny
Copy link
Collaborator

I'm not planning on releasing any more 1.6 releases. What's keeping you on that old version?

@ivan-danilov
Copy link
Contributor Author

@clairernovotny sorry for the delayed response, I had to retry the upgrade. I remember I tried it back in January but completely forgot why decided to stay on the old branch.
I think it is this NETSDK1107 warning.

I'll update to the last version and rebase.

The issue happens when BaseIntermediateOutputPath is overridden, thus
MSBuildProjectExtensionsPath gets assigned without generated suffix
even in *_wpftmp.*proj file.
Since _SdkOriginalProjectExtensionsPath didn't have a fallback value -
that prevented importing project extensions. This change adds the
fallback, making it effectively like "if there's a suffix - remove it,
otherwise use as is".
@ivan-danilov ivan-danilov changed the base branch from rel/v1.6 to master May 13, 2020 06:57
@ivan-danilov
Copy link
Contributor Author

@clairernovotny I hope you are well and healthy.
Just a kind reminder about this PR :)

I saw some related activity in WPF/NuGet repos but they don't look exactly promising yet.

@clairernovotny clairernovotny merged commit 3caa026 into novotnyllc:master Jul 24, 2020
@ivan-danilov
Copy link
Contributor Author

Thanks! :)

@ivan-danilov ivan-danilov deleted the fix-wpf-workaround branch July 24, 2020 00:58
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

2 participants