Skip to content
37 changes: 36 additions & 1 deletion README.md
Original file line number Diff line number Diff line change
@@ -1,5 +1,40 @@
# Windows Presentation Framework (WPF)
This repo contains the open-source components of Windows Presentation Foundation (WPF) that run on top of .NET Core 3. This is based on, but separate from, the version of WPF that is supported in the Windows Desktop .NET Framework.

For now, this is just building a simple Hello World project :)
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 use 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).

> note that this URL doesn't exist yet - I assume 3.0 will come online soon?
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.
Copy link
Member

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 ?

Copy link
Member

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.

* 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.
Copy link
Member

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?

Copy link
Member

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.

Copy link
Contributor Author

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!


# How to build the code
Currently, this repo only contains the `System.Xaml` assembly and its related tests. It is not sufficient to build a complete version of WPF, but you can rebuild `System.Xaml.dll` and run the associated tests.

## To build `System.Xaml`

* In the root of your repo, run `build` (or `build -verbose` for logs).

## To run the tests

* In the root of your repo, run `test` or open the solution file `src\Microsoft.DotNet.Wpf\test\DRT\DrtXaml.sln` ("DRT" is an internal name used for unit tests).

# Contribution guidelines
## Issues
* If you have feedback (bug report, feature suggestion, etc.) *specifically* about WPF on .NET Core 3, please [open a new issue here](https://github.com/dotnet/wpf/issues/).
* If you have more general feedback about .NET Core 3, please use the [dotnet/core](https://github.com/dotnet/core) repo.
* 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.
Copy link
Member

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.

Copy link
Contributor Author

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.


# Code of conduct
The WPF repo follows the [.NET Foundation Code of Condut](http://www.dotnetfoundation.org/code-of-conduct).

[![Build Status](https://dnceng.visualstudio.com/internal/_apis/build/status/dotnet.wpf)](https://dnceng.visualstudio.com/internal/_build/latest?definitionId=234)