Skip to content

Commit 9c4c3b5

Browse files
author
Steven Kirbach
authored
making copy-wpf more useful (#933)
* making copy-wpf more useful * addressing pr feedback * fixing space * cleaning up information
1 parent c9bdfc0 commit 9c4c3b5

File tree

2 files changed

+86
-34
lines changed

2 files changed

+86
-34
lines changed

Documentation/developer-guide.md

Lines changed: 23 additions & 24 deletions
Original file line numberDiff line numberDiff line change
@@ -53,8 +53,9 @@ If there were any failures, you can cd into $(RepoRoot)\artifacts\test\$(Configu
5353

5454
### Testing Locally built WPF assemblies (excluding PresentationBuildTasks)
5555
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.*
5859

5960
#### Copying binaries to publish location of a self-contained application
6061
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-
6768
located in the `eng` folder of the repo and point it to the location of your test application:
6869
> eng\copy-wpf.ps1 -destination "c:\mysampleproj"
6970
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:
76+
> eng\copy-wpf.ps1 -testhost -destination "c:\testhost\x86"
7177
72-
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:
8079

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
83-
will be used.
80+
> eng\copy-wpf.ps1 -testhost -destination "c:\testhost\x86" -version "3.0.0-preview6-27728-04"
8481
85-
- DOTNET_ROOT=<path_to_wpf_repo>\\.dotnet
86-
- DOTNET_MULTILEVEL_LOOKUP=0
82+
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+
```
8790

8891
**How to find location of the exe to test?**
8992
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
97100
higher version number is chosen. Assuming our locally built binaries are newer than what is
98101
installed, we can then simply reference those local binaries directly from the project file, like this:
99102

100-
*Note: you should build locally with the `-pack` param to ensure the binaries are put in the correct location.*
101103
```xml
102104
<PropertyGroup>
103105
<!-- 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
117119
```
118120

119121
### 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.
121123

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:
124125

125-
Below is an example powershell script of how you can use the `dotnet-install.ps1` script:
126-
127-
```
126+
```ps1
128127
$dotnet_install = "$env:TEMP\dotnet-install.ps1"
129128
$x64InstallDir = "$env:ProgramFiles\dotnet"
130129
$x86InstallDir = "${env:ProgramFiles(x86)}\dotnet"
@@ -154,7 +153,7 @@ In this example, the version of `Microsoft.WindowsDesktop.App` associated with t
154153
**Note**: The ability to install the WindowsDesktop runtime via the dotnet install script is being tracked by: https://github.com/dotnet/cli/issues/11115
155154

156155
#### 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:
158157
```xml
159158
<PropertyGroup>
160159
<MicrosoftWindowsDesktopAppVersion>3.0.0-preview5-27619-18</MicrosoftWindowsDesktopAppVersion>

eng/copy-wpf.ps1

Lines changed: 63 additions & 10 deletions
Original file line numberDiff line numberDiff line change
@@ -4,22 +4,25 @@ Param(
44
[string]$destination,
55
[string]$arch="x86",
66
[switch]$release,
7-
[switch]$local,
7+
[switch]$testhost,
8+
[string]$version,
89
[switch]$help
910
)
1011

1112
function Print-Usage()
1213
{
13-
Write-Host "Usage: copy-wpf.ps1 -destination <value> [-arch <value>] [-release] [-local]"
14+
Write-Host "Usage: copy-wpf.ps1 -destination <value> [-arch <value>] [-release] [-testhost] [-version]"
1415
Write-Host " This script helps developers deploy wpf assemblies to the proper location for easy testing. See "
1516
Write-Host " developer-guide.md for more information on how to use this script."
1617
Write-Host ""
1718
Write-Host "Common parameters:"
18-
Write-Host " -destination <value> Location of .csproj or .vbproj of application to test against. Ignored"
19-
Write-Host " if the -local parameter is used."
19+
Write-Host " -destination <value> Location of .csproj or .vbproj of application to test against. If using -testhost,"
20+
Write-Host " copies to the testhost location specified."
2021
Write-Host " -arch <value> Architecture of binaries to copy. Can be either x64 or x86. Default is x86."
2122
Write-Host " -release Copy release binaries. Default is to copy Debug binaries"
22-
Write-Host " -local Copy binaries over the local dotnet installation in the .dotnet folder"
23+
Write-Host " -testhost Copy binaries over the testhost installation of dotnet"
24+
Write-Host " -version When -testhost is used, will copy binaries over specified version of the"
25+
Write-Host " Microsoft.WindowsDesktop.App shared runtime"
2326
Write-Host " -help Print help and exit"
2427
Write-Host ""
2528
}
@@ -66,21 +69,71 @@ function CopyPackagedBinaries($location, $localBinLocation, $packageName, $binar
6669
}
6770
}
6871

69-
if ($help -or ([string]::IsNullOrEmpty($destination) -and !$local))
72+
function LocationIsSharedInstall($location, $arch)
73+
{
74+
if ($arch -eq "x86")
75+
{
76+
return $location -eq "${env:ProgramFiles(x86)}\dotnet"
77+
}
78+
else
79+
{
80+
return $location -eq "$env:ProgramFiles\dotnet"
81+
}
82+
}
83+
84+
if ($help -or [string]::IsNullOrEmpty($destination))
7085
{
7186
Print-Usage
7287
}
73-
elseif($local)
88+
elseif($testhost)
7489
{
75-
$destination = Join-Path $RepoRoot ".dotnet"
76-
Write-Host "Copying binaries to local installation"
77-
$location = Resolve-Path (Join-Path $destination "shared\Microsoft.WindowsDesktop.App\*")
90+
if ([string]::IsNullOrEmpty($version))
91+
{
92+
$location = Resolve-Path (Join-Path $destination "shared\Microsoft.WindowsDesktop.App\*")
93+
if ($location.Count -gt 1)
94+
{
95+
Write-Host "WARNING: Multiple versions of the Microsoft.WindowsDesktop.App runtime are located at $destination."
96+
Write-Host " Choosing the last installed runtime. Use -version flag to specify a different version."
97+
$runtimeToChoose = $location.Count-1
98+
99+
# If the last runtime is a backup, ignore it and choose the next one.
100+
if ($location[$runtimeToChoose].Path.Contains("Copy"))
101+
{
102+
$runtimeToChoose = $runtimeToChoose-1
103+
}
104+
$location = $location[$runtimeToChoose]
105+
}
106+
}
107+
else
108+
{
109+
$location = Resolve-Path (Join-Path $destination "shared\Microsoft.WindowsDesktop.App\$version")
110+
}
111+
112+
Write-Host "Copying binaries to dotnet installation at $location"
113+
78114
if(![System.IO.Directory]::Exists($location))
79115
{
80116
Write-Host "Location unavailable: " $location -ForegroundColor Red
81117
return
82118
}
83119
CopyBinariesToLocation $location
120+
121+
if (LocationIsSharedInstall $destination $arch)
122+
{
123+
# There is nothing fundamentally different about a test host installation versus trying to copy
124+
# into program files. We just won't set the DOTNET_ROOT or DOTNET_MULTILEVEL_LOOKUP.
125+
Write-Host "Copying to Program Files, skipping setting environment variables."
126+
}
127+
else
128+
{
129+
# Set DOTNET_ROOT variables so the host can find it
130+
$dotnetVariableToSet = if ($arch -eq "x86") { "env:DOTNET_ROOT(x86)"} else { "env:DOTNET_ROOT"}
131+
Write-Host "** Setting $dotnetVariableToSet to $destination **"
132+
Set-Item -Path $dotnetVariableToSet -Value $destination
133+
134+
Write-Host "** Setting env:DOTNET_MULTILEVEL_LOOKUP to 0 **"
135+
$env:DOTNET_MULTILEVEL_LOOKUP=0
136+
}
84137
}
85138
else
86139
{

0 commit comments

Comments
 (0)