You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: Documentation/developer-guide.md
+23-24Lines changed: 23 additions & 24 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -53,8 +53,9 @@ If there were any failures, you can cd into $(RepoRoot)\artifacts\test\$(Configu
53
53
54
54
### Testing Locally built WPF assemblies (excluding PresentationBuildTasks)
55
55
This section of guide is intended to discuss the different approaches for ad-hoc testing of WPF assemblies,
56
-
and not automated testing. There are a few different ways this can be done, and for the most part,
57
-
it can be a matter of personal preference on which workflow you choose.
56
+
and not automated testing. For automated testing, see the [Running DRTs locally](#Running-DRTs-locally) section above. There are a few different ways this can be done, and for the most part, it depends on what you are trying to accomplish. This section tries to lay out which scenarios require which workflow.
57
+
58
+
*NOTE: You should build locally with the `-pack` param to ensure the binaries are put in the correct location for manual testing.*
58
59
59
60
#### Copying binaries to publish location of a self-contained application
60
61
The simplest approach is to publish your sample app using `dotnet publish -r <rid> --self-contained`.
@@ -67,23 +68,25 @@ Then to copy the WPF assemblies to this published location, simply run the copy-
67
68
located in the `eng` folder of the repo and point it to the location of your test application:
68
69
> eng\copy-wpf.ps1 -destination "c:\mysampleproj"
69
70
70
-
#### Copying binaries to local dotnet installation
71
+
#### Copying binaries to test host installation of dotnet
72
+
73
+
If you want/need to test an existing application that targets the shared installation, it is safest to setup a test host, rather than trying to copy assemblies over the shared installation. A test host is a complete install of dotnet (host and runtimes) used for testing applications and can be setup by using the [dotnet install script](https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-install-script). This method is also effective for internal contributors who are working on porting our current test corpus from .NET Framework to .NET Core and wants to run the tests against locally built assemblies. Note that there is nothing fundamentally different between a testhost installation of dotnet and the one installed in `$env:ProgramFiles`. However the dotnet host dll won't be able to find the testhost install if the appropriate environment variables aren't set. Note that these environment variables are set for you by copy-wpf.ps1
74
+
75
+
You can run the copy-wpf.ps1 script again and be sure to pass in the `-testhost` parameter:
If you want/need to test an existing application that targets the shared installation,
73
-
it is safest to setup a test host, rather than trying to copy assemblies over the shared installation.
74
-
The arcade infrastructure creates a local dotnet installation in the `.dotnet` folder contained at the root
75
-
of the repository when you do a full build using the `build.cmd` or `build.sh` script.
76
-
You can run the copy-wpf.ps1 script again, except you can leave out the destination and be sure to pass in the
77
-
the `-testhost` parameter:
78
-
> eng\copy-wpf.ps1 -testhost
79
-
```cmd eng\copy-wpf.ps1 -testhost ```
78
+
If your testhost directory has multiple versions of the `Microsoft.WindowsDesktop.App` shared runtime in it, you can use the `-version` parameter to specify which one you want:
80
79
81
-
You need to set environment variables so that your testhost installation is used when launching the application.
82
-
Once these are set, you should be able to launch the executable from the command line and then your assemblies
If there are multiple versions, you will see a warning and the last installed runtime will be selected. You can backup the folder by creating a copy of it, and the script will ensure that this folder isn't touched as long as the word "Copy" is in the path. This was chosen because the default for Windows Explorer is to append "- Copy" to the folder. This allows you to easily backup folders containing the runtime assemblies knowing you can restore them to their original state if needed.
83
+
84
+
If you are installing to a special test host location, you will see output from the script that confirms the appropriate environment variables are set:
85
+
86
+
```
87
+
** Setting env:DOTNET_ROOT(x86) to c:\testhost\x86 **
88
+
** Setting env:DOTNET_MULTILEVEL_LOOKUP to 0 **
89
+
```
87
90
88
91
**How to find location of the exe to test?**
89
92
If you are testing an application and don't know where the executable is located, the easiest thing to do
@@ -97,7 +100,6 @@ When the C# compiler detects a collision with assembly references, the assembly
97
100
higher version number is chosen. Assuming our locally built binaries are newer than what is
98
101
installed, we can then simply reference those local binaries directly from the project file, like this:
99
102
100
-
*Note: you should build locally with the `-pack` param to ensure the binaries are put in the correct location.*
101
103
```xml
102
104
<PropertyGroup>
103
105
<!-- Change this value based on where your local repo is located -->
@@ -117,14 +119,11 @@ installed, we can then simply reference those local binaries directly from the p
117
119
```
118
120
119
121
### Testing specific versions of the Microsoft.WindowsDesktop.App runtime
120
-
At times, it is necessary to install and test specific versions of the runtime. This can be helpful if you are trying to root cause when an issue started occuring.
122
+
At times, it is necessary to install and test specific versions of the runtime. This can be helpful if you are trying to root cause when an issue started occuring, or need to compare functionality between two different versions.
121
123
122
-
For testing different versions of the runtime, you can install a specific version of the runtimes via the dotnet install script: https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-install-script
123
-
**Note**: These install the versions to your %user% directory, so you can use the DOTNET_ROOT environment variables to ensure these get used as described above. Otherwise, you can point them to install in %programfiles% and specify which version of the runtime should be picked up.
124
+
For testing different versions of the runtime, you can install a specific version of the runtimes via the [dotnet install script](https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-install-script). Below is an example powershell script of how you can use the `dotnet-install.ps1` script that will install both 32-bit and 64-bit versions of the `Microsoft.WindowsDesktop.App` runtime into the specified folder:
124
125
125
-
Below is an example powershell script of how you can use the `dotnet-install.ps1` script:
@@ -154,7 +153,7 @@ In this example, the version of `Microsoft.WindowsDesktop.App` associated with t
154
153
**Note**: The ability to install the WindowsDesktop runtime via the dotnet install script is being tracked by: https://github.com/dotnet/cli/issues/11115
155
154
156
155
#### Specifying which version of the runtime to use
157
-
If you can build directly from source, you can add this to your project file to pick up the version of the shared runtime you want to test:
156
+
If you can build directly from source, and want to test your application against a certain version of the `Microsoft.WindowsDesktop.App` shared runtime, you can add this to your project file to pick up the version of the shared runtime you want to test:
0 commit comments