Simplify content for repo (#133)
* Simplify content for repo * Add roadmap link to contributing guide * Update roadmap * Fix links * Rename contributing guide file
This commit is contained in:
Rich Lander
GitHub
Родитель
26561642b9
Коммит
854cd09d36
|
|
@ -1,6 +1,6 @@
|
|||
# Contributing
|
||||
|
||||
See [Contributing Guide](../Documentation/contributing-guide.md) for information about:
|
||||
See [Contributing Guide](../Documentation/contributing.md) for information about:
|
||||
|
||||
* Which kind of PRs we accept/reject for .NET Core 3.0 release
|
||||
* Coding style
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# Contributing Guide
|
||||
|
||||
The primary focus of .NET Core 3.0 release for Windows Forms is to achieve parity with .NET Framework. Priority will be given to changes that align with that goal.
|
||||
The primary focus of .NET Core 3.0 release for Windows Forms is to achieve parity with .NET Framework. Priority will be given to changes that align with that goal. See the [roadmap](../roadmap.md) to understand project goals.
|
||||
|
||||
We need the most help with the following types of changes:
|
||||
|
||||
|
|
@ -9,6 +9,8 @@ We need the most help with the following types of changes:
|
|||
|
||||
Please [file an issue](https://github.com/dotnet/winforms/issues) for any larger change you would like to propose.
|
||||
|
||||
See [Developer Guide](developer-guide.md) to learn how to develop changes for this repo.
|
||||
|
||||
This project follows the general [.NET Core Contribution Guidelines](https://github.com/dotnet/coreclr/blob/master/Documentation/project-docs/contributing.md). The contribution bar from the general contribution guidelines is copied below.
|
||||
|
||||
## Contribution "Bar"
|
||||
|
|
@ -6,7 +6,7 @@ Then, you are free make your changes locally.
|
|||
|
||||
Once you are ready to debug your changes on an existing Windows Forms application, please follow one of the two following recommended techniques for relating your changes back to your project. You should then be able to set breakpoints and debug as expected.
|
||||
|
||||
If you do not want to corrupt your local SDK, you may with to perform technique 2, while if you do not want to add an additional reference to your project, technique 1 may be better for you.
|
||||
If you do not want to modify your local SDK, you may with to perform technique 2, while if you do not want to add an additional reference to your project, technique 1 may be better for you.
|
||||
|
||||
### 1. Copy your changes into the SDK
|
||||
|
||||
|
|
@ -20,9 +20,9 @@ to your dotnet folder at:
|
|||
|
||||
where **[Drive]** is your OS drive (for example, C:) and **[Version]** is your DesktopUI version directory (for example, 3.0.0-alpha-27017-4).
|
||||
|
||||
**NOTE** that this will corrupt your SDK; to revert back, you will have to repair the install or reinstall. See the [dotnet Core repository](https://github.com/dotnet/core) for more information.
|
||||
**NOTE** that this will modify your SDK; to revert back, you will have to repair the install or reinstall. See the [dotnet Core repository](https://github.com/dotnet/core) for more information.
|
||||
|
||||
### 2. Point your project to your experimental binary(-ies)
|
||||
### 2. Point your project to your experimental binary(-ies)
|
||||
|
||||
Add references to the binary(-ies) to your project. For example, for System.Windows.Forms, you should add the following reference:
|
||||
|
||||
|
|
@ -32,4 +32,4 @@ Add references to the binary(-ies) to your project. For example, for System.Wind
|
|||
</ItemGroup>
|
||||
```
|
||||
|
||||
where **[Drive]** is your OS drive.
|
||||
where **[Drive]** is your OS drive.
|
||||
|
|
@ -0,0 +1,35 @@
|
|||
# Developer Guide
|
||||
|
||||
The following document describes the setup and workflow that is recommended for working on the Windows Forms project. It assumes that you have read the [contributing doc](contributing.md).
|
||||
|
||||
The [Issue Guide](issue-guide.md) describes our approach to using GitHub issues.
|
||||
|
||||
## Machine Setup
|
||||
|
||||
Follow the [Building CoreFX on Windows](https://github.com/dotnet/corefx/blob/master/Documentation/building/windows-instructions.md) instructions.
|
||||
|
||||
Windows Forms requires the following workloads and components be selected when installing Visual Studio:
|
||||
|
||||
* Required Workloads:
|
||||
* .NET Desktop Development
|
||||
* Desktop development with C++
|
||||
* Required Individual Components:
|
||||
* C++/CLI support
|
||||
* Windows 10 SDK
|
||||
|
||||
## Workflow
|
||||
|
||||
We use the following workflow for building and testing features and fixes.
|
||||
|
||||
You first need to [Fork](https://github.com/dotnet/corefx/wiki/Checking-out-the-code-repository#fork-the-repository) and [Clone](https://github.com/dotnet/corefx/wiki/Checking-out-the-code-repository#clone-the-repository) this WinForms repository. This is a one-time task.
|
||||
|
||||
1. [Build](building.md) the repo.
|
||||
2. [Debug](debugging.md) the change, as needed.
|
||||
3. [Test](testing.md) the change, to validate quality.
|
||||
|
||||
## More Information
|
||||
|
||||
* [git commands and workflow](https://github.com/dotnet/corefx/wiki/git-reference)
|
||||
* [Coding guidelines](https://github.com/dotnet/corefx/tree/master/Documentation#coding-guidelines)
|
||||
* [up-for-grabs Winforms issues](https://github.com/dotnet/winforms/issues?q=is%3Aopen+is%3Aissue+label%3Aup-for-grabs)
|
||||
* [easy Winforms issues](https://github.com/dotnet/winforms/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+label%3Aeasy)
|
||||
|
|
@ -1,5 +0,0 @@
|
|||
# Windows Forms Functional Testing #
|
||||
|
||||
We are still working on a scalable solution for functional testing and will update this doc when we have one.
|
||||
|
||||
[TODO: Link to manual testing instructions]
|
||||
|
|
@ -1,38 +1,28 @@
|
|||
# Getting started with WinForms for .NET Core
|
||||
|
||||
This document describes the experience of using WinForms on .NET Core. The [Developer Guide](developer-guide.md) describes how to develop features and fixes for Windows Forms.
|
||||
|
||||
## Installation
|
||||
|
||||
Choose one of these options:
|
||||
|
||||
1. Official public preview [.NET Core 3.0 SDK Preview 1](https://www.microsoft.com/net/download), or
|
||||
2. [Daily build](https://aka.ms/netcore3sdk) (for more installer options see [dotnet/code-sdk repo](https://github.com/dotnet/core-sdk)).
|
||||
|
||||
To use the **WinForms designer**, you'll need Visual Studio. We recommend [Visual Studio 2019 Preview 1](https://visualstudio.microsoft.com/downloads/).
|
||||
Select the **.NET desktop development** workload with the options: **.NET Framework 4.7.2 development tools** and **.NET Core 3.0 development tools**.
|
||||
1. [.NET Core 3.0 SDK Preview 1 (recommended)](https://www.microsoft.com/net/download)
|
||||
2. [.NET Core 3.0 daily build (latest changes, but less stable)](https://github.com/dotnet/core/blob/master/daily-builds.md)
|
||||
|
||||
## Creating new applications
|
||||
|
||||
You can create a new WinForms application with `dotnet new` command, using the new templates for WinForms.
|
||||
You can create a new WinForms application with `dotnet new` command, using the following commands:
|
||||
|
||||
In your favorite console run:
|
||||
```cmd
|
||||
dotnet new winforms -o MyWinFormsApp
|
||||
cd MyWinFormsApp
|
||||
dotnet run
|
||||
```
|
||||
|
||||
## Samples
|
||||
|
||||
Check out the [.NET Core 3.0 WinForms samples](https://github.com/dotnet/samples/tree/master/windowsforms) for both basic and advanced scenarios.
|
||||
|
||||
## Porting existing applications
|
||||
|
||||
To port your existing WinForms application from .NET Framework to .NET Core 3.0, refer to our [porting guidelines](porting-guidelines.md).
|
||||
|
||||
## Samples
|
||||
|
||||
Check out the .NET Core 3.0 WinForms [samples](https://github.com/dotnet/samples/tree/master/windowsforms)
|
||||
for HelloWorld examples and more advanced scenarios.
|
||||
|
||||
## How to build
|
||||
See [Building Windows Forms](building.md)
|
||||
|
||||
## How to test
|
||||
See [Testing Windows Forms](testing.md).
|
||||
|
||||
|
|
|
|||
|
|
@ -6,8 +6,6 @@ It may be as simple as a small product or test bug or as large as the work track
|
|||
|
||||
We will keep issues open even if the WinForms team internally has no plans to address them in an upcoming release, as long as we believe they are in line with our direction.
|
||||
|
||||
|
||||
|
||||
## How to file issues
|
||||
|
||||
You can help us streamline our response time to your feedback and ideas by filing high-quality reports.
|
||||
|
|
@ -27,8 +25,6 @@ Ideally, assume that the reader has minimal knowledge and experience with writin
|
|||
|
||||
For API suggestions, check [API review process](https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/api-review-process.md), especially [example of good API proposals](https://github.com/dotnet/corefx/issues/271).
|
||||
|
||||
|
||||
|
||||
## Labels
|
||||
|
||||
We use GitHub [labels](https://github.com/dotnet/winforms/labels) on our issues in order to classify them. We have the following categories per issue:
|
||||
|
|
@ -42,8 +38,6 @@ We use GitHub [labels](https://github.com/dotnet/winforms/labels) on our issues
|
|||
* [needs-more-info](https://github.com/dotnet/winforms/labels/needs-more-info): Issues which need more information to be actionable. Usually this will be because we can't reproduce a reported bug. We'll close these issues after a little bit if we haven't gotten actionable information, but we welcome folks who have acquired more information to reopen the issue.
|
||||
* [tenet-compatibility](https://github.com/dotnet/winforms/labels/tenet-compatibility): Incompatibility between relesed versions or with WinForms for .NET Framework.
|
||||
|
||||
|
||||
|
||||
## Milestones
|
||||
|
||||
We use [milestones](https://github.com/dotnet/winforms/milestones) to prioritize work for each upcoming release.
|
||||
|
|
@ -54,30 +48,17 @@ We use [milestones](https://github.com/dotnet/winforms/milestones) to prioritize
|
|||
* **Future** milestone tracks all potential future work (which may or may not happen). When we are done with 3.0 release, we will move some of these issues into the next immediate milestone.
|
||||
* Please do not start discussions about next post-3.0 milestone until we are close to final 3.0 release. If you want to express your opinion on prioritization, please [upvote first post of the issue](#upvotes-on-issues) instead.
|
||||
|
||||
|
||||
|
||||
## Assignee
|
||||
|
||||
We assign each issue to assignee, when the assignee is ready to pick up the work and start working on it.
|
||||
If the issue is not assigned to anyone and you want to pick it up, please say so - we will assign the issue to you.
|
||||
If the issue is already assigned to someone, please coordinate with the assignee before you start working on it.
|
||||
|
||||
|
||||
|
||||
## Upvotes on issues
|
||||
|
||||
Upvotes on first post of each issue are useful hint for our prioritization.
|
||||
We can [sort issues by number of upvotes](https://github.com/dotnet/winforms/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc) and we will review the top list on regular basis.
|
||||
|
||||
|
||||
|
||||
## Escalations
|
||||
|
||||
If you think some issue or PR is not getting the right attention, or if you notice some [Code of Conduct](https://dotnetfoundation.org/code-of-conduct) violation we might miss,
|
||||
you can escalate to WinForms team by tagging some of us (e.g. [@merriemcgaw](https://github.com/merriemcgaw), [@karelz](https://github.com/karelz)). Please do not overuse it.
|
||||
|
||||
|
||||
|
||||
## Triage rules
|
||||
|
||||
Guidance for triaging issues for WinForms team members:
|
||||
|
|
|
|||
|
|
@ -1,10 +0,0 @@
|
|||
# Machine Setup
|
||||
|
||||
Follow the [Building CoreFX on Windows](https://github.com/dotnet/corefx/blob/master/Documentation/building/windows-instructions.md) instructions; in particular, **Windows Forms requires the following workloads and individual components** be installed when downloading Visual Studio:
|
||||
|
||||
* Required Workloads:
|
||||
* .NET Desktop Development
|
||||
* Desktop development with C++
|
||||
* Required Individual Components:
|
||||
* C++/CLI support
|
||||
* Windows 10 SDK
|
||||
|
|
@ -1,43 +0,0 @@
|
|||
# WinForms on .NET Core Roadmap
|
||||
|
||||
With the introduction of .NET Core 3, WinForms exists as one of [several
|
||||
layers](https://github.com/dotnet/core/blob/master/Documentation/core-repos.md)
|
||||
of .NET Core. Although .NET Core is cross-platform, WinForms relies heavily on
|
||||
Windows-specific platform pieces and for now will remain Windows only.
|
||||
|
||||
At present, our team's primary focus is making additional components of WinForms
|
||||
available as open source in this repo, ensuring functional parity with the
|
||||
WinForms as it currently exists .NET Framework, and adding the ability to run
|
||||
tests publicly so we can accept PRs from the open source community. Here are our
|
||||
short-term and long-term goals.
|
||||
|
||||
## Short-Term
|
||||
|
||||
* Port existing functional tests and test infrastructure to this repo
|
||||
* Add Application property for DPI Awareness setting
|
||||
|
||||
## Long-Term
|
||||
|
||||
* Add WinForms Designer support for .NET Core 3 projects in Visual Studio
|
||||
* Fix existing scaling bugs in Per Monitor DPI aware applications
|
||||
* Add a new “clean" way of calculating location/size information in PMA mode.
|
||||
* Make new projects be per monitor aware
|
||||
* Add Edge browser control
|
||||
* Add Data Visualization controls
|
||||
* Improve accessibility support for some missing UIA interfaces
|
||||
* Improve performance of WinForms runtime
|
||||
|
||||
For general information regarding .NET Core plans, see [.NET Core
|
||||
roadmap](https://github.com/dotnet/core/blob/master/roadmap.md).
|
||||
|
||||
## Timeline for Open Source
|
||||
|
||||
| Milestone | Release Date |
|
||||
|---|---|
|
||||
|Initial launch of WinForms on .NET Core repository |Dec 4, 2018|
|
||||
|Functional parity with .NET Framework WinForms |Q1 2019|
|
||||
|First version of open source WinForms|.NET Core GA|
|
||||
|Designer support in Visual Studio|Update to VS 2019|
|
||||
|
||||
If you'd like to contribute to WinForms, please take a look at our [Contributing
|
||||
Guide](https://github.com/dotnet/winforms/blob/master/Documentation/contributing-guide.md).
|
||||
|
|
@ -1,4 +1,82 @@
|
|||
# Testing Windows Forms
|
||||
# Windows Forms Unit Testing
|
||||
|
||||
* For unit testing, see [Unit Testing](unit-testing.md)
|
||||
* For functional testing, see [Functional Testing](functional-testing.md)
|
||||
This document describes our approach to unit testing.
|
||||
|
||||
We are still working on a scalable solution for functional testing.
|
||||
|
||||
## Building tests
|
||||
Tests are automatically built when running `.\build` since all test projects are referenced in `System.Windows.Forms.sln` at the repo root.
|
||||
|
||||
## Running tests
|
||||
|
||||
### Testing from the command line
|
||||
To execute unit tests, run `.\build -test`
|
||||
|
||||
If all the tests are successful, you should see something like this:
|
||||
```console
|
||||
Running tests: E:\src\repos\github\winforms\artifacts\bin\System.Windows.Forms.Tests\Debug\netcoreapp3.0\System.Windows.Forms.Tests.dll [netcoreapp3.0|x64]
|
||||
Tests succeeded: E:\src\repos\github\winforms\artifacts\bin\System.Windows.Forms.Tests\Debug\netcoreapp3.0\System.Windows.Forms.Tests.dll [netcoreapp3.0|x64]
|
||||
|
||||
Build succeeded.
|
||||
0 Warning(s)
|
||||
0 Error(s)
|
||||
```
|
||||
|
||||
### Troubleshooting command-line test errors
|
||||
When testing from the command line, a failed test should look something like this:
|
||||
```console
|
||||
Running tests: E:\src\repos\github\winforms\artifacts\bin\System.Windows.Forms.Tests\Debug\netcoreapp3.0\System.Windows.Forms.Tests.dll [netcoreapp3.0|x64]
|
||||
XUnit : error : Tests failed: E:\src\repos\github\winforms\artifacts\TestResults\Debug\System.Windows.Forms.Tests_netcoreapp3.0_x64.html [netcoreapp3.0|x64] [E:\src\repos\github\winforms\src\System.Windows.Forms\tests\UnitTests\System.Windows.Forms.Tests.csproj]
|
||||
XUnit : error : Tests failed: E:\src\repos\github\winforms\artifacts\TestResults\Debug\System.Windows.Forms.Tests_netcoreapp3.0_x64.html [netcoreapp3.0|x64] [E:\src\repos\github\winforms\src\System.Windows.Forms\tests\UnitTests\System.Windows.Forms.Tests.csproj]
|
||||
|
||||
Build FAILED.
|
||||
```
|
||||
|
||||
* The test summary can be found under artifacts\log
|
||||
* To see the actual test(s) that failed, along with their error message(s), open the .html file that is displayed in the error message (which is always under `artifacts\TestResults`)
|
||||
|
||||
### Testing from Visual Studio
|
||||
To test from Visual Studio, open System.Windows.Forms.sln in Visual Studio and test how you normally would (using the Test Explorer, for example)
|
||||
|
||||
### Troubleshooting Visual Studio test errors
|
||||
* When testing from Visual Studio, test errors show up as normal in the test explorer.
|
||||
* To troubleshoot, debug the selected test and set breakpoints as you normally would.
|
||||
|
||||
## Adding new tests
|
||||
Tests are built and executed by file name convention
|
||||
* Every WinForms binary has its own folder under src in the repo root (src\System.Windows.Forms, for example)
|
||||
* Each of those folders has a tests folder under it (src\System.Windows.Forms\tests, for example)
|
||||
* Each tests folder contains an xUnit test project (System.Windows.Forms.Tests.csproj)
|
||||
* These test projects automatically build when running .\build
|
||||
* The tests from these projects automatically execute when running .\build -test
|
||||
|
||||
**Therefore, you just need to put your tests in the right place in order for them to run**
|
||||
* Browse to the tests folder for the binary you are testing
|
||||
* There should be one file per class being tested, and the file name should match the class name.
|
||||
* For example, if I wanted to test the Button class in System.Windows.Forms.dll, I would look for a Button.cs under src\System.Windows.Forms\tests
|
||||
* If the file exists, add your tests there. If it doesn't exist, feel free to create it.
|
||||
* **Note that you don't have to modify the csproj at all.** Since the project is a Microsoft.NET.Sdk project, all source files next to it are automatically included
|
||||
|
||||
### Test best pactices
|
||||
Naming
|
||||
* Test files names should match the class they are testing
|
||||
* For example, tests for the Button class should be in Button.cs
|
||||
* Test class names should match the class they are testing, followed by "Tests"
|
||||
* For example, tests for the Button class should in the ButtonTests class
|
||||
* Test names should start with the class they are testing
|
||||
* For example, all tests for the button class should start with "Button"
|
||||
* Test names should end with a description of what the test does
|
||||
* For example, Button_AutoSizeModeGetSet
|
||||
* This is very useful when viewing test results, and when browsing in the test explorer
|
||||
|
||||
Strategy
|
||||
* **Unit tests should be part of the same PR as code changes**
|
||||
* Please test internal methods as well, not just publics.
|
||||
* Avoid duplicating tests just for different inputs
|
||||
* Use `[Theory]` for this, followed by either `[InlineData]` or `[MemberData]`. See existing tests for examples on how to use these attributes
|
||||
* The exception to this is if the code behavior is fundamentally different based on the inputs. For example, if a method throws an ArgumentException for invalid inputs, that should be a separate test.
|
||||
* One test (or test data) per code path please
|
||||
* The most common exception to this is when testing a property, most people test get/set together
|
||||
* Whenever possible, mock up dependencies to run tests in isolation
|
||||
* For example, if your method accepts an abstraction, use Moq to mock it up
|
||||
* Search for Mock in the existing tests for examples, and see [Moq](https://github.com/Moq/moq4/wiki/Quickstart) for details on how to use Moq.
|
||||
|
|
@ -1,78 +0,0 @@
|
|||
# Windows Forms Unit Testing #
|
||||
|
||||
## Building tests
|
||||
Tests are automatically built when running `.\build` since all test projects are referenced in `System.Windows.Forms.sln` at the repo root.
|
||||
|
||||
## Running tests
|
||||
|
||||
### Testing from the command line
|
||||
To execute unit tests, run `.\build -test`
|
||||
|
||||
If all the tests are successful, you should see something like this:
|
||||
```console
|
||||
Running tests: E:\src\repos\github\winforms\artifacts\bin\System.Windows.Forms.Tests\Debug\netcoreapp3.0\System.Windows.Forms.Tests.dll [netcoreapp3.0|x64]
|
||||
Tests succeeded: E:\src\repos\github\winforms\artifacts\bin\System.Windows.Forms.Tests\Debug\netcoreapp3.0\System.Windows.Forms.Tests.dll [netcoreapp3.0|x64]
|
||||
|
||||
Build succeeded.
|
||||
0 Warning(s)
|
||||
0 Error(s)
|
||||
```
|
||||
|
||||
### Troubleshooting command-line test errors
|
||||
When testing from the command line, a failed test should look something like this:
|
||||
```console
|
||||
Running tests: E:\src\repos\github\winforms\artifacts\bin\System.Windows.Forms.Tests\Debug\netcoreapp3.0\System.Windows.Forms.Tests.dll [netcoreapp3.0|x64]
|
||||
XUnit : error : Tests failed: E:\src\repos\github\winforms\artifacts\TestResults\Debug\System.Windows.Forms.Tests_netcoreapp3.0_x64.html [netcoreapp3.0|x64] [E:\src\repos\github\winforms\src\System.Windows.Forms\tests\UnitTests\System.Windows.Forms.Tests.csproj]
|
||||
XUnit : error : Tests failed: E:\src\repos\github\winforms\artifacts\TestResults\Debug\System.Windows.Forms.Tests_netcoreapp3.0_x64.html [netcoreapp3.0|x64] [E:\src\repos\github\winforms\src\System.Windows.Forms\tests\UnitTests\System.Windows.Forms.Tests.csproj]
|
||||
|
||||
Build FAILED.
|
||||
```
|
||||
|
||||
* The test summary can be found under artifacts\log
|
||||
* To see the actual test(s) that failed, along with their error message(s), open the .html file that is displayed in the error message (which is always under `artifacts\TestResults`)
|
||||
|
||||
### Testing from Visual Studio
|
||||
To test from Visual Studio, open System.Windows.Forms.sln in Visual Studio and test how you normally would (using the Test Explorer, for example)
|
||||
|
||||
### Troubleshooting Visual Studio test errors
|
||||
* When testing from Visual Studio, test errors show up as normal in the test explorer.
|
||||
* To troubleshoot, debug the selected test and set breakpoints as you normally would.
|
||||
|
||||
## Adding new tests
|
||||
Tests are built and executed by file name convention
|
||||
* Every WinForms binary has its own folder under src in the repo root (src\System.Windows.Forms, for example)
|
||||
* Each of those folders has a tests folder under it (src\System.Windows.Forms\tests, for example)
|
||||
* Each tests folder contains an xUnit test project (System.Windows.Forms.Tests.csproj)
|
||||
* These test projects automatically build when running .\build
|
||||
* The tests from these projects automatically execute when running .\build -test
|
||||
|
||||
**Therefore, you just need to put your tests in the right place in order for them to run**
|
||||
* Browse to the tests folder for the binary you are testing
|
||||
* There should be one file per class being tested, and the file name should match the class name.
|
||||
* For example, if I wanted to test the Button class in System.Windows.Forms.dll, I would look for a Button.cs under src\System.Windows.Forms\tests
|
||||
* If the file exists, add your tests there. If it doesn't exist, feel free to create it.
|
||||
* **Note that you don't have to modify the csproj at all.** Since the project is a Microsoft.NET.Sdk project, all source files next to it are automatically included
|
||||
|
||||
### Test best pactices
|
||||
Naming
|
||||
* Test files names should match the class they are testing
|
||||
* For example, tests for the Button class should be in Button.cs
|
||||
* Test class names should match the class they are testing, followed by "Tests"
|
||||
* For example, tests for the Button class should in the ButtonTests class
|
||||
* Test names should start with the class they are testing
|
||||
* For example, all tests for the button class should start with "Button"
|
||||
* Test names should end with a description of what the test does
|
||||
* For example, Button_AutoSizeModeGetSet
|
||||
* This is very useful when viewing test results, and when browsing in the test explorer
|
||||
|
||||
Strategy
|
||||
* **Unit tests should be part of the same PR as code changes**
|
||||
* Please test internal methods as well, not just publics.
|
||||
* Avoid duplicating tests just for different inputs
|
||||
* Use `[Theory]` for this, followed by either `[InlineData]` or `[MemberData]`. See existing tests for examples on how to use these attributes
|
||||
* The exception to this is if the code behavior is fundamentally different based on the inputs. For example, if a method throws an ArgumentException for invalid inputs, that should be a separate test.
|
||||
* One test (or test data) per code path please
|
||||
* The most common exception to this is when testing a property, most people test get/set together
|
||||
* Whenever possible, mock up dependencies to run tests in isolation
|
||||
* For example, if your method accepts an abstraction, use Moq to mock it up
|
||||
* Search for Mock in the existing tests for examples, and see [Moq](https://github.com/Moq/moq4/wiki/Quickstart) for details on how to use Moq.
|
||||
23
README.md
23
README.md
|
|
@ -3,23 +3,22 @@
|
|||
|
||||
Windows Forms (WinForms) is a UI framework for building Windows desktop applications. It is a .NET wrapper over Windows user interface libraries, such as User32 and GDI+. It also offers controls and other functionality that is unique to Windows Forms.
|
||||
|
||||
WinForms applications typically have good performance because WinForms is a thin layer over Windows for much of the functionality. It also provides one of the most productive ways to create desktop applications based on the visual designer provided in Visual Studio. It enable drag-and-drop of visual controls and other similar functionality that make it easy to build desktop applications.
|
||||
WinForms also provides one of the most productive ways to create desktop applications based on the visual designer provided in Visual Studio. It enable drag-and-drop of visual controls and other similar functionality that make it easy to build desktop applications.
|
||||
|
||||
> Note: The visual designer is not yet available and will be part of a Visual Studio 2019 update. You are recommended to use Visual Studio 2019 Preview 1 to use Windows Forms on .NET Core.
|
||||
> Note: The visual designer is not yet available and will be part of a Visual Studio 2019 update.
|
||||
|
||||
Consult the [Windows Forms Roadmap](roadmap.md) to learn about project priorities, status and ship dates.
|
||||
Consult the [Windows Forms Roadmap](roadmap.md) to learn about project priorities, status and ship dates.
|
||||
|
||||
This repo contains WinForms for .NET Core. It does not contain the .NET Framework variant of WinForms.
|
||||
|
||||
[WPF](https://github.com/dotnet/wpf) is another UI framework for building Windows desktop applications that is supported on .NET Core. WPF and WinForms applications only run on Windows. They are part of the `Microsoft.NET.Sdk.WindowsDesktop` SDK.
|
||||
[WPF](https://github.com/dotnet/wpf) is another UI framework for building Windows desktop applications that is supported on .NET Core. WPF and WinForms applications only run on Windows. They are part of the `Microsoft.NET.Sdk.WindowsDesktop` SDK. You are recommended to use Visual Studio 2019 Preview 1 to use WPF and WinForms with .NET Core.
|
||||
|
||||
## Getting started
|
||||
|
||||
* [.NET Core 3.0 SDK Preview 1](https://www.microsoft.com/net/download)
|
||||
* [Getting started instructions](Documentation/getting-started.md)
|
||||
* [Issue guide](Documentation/issue-guide.md)
|
||||
* [Contributing guide](Documentation/contributing.md)
|
||||
* [Porting guide](Documentation/porting-guide.md)
|
||||
* [Contributing guide](Documentation/contributing-guide.md)
|
||||
|
||||
## Status
|
||||
|
||||
|
|
@ -30,9 +29,9 @@ We are in the process of doing four projects with Windows Forms:
|
|||
3. Publish (and in some cases write) tests to GitHub and enable automated testing infrastructure.
|
||||
4. Enable the Visual Studio WinForms designer to work with WinForms running on .NET Core.
|
||||
|
||||
The first two tasks are well underway. Most of the source has been published to GitHub although we are still bringing the codebase up to functional and performance parity with .NET Framework.
|
||||
The first two tasks are well underway. Most of the source has been published to GitHub although we are still bringing the codebase up to functional and performance parity with .NET Framework.
|
||||
|
||||
We have published very few tests and have very limited coverage for PRs at this time as a result. We will be slow in merging PRs as a result. We will add more tests in 2019, however, it will be an incremental process. We welcome test contributions to increase coverage and help us validate PRs more easily.
|
||||
We have published very few tests and have very limited coverage for PRs at this time as a result. We will be slow in merging PRs as a result. We will add more tests in 2019, however, it will be an incremental process. We welcome test contributions to increase coverage and help us validate PRs more easily.
|
||||
|
||||
The Visual Studio WinForms designer is not yet available and will be part of a Visual Studio 2019 update. In short, we need to move to an out-of-proc model (relative to Visual Studio) for the designer.
|
||||
|
||||
|
|
@ -40,7 +39,8 @@ The Visual Studio WinForms designer is not yet available and will be part of a V
|
|||
|
||||
Some of the best ways to contribute are to try things out, file bugs, join in design conversations, and fix issues.
|
||||
|
||||
* This repo defines [contributing guidelines](Documentation/contributing-guide.md) and also follows the more general [.NET Core contributing guide](https://github.com/dotnet/coreclr/blob/master/Documentation/project-docs/contributing.md).
|
||||
* The [contributing guidelines](Documentation/contributing.md) and the more general [.NET Core contributing guide](https://github.com/dotnet/coreclr/blob/master/Documentation/project-docs/contributing.md) define contributing rules.
|
||||
* The [Developer Guide](developer-guide.md) defines the setup and workflow for working on this repo.
|
||||
* If you have a question or have found a bug, [file an issue](https://github.com/dotnet/winforms/issues/new).
|
||||
* Use [daily builds](Documentation/getting-started.md#installation) if you want to contribute and stay up to date with the team.
|
||||
|
||||
|
|
@ -70,7 +70,4 @@ This project uses the [.NET Foundation Code of Conduct](https://dotnetfoundation
|
|||
|
||||
.NET Core WinForms is a [.NET Foundation](https://www.dotnetfoundation.org/projects) project.
|
||||
|
||||
There are many .NET related projects on GitHub.
|
||||
|
||||
- [.NET home repo](https://github.com/Microsoft/dotnet) - links to 100s of .NET
|
||||
projects, from Microsoft and the community.
|
||||
See the [.NET home repo](https://github.com/Microsoft/dotnet) to find other .NET-related projects.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,44 @@
|
|||
# WinForms on .NET Core Roadmap
|
||||
|
||||
This roadmap communicates priorities for evolving and extending the scope of WinForms for .NET Core.
|
||||
|
||||
At present, our primary focus is enabling the following for .NET Core 3.0:
|
||||
|
||||
* Achieve WinForms functional and performance parity compared to .NET Framework
|
||||
* Publish remaining WinForms components to the repo
|
||||
* Publish (and write) more WinForms tests to the repo
|
||||
|
||||
> Note: There are some specific .NET Framework features will not be supported, such as hosting WinForms controls in Internet Explorer.
|
||||
|
||||
As we complete those goals, we'll update our roadmap to include additional feature/capability areas we will focus on next.
|
||||
|
||||
For general information regarding .NET Core plans, see [.NET Core
|
||||
roadmap](https://github.com/dotnet/core/blob/master/roadmap.md).
|
||||
|
||||
## Timelines
|
||||
|
||||
| Milestone | Date |
|
||||
|---|---|
|
||||
|Initial launch of WinForms on .NET Core repository |Dec 4, 2018|
|
||||
|Functional parity with .NET Framework WinForms |Q1 2019|
|
||||
|First version of WinForms on .NET Core |.NET Core 3.0 GA|
|
||||
|Designer support in Visual Studio|Update to VS 2019|
|
||||
|
||||
If you'd like to contribute to WinForms, please take a look at our [Contributing
|
||||
Guide](Documentation/contributing.md).
|
||||
|
||||
## Shorter-Term Feature Backlog
|
||||
|
||||
* Port existing functional tests and test infrastructure to this repo
|
||||
* Add Application property for DPI Awareness setting
|
||||
|
||||
## Longer-Term Feature Backlog
|
||||
|
||||
* Add WinForms Designer support for .NET Core 3 projects in a Visual Studio 2019 update
|
||||
* Fix existing scaling bugs in Per Monitor DPI aware applications
|
||||
* Add a new “clean" way of calculating location/size information in PMA mode.
|
||||
* Make new projects be per monitor aware
|
||||
* Add Edge browser control
|
||||
* Add Data Visualization controls
|
||||
* Improve accessibility support for some missing UIA interfaces
|
||||
* Improve performance of WinForms runtime
|
||||
Загрузка…
Ссылка в новой задаче