* Adding a document on how to use WCF .NET Core in Windows and Linux containers
addressing feedback comments
* A quick start on WCF Core client in containers
Updated with latest comments and feedback.
We have removed the Bridge, so we should rename all references to "Bridge" to
something less technology specific
Also moving the TestRootCertificateInstaller.(sh|cmd) scripts to the appropriate
scripts directory
Move documentation from certificates to Documentation/archives as a reference
for how we used to use makecert. The documentation might be useful in testing,
but the certificates themselves are removed as they're expired and no longer work.
These changes make it possible to tell the run-test.sh script
that OuterLoop tests should be included. More work is required
to allow a CI machine to host a 2nd machine, but this PR makes
it possible to test manually.
This PR also enhances the error reporting from BridgeClient to
improve the debugging experience talking x-machine to the WCF
Bridge component.
The run-test.sh script is based heavily on the CoreFx version
and adds the additional logic to overlay WCF binaries.
The cross-platform-testing.md is also based heavily on the CoreFx
version and is updated for WCF.
Using the steps in cross-platform-testing.md, most WCF unit tests
pass in Linux.
Bridge.exe now has an app manifest that allows it to run
as admin (UAC prompting if appropriate).
The Bridge.exe command line options have now been improved
to match the names in TestProperties and BridgeConfiguration.
And it is possible to give Bridge.exe a .json file to initialize
multiple Bridge options.
The prior certificates used for https tests were replaced with
newer versions, and they are installed and uninstalled by the
Bridge as needed.
All firewall rule and certificate cleanup that used to happen
in other scripts is now handled by the Bridge itself. And those
prior scripts have been removed.
The BridgeController was added and a DELETE request to it will
shutdown the Bridge cleanly.
These changes allow the firewall rules created by the Bridge
to be scoped to specific IP's to allow them to be secured against
unauthorized access.
Remotely starting the Bridge has been made easier with a new script.
and a new markdown file describes how to run the Bridge remotely.