-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Merge initial README changes #23
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
Conversation
Started adding info
Added known issue for vcruntime and designer support
Added info on building and cleaned up contributions section
Updated docs info / links
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few typos.
README.md
Outdated
Most of the [conceptual documentation for WPF on Desktop](https://docs.microsoft.com/en-us/visualstudio/designers/getting-started-with-wpf?view=vs-2017) applies equally well to WPF on .NET Core 3. The main differences are around project structure and lack of Designer support (see **Known issues**, below). All WPF features are available on .NET Core 3, but some .NET Framework features (such as remoting or AppDomains) are not supported. See [**insert some link to .NET Core docs**](http://msdn.microsoft.com) for more info | ||
|
||
# Known issues | ||
* WPF relies on the VCRuntime redistributable package. For this initial release, you will need to install the VCRuntime redistributable on any machines where you want WPF applications to run. You can [follow this issue in /dotnet/core-setup](https://github.com/dotnet/core-sdk/issues/160#issuecomment-440103176) for more information. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we want a link to the vcruntime here. The issue I sent was just in case we wanted to have a GitHub issue link for each known issue. But I think maybe it makes more sense to start our own issue in the WPF repo and then link to that. Thoughts @vatsan-madhavan ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When solutions are expected to be made in the wpf codebase, we should file corresponding issues under /wpf. If issues are expected to be solved elsewhere, then we should file them where they are expected to be solved. For now, the vcruntime problem seems to have an unclear 'home'. I think it is owned by the VC libs or the Compiler team, but there is also an onus on us (WPF team) to drive a solution for this (or consume a partial solution, like a privatized runtime ). Given its particular complexity, I would open an issue for this one under /wpf and link to it with details.
README.md
Outdated
|
||
# Known issues | ||
* WPF relies on the VCRuntime redistributable package. For this initial release, you will need to install the VCRuntime redistributable on any machines where you want WPF applications to run. You can [follow this issue in /dotnet/core-setup](https://github.com/dotnet/core-sdk/issues/160#issuecomment-440103176) for more information. | ||
* There is currently no XAML Designer support for WPF on .NET Core. If you wantto use the XAML Designer, you will need to do that in the context of a .NET Framework (Desktop) project. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have we verified that the multi-target scenario where net472 is the first target framework allows the designer to be used? If so and VS signs off on that, should we tell people to use that as a workaround in the meantime?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do this all the time, and works well for me. Both the designer, and the Test runner, respect only the first entry in <TargetFrameworks/>
. I just verified it on a project from yesterdays SDK bits, and it continues to work well.
Instead of asking for a hard support statement from IDE folks (I'm not discouraging us from following this through - I'm just worried that asking for a "sign off" for somethign like this would not be forthcoming easily), we should consider framing our knowledge of this workaround as a fragile-yet-functional workaround which is not guaranteed to work forever, and possibly mention that we hope to build appropriate first-class IDE experiences "soon". In the meantime, if IDE folks are willing to guarantee that this will work reliably, then we can ugprade our verbiage appropriately. Just my 2c.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will experiment and add this info in update to PR. Thanks!
README.md
Outdated
* If you have feedback about WPF on the Desktop Framework, please report it using the Feedback Hub on Windows 10 (Category: *Developer Platfornm*, sub-category *UI frameworks and controls* and make it clear your feedback is for WPF, not UWP XAML). | ||
|
||
## Code | ||
We are not accepting pull requests to WPF at this time; we will udpate this section with contribution guidelines as we move closer to an initial full release of the code. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not true as per my last understanding of the plan. We will accept PRs, but not merge them. I assume if this is a distinction we are making internally, we should also make it externally.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added something along those lines; please take a look.
Update based on review feedback
Co-Authored-By: ptorr-msft <[email protected]>
Added more wording to Code contributions
Currently, only a subset of the full WPF Framework is available as open-source (`System.Xaml` and related tests); more code will be pushed to the repo over the coming months. | ||
|
||
# Using the code | ||
To get started using WPF on .NET Core 3, follow the [Getting Started instructions](https://github.com/dotnet/samples/tree/master/wpf). The WPF APIs are documented on MSDN in the [.NET API Browser](https://docs.microsoft.com/en-us/dotnet/api/?view=netstandard-2.0). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- Should the getting started instructions live in this repo, and the samples repo points back here for basic getting started instructions? @richlander
- I think we need to update the API reference list, but I don't know if it will be ready in time for Preview 1. Should we remove this line for now?
Few minor updates
Tweaked wording for designer.
@ptorr-msft as discussed offline, I put up docs in another PR - see #32 and pending #33
I believe the rest is covered in my docs. Including limiting PR contributions to "parity with WPF for .NET Framework" (different wording for https://github.com/dotnet/wpf/blob/da8b617a3bc67b78cea6ca225d0c66837ff537e4/README.md#code). |
Closing this in favour of Karel's PR; I will add missing pieces back to that. |
Basic README for the Preview 1 release. Still has a couple of placeholders but wanted something close to ready.