diff --git a/Directory.Build.props b/Directory.Build.props
index 15d81ab..f9bb611 100644
--- a/Directory.Build.props
+++ b/Directory.Build.props
@@ -8,16 +8,6 @@
-
- false
- net462;
- netcoreapp3.0
- $(WindowsFrameworks)$(CoreFrameworks)
- win7-x64;win7-x86;win10-x64;win10-x86;
- osx-x64;debian.8-x64;ubuntu.16.10-x64;ubuntu.16.04-x64;opensuse-x64;ol-x64;rhel-x64;fedora-x64;centos-x64
- $(WindowsRuntimeIdentifiers)$(UnixRuntimeIdentifiers)
-
-
Microsoft Azure Relay Bridge
https://github.com/Azure/azure-relay-bridge
diff --git a/README.md b/README.md
index 235c25e..e2b0e80 100644
--- a/README.md
+++ b/README.md
@@ -1,224 +1,224 @@
-# Azure Relay Bridge
-
-![img](https://ci.appveyor.com/api/projects/status/github/clemensv/azure-relay-bridge)
-
-The Azure Relay Bridge is a tool that allows creating TCP tunnels between any
-pair of hosts, as long as those hosts each have outbound Internet connectivity on
-port 443 (HTTPS) to the Azure Relay service.
-
-The Relay Bridge is designed for reaching networked assets in any environment
-where it is impractical or impossible for those assets to be directly reachable
-through a public IP address.
-
-For instance, if you need to reach an on-premises database or application from
-a cloud-based solution, the on-premises assets are typically not accessible
-from the public network. The Relay Bridge can help establishing a TCP tunnel
-socket exclusive to a particular endpoint in such an on-premises environment,
-and without the complexity of a VPN solution.
-
-Another example are on-premises applications that run behind network gateways
-with dynamically assigned IP addresses, like in most residential and small-business
-environments. An Azure Relay endpoint provides a stable network destination for
-such application endpoints, without VPN, and without the complexity of a dynamic
-DNS registration.
-
-Inside cloud and data-center environments, reaching into and bridging between
-containerized workloads can also be tricky. The Relay Bridge can provide
-every service inside a container instance with a stable and externally reachable
-network address, and with the Relay's built-in load balancing support, you can
-even bind multiple services inside separate container instances to the same name.
-And you can do all that without configuring any kind of inbound network access
-to the containers.
-
-Practically all TCP-based services, including HTTP(S), are compatible with
-the Azure Relay Bridge. For services that require connections to be made from
-both parties, the bridge can concurrently act as local and remote bridge.
-
-All Azure Relay endpoints are secure, requiring TLS 1.2+ (aka SSL) WebSocket
-connections for all connections through the Relay, and both communicating
-parties must provide an authorization token to establish a connection via the
-Relay.
-
-The Azure Relay Bridge builds on this foundation and creates the illusion of a
-local connection to the target service by ways of a *local forwarder* that listens
-on a configured IP address and port, and that then forwards all incoming TCP
-connections to a *remote forwarder* via the Azure Relay. The *remote forwarder*
-connects each incoming connection to the target service.
-
-
-## azbridge
-
-The Relay Bridge is a command line utility ("azbridge") with binary distributions
-for Windows, macOS, and several Linux distributions. It can optionally also be
-configured and run as a background service on Windows and Linux.
-
-Since the tool helps with scenarios not dissimilar to SSH tunnels (but without
-requiring peer-to-peer connectivity) the command line syntax of *azbridge* uses
-elements that resemble SSH's equivalent tunnel functionality, especially the -L
-and -R arguments. The key difference to SSH is that *azbridge* always binds sockets
-to an Azure Relay name, and that Azure Relay acts as the identifier for the
-tunnel and as network rendezvous point.
-
-The bridge can either be used directly on the machines where a client or a server
-resides, or it can be used as a gateway solution. When used as *local forwarder
-gateway* (*-g* *-L*) and with externally resolvable listener addresses, the bridge
-resides on a host in the network and allows connections from clients across the
-network. The *remote forwarder* (*-R*) can always reach out to off-machine targets
-within its network scope.
-
-When the bridge is used locally, the client can configure DNS names of the target
-services in the local *hosts* file, picking a unique IP address out of the 127.x.x.x
-range for each service, and then configuring a local forwarder for the respective
-target address. Those addresses can only be reached on that local machine, shielding
-the client from exposing TCP bridges to others. For instance, for reaching the remote
-SQL Server "sql.corp.example.com", you would add an IP address like `127.1.2.3` to
-the "hosts" file as `127.1.2.3 sql.corp.example.com`, and then use a local forwarder
-configuration that refers to the `127.1.2.3` address, for example
-`azbridge -L 127.1.2.3:1433:relay`.
-
-When used as a *local forwarder gateway*, you will need to use addresses that can be
-reached by the clients in your network, and ideally have a multi-homed setup where
-the gateway node has a network address, e.g. from the `10.x.x.x` range, per remote
-target service host. For naming support, those network addresses should be registered
-in a DNS service reachable and used by the clients in your network. A DNS service is
-also required for resolving wildcard addresses, even for the local scenario.
-
-With a local configuration, when using *azbridge* to reach a Microsoft SQL Server
-instance endpoint (port 1433) on a different network, you would use the following
-constellation:
-
-* SQL Client connects to sql.corp.example.com:1433, whereby the local "hosts" file
- re-maps the server name to a local address with the entry
- `127.0.5.1 sql.corp.example.com`
-* Local bridge on the same machine the client runs as
- `azclient -L 127.0.5.1:1433:sql-corp-example-com -x {cxnstring}`
-* Azure Relay has a configured endpoint
- `wss://mynamespace.servicebus.windows.net/$hc/sql-corp-example-com`
-* Remote Bridge on or near the server runs as
- `azclient -R sql-corp-example-com:sql.corp.example.com:1433 -x {cxnstring}`
-* SQL Server runs as `sql.corp.example.com:1433`
-
-The `{cxnstring}` represents the connection string for the configured
-Azure Relay endpoint with appropriate send and/or listen permissions.
-
-The connection string can be obtained from the portal.
-
-Further details about how to use the tool and how to configure it can be found in
-the [Configuration and Command Line Options](CONFIG.md) document.
-
-## Downloads
-
-This is an early preview. Unsigned (!) binaries are available for direct download
-from the [Github Releases](../../releases) page for evaluation. Signed binaries will eventually
-be available for download with common package managers.
-
-## Installation
-
-The tool has installation packages for a variety of platforms. All packages are
-self-contained distributions, meaning they do not rely on a centrally installed
-runtime. However, depending on the package type and platform, the installation
-of some prerequisites may be required.
-
-### Windows
-
-The easiest way to install the bridge on Windows is by using the appropriate
-*.msi package. The installer adds the tool to the PATH and also registers
-the "azbridge" Windows service. The service is configured for on-demand
-(manual) start at installation time.
-
-> **KNOWN ISSUE:** These early builds are not signed. Download the MSI file,
-unblock it, and then install. Otherwise the application may not work as
-expected.
-
-### Linux
-
-### Debian, Ubuntu, Linuxmint
-
-For Debian 8+ and all Debian-based distributions, like Ubuntu 16.04+ and Linuxmint 16+,
-you can install the tool from the respective *.deb package with
-
-`sudo apt-get install ./{package-name}.deb`
-
-Using `apt-get` will automatically install the distribution prerequisites. The
-.NET Core platform required by the tool is private and not installed machine-wide.
-
-The package install will put the tool into `/usr/share/azbridge`, place a machine-wide
-configuration file into `/etc/azbridge`, add the tool to the PATH, and register two
-BASH extensions for adding and removing entries from the `/etc/hosts` file:
-
-* `addhost {ipaddress} {name}` - adds an IP address with the given hostname to "hosts"
-* `removehost {name}` - removes the entry for the given hostname
-
-### Fedora, CentOS, Red Hat Enterprise Linux
-
-For Fedora, CentOS, and Red Hat Enterprise Linux, you can install the tool from the
-respective *.rpm package with
-
-`sudo yum install {package-name}.rpm`
-
-Using `yum` will automatically install the distribution prerequisites. The
-.NET Core platform required by the tool is private and not installed machine-wide.
-
-The package install will put the tool into `/usr/share/azbridge`.
-
-> **KNOWN ISSUE 1:** The package will presently not install correctly if the install of
-> documentation files is suppressed for `yum` and/or `dnf`. The is the case for many
-> container base images. On CentOS, you should drop the respective configuration with
-> `sed -i '/tsflags=nodocs/d' /etc/yum.conf` (RUN in a Dockerfile before installing
-> the rpm) and on Fedora use `sed -i '/tsflags=nodocs/d' /etc/dnf/dnf.conf`.
-> **KNOWN ISSUE 2:** The package does not yet perform any of the post-install tasks that
-> the Debian package performs, meaning the tool is not added to the PATH.
-
-### Other distributions and platforms
-
-You can also install the tool from respective platform *.tar.gz archive. For Linux,
-you need to [explicitly install Linux prerequisites for .NET Core](https://docs.microsoft.com/en-us/dotnet/core/linux-prerequisites?tabs=netcore2x)
-for your respective distribution. For macOS, you need to [install prerequisites from
-this list](https://docs.microsoft.com/en-us/dotnet/core/macos-prerequisites?tabs=netcore2x).
-
-## Building the code
-
-The repo contains a complete build and verification structure for all platforms.
-
-The Windows version MUST be built on Windows because the service integration requires
-the full .NET Framework and the installer can only be built on Windows. You will at least
-need the "Build Tools for Visual Studio 2017", and ideally a local install of
-Visual Studio 2017 with desktop C# support.
-
-All other versions are built with the .NET Core 3.0 SDK. The DEB and
-RPM packages are only created when building on a Unix (i.e. Linux or macOS) host.
-dotb
-The ideal build environment is a Windows 10/Windows Server 2016 host with Docker for
-Windows installed. The `package-all.cmd` script will first build and package all Windows
-targets, and then launch a docker-based build with the official Microsoft .NET Core 3.0
-SDK image for the remaining targets. The `package.sh` script will only build and package
-the Unix targets, the `package.cmd` script only Windows targets.
-
-The latter two scripts are used with the AppVeyor build as well.
-
-All build output is placed into `./artifacts/build`
-
-## Tests
-
-Running the Unit tests and the Integration tests both require an Azure Relay namespace
-to be available for use and configured. Before running any of the test scenarios, the
-environment variable `AZBRIDGE_TEST_CXNSTRING` must be set to the Relay namespace
-connection string (enclosed in quotes) on the build platform.
-
-An [Azure Resource Manager template](https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-group-template-deploy-cli)
-to deploy a namespace with the definitions required for testing resides in
-`./src/tools/azure/test-resource-template.json`. The template expects the name of a new namespace
-and a region location as inputs.
-
-Once the template has been deployed using either Powershell or the Azure CLI, you can find
-the "sendListenConnectionString" value (starts with "Endpoint...") in the returned output.
-Copy and save that value for use in the `AZBRIDGE_TEST_CXNSTRING` environment variable.
-
-The Unit tests can be run from the command line with `dotnet test` with an .NET Core build.
-
-For integration testing that installs and executes the emitted packages, run `verify-build.cmd`/`verify-build.sh`. Expect for Windows, the integration tests depend on a
-local Docker installation: The script cleans any existing images, builds CentOS, Debian, Fedora, and Ubuntu images with the newly built binaries, and then executes a series of tests on each image.
-
-## Contributions
-
-We're gladly accepting contributions. Please review the [contribution rules](CONTRIBUTING.md).
+# Azure Relay Bridge
+
+![img](https://ci.appveyor.com/api/projects/status/github/clemensv/azure-relay-bridge)
+
+The Azure Relay Bridge is a tool that allows creating TCP tunnels between any
+pair of hosts, as long as those hosts each have outbound Internet connectivity on
+port 443 (HTTPS) to the Azure Relay service.
+
+The Relay Bridge is designed for reaching networked assets in any environment
+where it is impractical or impossible for those assets to be directly reachable
+through a public IP address.
+
+For instance, if you need to reach an on-premises database or application from
+a cloud-based solution, the on-premises assets are typically not accessible
+from the public network. The Relay Bridge can help establishing a TCP tunnel
+socket exclusive to a particular endpoint in such an on-premises environment,
+and without the complexity of a VPN solution.
+
+Another example are on-premises applications that run behind network gateways
+with dynamically assigned IP addresses, like in most residential and small-business
+environments. An Azure Relay endpoint provides a stable network destination for
+such application endpoints, without VPN, and without the complexity of a dynamic
+DNS registration.
+
+Inside cloud and data-center environments, reaching into and bridging between
+containerized workloads can also be tricky. The Relay Bridge can provide
+every service inside a container instance with a stable and externally reachable
+network address, and with the Relay's built-in load balancing support, you can
+even bind multiple services inside separate container instances to the same name.
+And you can do all that without configuring any kind of inbound network access
+to the containers.
+
+Practically all TCP-based services, including HTTP(S), are compatible with
+the Azure Relay Bridge. For services that require connections to be made from
+both parties, the bridge can concurrently act as local and remote bridge.
+
+All Azure Relay endpoints are secure, requiring TLS 1.2+ (aka SSL) WebSocket
+connections for all connections through the Relay, and both communicating
+parties must provide an authorization token to establish a connection via the
+Relay.
+
+The Azure Relay Bridge builds on this foundation and creates the illusion of a
+local connection to the target service by ways of a *local forwarder* that listens
+on a configured IP address and port, and that then forwards all incoming TCP
+connections to a *remote forwarder* via the Azure Relay. The *remote forwarder*
+connects each incoming connection to the target service.
+
+
+## azbridge
+
+The Relay Bridge is a command line utility ("azbridge") with binary distributions
+for Windows, macOS, and several Linux distributions. It can optionally also be
+configured and run as a background service on Windows and Linux.
+
+Since the tool helps with scenarios not dissimilar to SSH tunnels (but without
+requiring peer-to-peer connectivity) the command line syntax of *azbridge* uses
+elements that resemble SSH's equivalent tunnel functionality, especially the -L
+and -R arguments. The key difference to SSH is that *azbridge* always binds sockets
+to an Azure Relay name, and that Azure Relay acts as the identifier for the
+tunnel and as network rendezvous point.
+
+The bridge can either be used directly on the machines where a client or a server
+resides, or it can be used as a gateway solution. When used as *local forwarder
+gateway* (*-g* *-L*) and with externally resolvable listener addresses, the bridge
+resides on a host in the network and allows connections from clients across the
+network. The *remote forwarder* (*-R*) can always reach out to off-machine targets
+within its network scope.
+
+When the bridge is used locally, the client can configure DNS names of the target
+services in the local *hosts* file, picking a unique IP address out of the 127.x.x.x
+range for each service, and then configuring a local forwarder for the respective
+target address. Those addresses can only be reached on that local machine, shielding
+the client from exposing TCP bridges to others. For instance, for reaching the remote
+SQL Server "sql.corp.example.com", you would add an IP address like `127.1.2.3` to
+the "hosts" file as `127.1.2.3 sql.corp.example.com`, and then use a local forwarder
+configuration that refers to the `127.1.2.3` address, for example
+`azbridge -L 127.1.2.3:1433:relay`.
+
+When used as a *local forwarder gateway*, you will need to use addresses that can be
+reached by the clients in your network, and ideally have a multi-homed setup where
+the gateway node has a network address, e.g. from the `10.x.x.x` range, per remote
+target service host. For naming support, those network addresses should be registered
+in a DNS service reachable and used by the clients in your network. A DNS service is
+also required for resolving wildcard addresses, even for the local scenario.
+
+With a local configuration, when using *azbridge* to reach a Microsoft SQL Server
+instance endpoint (port 1433) on a different network, you would use the following
+constellation:
+
+* SQL Client connects to sql.corp.example.com:1433, whereby the local "hosts" file
+ re-maps the server name to a local address with the entry
+ `127.0.5.1 sql.corp.example.com`
+* Local bridge on the same machine the client runs as
+ `azclient -L 127.0.5.1:1433:sql-corp-example-com -x {cxnstring}`
+* Azure Relay has a configured endpoint
+ `wss://mynamespace.servicebus.windows.net/$hc/sql-corp-example-com`
+* Remote Bridge on or near the server runs as
+ `azclient -R sql-corp-example-com:sql.corp.example.com:1433 -x {cxnstring}`
+* SQL Server runs as `sql.corp.example.com:1433`
+
+The `{cxnstring}` represents the connection string for the configured
+Azure Relay endpoint with appropriate send and/or listen permissions.
+
+The connection string can be obtained from the portal.
+
+Further details about how to use the tool and how to configure it can be found in
+the [Configuration and Command Line Options](CONFIG.md) document.
+
+## Downloads
+
+This is an early preview. Unsigned (!) binaries are available for direct download
+from the [Github Releases](../../releases) page for evaluation. Signed binaries will eventually
+be available for download with common package managers.
+
+## Installation
+
+The tool has installation packages for a variety of platforms. All packages are
+self-contained distributions, meaning they do not rely on a centrally installed
+runtime. However, depending on the package type and platform, the installation
+of some prerequisites may be required.
+
+### Windows
+
+The easiest way to install the bridge on Windows is by using the appropriate
+*.msi package. The installer adds the tool to the PATH and also registers
+the "azbridge" Windows service. The service is configured for on-demand
+(manual) start at installation time.
+
+> **KNOWN ISSUE:** These early builds are not signed. Download the MSI file,
+unblock it, and then install. Otherwise the application may not work as
+expected.
+
+### Linux
+
+### Debian, Ubuntu, Linuxmint
+
+For Debian 8+ and all Debian-based distributions, like Ubuntu 16.04+ and Linuxmint 16+,
+you can install the tool from the respective *.deb package with
+
+`sudo apt-get install ./{package-name}.deb`
+
+Using `apt-get` will automatically install the distribution prerequisites. The
+.NET Core platform required by the tool is private and not installed machine-wide.
+
+The package install will put the tool into `/usr/share/azbridge`, place a machine-wide
+configuration file into `/etc/azbridge`, add the tool to the PATH, and register two
+BASH extensions for adding and removing entries from the `/etc/hosts` file:
+
+* `addhost {ipaddress} {name}` - adds an IP address with the given hostname to "hosts"
+* `removehost {name}` - removes the entry for the given hostname
+
+### Fedora, CentOS, Red Hat Enterprise Linux
+
+For Fedora, CentOS, and Red Hat Enterprise Linux, you can install the tool from the
+respective *.rpm package with
+
+`sudo yum install {package-name}.rpm`
+
+Using `yum` will automatically install the distribution prerequisites. The
+.NET Core platform required by the tool is private and not installed machine-wide.
+
+The package install will put the tool into `/usr/share/azbridge`.
+
+> **KNOWN ISSUE 1:** The package will presently not install correctly if the install of
+> documentation files is suppressed for `yum` and/or `dnf`. The is the case for many
+> container base images. On CentOS, you should drop the respective configuration with
+> `sed -i '/tsflags=nodocs/d' /etc/yum.conf` (RUN in a Dockerfile before installing
+> the rpm) and on Fedora use `sed -i '/tsflags=nodocs/d' /etc/dnf/dnf.conf`.
+> **KNOWN ISSUE 2:** The package does not yet perform any of the post-install tasks that
+> the Debian package performs, meaning the tool is not added to the PATH.
+
+### Other distributions and platforms
+
+You can also install the tool from respective platform *.tar.gz archive. For Linux,
+you need to [explicitly install Linux prerequisites for .NET Core](https://docs.microsoft.com/en-us/dotnet/core/linux-prerequisites?tabs=netcore2x)
+for your respective distribution. For macOS, you need to [install prerequisites from
+this list](https://docs.microsoft.com/en-us/dotnet/core/macos-prerequisites?tabs=netcore2x).
+
+## Building the code
+
+The repo contains a complete build and verification structure for all platforms.
+
+The Windows version MUST be built on Windows because the service integration requires
+the full .NET Framework and the installer can only be built on Windows. You will at least
+need the "Build Tools for Visual Studio 2017", and ideally a local install of
+Visual Studio 2017 with desktop C# support.
+
+All other versions are built with the .NET Core 3.0 SDK. The DEB and
+RPM packages are only created when building on a Unix (i.e. Linux or macOS) host.
+dotb
+The ideal build environment is a Windows 10/Windows Server 2016 host with Docker for
+Windows installed. The `package-all.cmd` script will first build and package all Windows
+targets, and then launch a docker-based build with the official Microsoft .NET Core 3.0
+SDK image for the remaining targets. The `package.sh` script will only build and package
+the Unix targets, the `package.cmd` script only Windows targets.
+
+The latter two scripts are used with the AppVeyor build as well.
+
+All build output is placed into `./artifacts/build`
+
+## Tests
+
+Running the Unit tests and the Integration tests both require an Azure Relay namespace
+to be available for use and configured. Before running any of the test scenarios, the
+environment variable `AZBRIDGE_TEST_CXNSTRING` must be set to the Relay namespace
+connection string (enclosed in quotes) on the build platform.
+
+An [Azure Resource Manager template](https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-group-template-deploy-cli)
+to deploy a namespace with the definitions required for testing resides in
+`./src/tools/azure/test-resource-template.json`. The template expects the name of a new namespace
+and a region location as inputs.
+
+Once the template has been deployed using either Powershell or the Azure CLI, you can find
+the "sendListenConnectionString" value (starts with "Endpoint...") in the returned output.
+Copy and save that value for use in the `AZBRIDGE_TEST_CXNSTRING` environment variable.
+
+The Unit tests can be run from the command line with `dotnet test` with an .NET Core build.
+
+For integration testing that installs and executes the emitted packages, run `verify-build.cmd`/`verify-build.sh`. Expect for Windows, the integration tests depend on a
+local Docker installation: The script cleans any existing images, builds CentOS, Debian, Fedora, and Ubuntu images with the newly built binaries, and then executes a series of tests on each image.
+
+## Contributions
+
+We're gladly accepting contributions. Please review the [contribution rules](CONTRIBUTING.md).
diff --git a/azure-pipelines.yml b/azure-pipelines.yml
new file mode 100644
index 0000000..10452d3
--- /dev/null
+++ b/azure-pipelines.yml
@@ -0,0 +1,54 @@
+# Azure Pipelines Build
+# https://docs.microsoft.com/azure/devops/pipelines/languages/dotnet-core
+
+trigger:
+- master
+
+variables:
+ BuildVersion.MajorMinor: 0.3
+ BuildVersion.Revision: $[counter(variables['Version.MajorMinor'], 0)]
+ BuildVersion: $(BuildVersion.MajorMinor).$(BuildVersion.Revision)
+
+jobs:
+ - job: WindowsBuild
+ workspace:
+ clean: all
+ pool:
+ vmImage: 'windows-latest'
+
+ steps:
+ - task: DotNetCoreCLI@2
+ inputs:
+ command: 'restore'
+ feedsToUse: 'select'
+ - task: MSBuild@1
+ inputs:
+ solution: '**/*.sln'
+ msbuildArguments: '/t:clean,package /p:WindowsOnly=true /p:Configuration=Release /p:VersionPrefix=$(BuildVersion) /p:VersionSuffix=rel'
+ - task: DotNetCoreCLI@2
+ inputs:
+ command: 'test'
+ arguments: '/p:WindowsOnly=true'
+
+ - publish: $(System.DefaultWorkingDirectory)\artifacts\build\net462
+ artifact: WindowsBuild
+
+ - job: LinuxBuild
+ workspace:
+ clean: all
+ pool:
+ vmImage: 'ubuntu-latest'
+
+ steps:
+ - task: ShellScript@1
+ inputs:
+ scriptPath: './package.sh'
+ arguments: '/p:VersionSuffix=rel'
+
+ - task: DotNetCoreCLI@2
+ inputs:
+ command: 'test'
+ arguments: '/p:RuntimeIdentifier=ubuntu-x64 /p:Configuration=Debug'
+
+ - publish: $(System.DefaultWorkingDirectory)/artifacts/build/netcoreapp3.0
+ artifact: XBuild
diff --git a/build/dependencies.props b/build/dependencies.props
index 457415f..8fc767d 100644
--- a/build/dependencies.props
+++ b/build/dependencies.props
@@ -31,7 +31,8 @@
3.0.0
3.0.0
2.4.1
- 2.3.1
+ 5.3.1
+ 2.4.1
2.4.1
2.4.0
12.0.3
diff --git a/build/repo.props b/build/repo.props
index 11adb09..5df708a 100644
--- a/build/repo.props
+++ b/build/repo.props
@@ -6,7 +6,7 @@
netcoreapp3.0
$(WindowsFrameworks)$(CoreFrameworks)
win7-x64;win7-x86;win10-x64;win10-x86;
- osx-x64;debian.8-x64;ubuntu.16.10-x64;ubuntu.16.04-x64;opensuse-x64;ol-x64;rhel-x64;fedora-x64;centos-x64
+ osx-x64;debian.8-x64;ubuntu.16.10-x64;ubuntu.18.04-x64;ubuntu.16.10-x64;ubuntu.18.10-x64;opensuse-x64;ol-x64;rhel-x64;fedora-x64;centos-x64
$(WindowsRuntimeIdentifiers)$(UnixRuntimeIdentifiers)
diff --git a/package.cmd b/package.cmd
index b6b85e3..4a6f6cc 100644
--- a/package.cmd
+++ b/package.cmd
@@ -1,3 +1,3 @@
if not "%APPVEYOR_BUILD_VERSION%"=="" set _VersionProp="/p:VersionPrefix=%APPVEYOR_BUILD_VERSION%"
-msbuild /t:clean,restore,build /p:WindowsOnly=true /p:Configuration=Debug %_BuildProp% %_VersionProp% %*
-msbuild /t:clean,restore,build,package /p:WindowsOnly=true /p:Configuration=Release %_BuildProp% %_VersionProp% %*
\ No newline at end of file
+if not "%BUILDVERSION%"=="" set _VersionProp="/p:VersionPrefix=%BUILDVERSION%"
+msbuild /t:clean,build,package /p:WindowsOnly=true /p:Configuration=Release %_BuildProp% %_VersionProp% %*
\ No newline at end of file
diff --git a/package.sh b/package.sh
index 7005d30..e37b96a 100755
--- a/package.sh
+++ b/package.sh
@@ -1,7 +1,7 @@
#!/bin/bash
pushd "${0%/*}" > /dev/null
if [ ! -z $APPVEYOR_BUILD_VERSION ]; then _VersionProp="/p:VersionPrefix=$APPVEYOR_BUILD_VERSION"; fi
+if [ ! -z $BUILDVERSION ]; then _VersionProp="/p:VersionPrefix=$BUILDVERSION"; fi
dotnet restore
-dotnet msbuild /t:clean,restore,build /p:Configuration=Debug /p:TargetFramework=netcoreapp3.0 $_BuildProp $_VersionProp $@
-dotnet msbuild /t:clean,restore,build,package /p:Configuration=Release /p:TargetFramework=netcoreapp3.0 $_BuildProp $_VersionProp $@
+dotnet msbuild /t:Package /p:Configuration=Release /p:TargetFramework=netcoreapp3.0 $_BuildProp $_VersionProp $@
popd
diff --git a/run.ps1 b/run.ps1
index bdce1ef..f5f88e3 100644
--- a/run.ps1
+++ b/run.ps1
@@ -1 +1 @@
-msbuild -t:Clean,Restore,Build $args
\ No newline at end of file
+msbuild -t:Clean,Build $args
\ No newline at end of file
diff --git a/src/Microsoft.Azure.Relay.Bridge/Microsoft.Azure.Relay.Bridge.csproj b/src/Microsoft.Azure.Relay.Bridge/Microsoft.Azure.Relay.Bridge.csproj
index 893dd57..a98afc7 100644
--- a/src/Microsoft.Azure.Relay.Bridge/Microsoft.Azure.Relay.Bridge.csproj
+++ b/src/Microsoft.Azure.Relay.Bridge/Microsoft.Azure.Relay.Bridge.csproj
@@ -1,13 +1,7 @@
- false
- net462;
- netcoreapp3.0
- $(WindowsFrameworks)$(CoreFrameworks)
- win7-x64;win7-x86;win10-x64;win10-x86;
- osx-x64;debian.8-x64;ubuntu.16.10-x64;ubuntu.16.04-x64;opensuse-x64;ol-x64;rhel-x64;fedora-x64;centos-x64
- $(WindowsRuntimeIdentifiers)$(UnixRuntimeIdentifiers)
+ true
@@ -64,6 +58,16 @@
+
+
+
+
+ if [ -f /etc/profile.d/azbridge.sh ]; then
+ rm /etc/profile.d/azbridge.sh;
+ fi
+
+
+
ResXFileCodeGenerator
diff --git a/src/azbridge/azbridge.csproj b/src/azbridge/azbridge.csproj
index 7ad9093..9edd2f3 100644
--- a/src/azbridge/azbridge.csproj
+++ b/src/azbridge/azbridge.csproj
@@ -1,16 +1,16 @@
- false
- net462;
- netcoreapp3.0
- $(WindowsFrameworks)$(CoreFrameworks)
-
- win7-x64;win7-x86;win10-x64;win10-x86;
- osx-x64;debian.8-x64;ubuntu.16.10-x64;ubuntu.16.04-x64;opensuse-x64;ol-x64;rhel-x64;fedora-x64;centos-x64
- $(WindowsRuntimeIdentifiers)$(UnixRuntimeIdentifiers)
+ true
+ true
+ false
+ true
+
+
+
+
Debug
Exe
@@ -28,25 +28,24 @@
-
-
-
-
- /etc/azbridge/azbridge_config.yml
+
+
+
+ /etc/azbridge/azbridge_config.svc.yml
-
- /etc/azbridge/azbridge_config.yml
+
+ /etc/azbridge/azbridge_config.machine.yml
-
-
-
-
-
-
+
+
+ /etc/profile.d/azbridge.sh
+ 0555
+
+
+
+
+
@@ -85,14 +84,7 @@
true
-
-
-
-
-
+
@@ -117,11 +109,18 @@
-
+
-
+
+
+
+
+
+
+
+
@@ -135,29 +134,22 @@
-
+
+
-
-
-
-
+
+
+
+
-
-
- . /usr/share/azbridge/debpostinst.sh
- . /usr/share/azbridge/debpostrm.sh
-
-
+
+
+
+
+
diff --git a/src/tools/bash/hostnames.sh b/src/azbridge/azbridge.sh
similarity index 97%
rename from src/tools/bash/hostnames.sh
rename to src/azbridge/azbridge.sh
index 12a355a..d0086a3 100755
--- a/src/tools/bash/hostnames.sh
+++ b/src/azbridge/azbridge.sh
@@ -1,5 +1,7 @@
#!/bin/bash
+export PATH="$PATH:/usr/share/azbridge"
+
# remove specified host from /etc/hosts
function removehost() {
diff --git a/src/azbridge/debpostinst.sh b/src/azbridge/debpostinst.sh
deleted file mode 100644
index bb6dc03..0000000
--- a/src/azbridge/debpostinst.sh
+++ /dev/null
@@ -1,11 +0,0 @@
-echo '#!/bin/bash' > /etc/profile.d/azbridge.sh
-echo 'export PATH="\$PATH:/usr/share/azbridge"' >> /etc/profile.d/azbridge.sh
-echo '. /usr/share/azbridge/hostnames.sh' >> /etc/profile.d/azbridge.sh
-chmod a+x /etc/profile.d/azbridge.sh
-if [ ! -d "/etc/azbridge" ]; then
- mkdir /etc/azbridge;
-fi
-if [ ! -f "/etc/azbridge/azbridge_config.machine.yml" ]; then
- mv /usr/share/azbridge/azbridge_config.machine.yml /etc/azbridge/azbridge_config.machine.yml;
-fi
-/etc/profile.d/azbridge.sh
\ No newline at end of file
diff --git a/src/azbridge/debpostrm.sh b/src/azbridge/debpostrm.sh
deleted file mode 100644
index a634a4c..0000000
--- a/src/azbridge/debpostrm.sh
+++ /dev/null
@@ -1,3 +0,0 @@
-if [ -f /etc/profile.d/azbridge.sh ]; then
- rm /etc/profile.d/azbridge.sh;
-fi
\ No newline at end of file
diff --git a/test/docker/ubuntu/build.cmd b/test/docker/ubuntu/build.cmd
index 0be9475..0993b37 100644
--- a/test/docker/ubuntu/build.cmd
+++ b/test/docker/ubuntu/build.cmd
@@ -10,7 +10,7 @@ if "%TargetFramework%"=="" set TargetFramework="netcoreapp3.0"
pushd "%~dp0"
if not exist "tmp" mkdir tmp
-set DebFile=azbridge.%VersionPrefix%-%VersionSuffix%.ubuntu.16.04-x64.deb
+set DebFile=azbridge.%VersionPrefix%-%VersionSuffix%.ubuntu.18.10-x64.deb
copy /y ..\..\..\artifacts\build\%TargetFramework%\%DebFile% tmp > NUL
docker build -f Dockerfile . --tag azbridge_ubuntu1604_test --build-arg deb_package=%DebFile%
rd /s /q tmp
diff --git a/test/docker/ubuntu/build.sh b/test/docker/ubuntu/build.sh
index 577b1f7..58b19a9 100755
--- a/test/docker/ubuntu/build.sh
+++ b/test/docker/ubuntu/build.sh
@@ -10,7 +10,7 @@ if [ -z ${TargetFramework+x} ]; then TargetFramework='netcoreapp3.0'; fi
pushd "${0%/*}" > /dev/null
if [ ! -d "tmp" ]; then mkdir tmp; fi
-DebFile=azbridge.$VersionPrefix-$VersionSuffix.ubuntu.16.04-x64.deb
+DebFile=azbridge.$VersionPrefix-$VersionSuffix.ubuntu.18.10-x64.deb
cp ../../../artifacts/build/$TargetFramework/$DebFile tmp/ > /dev/null
docker build -f Dockerfile . --tag azbridge_ubuntu1604_test --build-arg deb_package=$DebFile
diff --git a/test/unit/Microsoft.Azure.Relay.Bridge.Tests/Microsoft.Azure.Relay.Bridge.Tests.csproj b/test/unit/Microsoft.Azure.Relay.Bridge.Tests/Microsoft.Azure.Relay.Bridge.Tests.csproj
index fa94a2c..12c90f8 100644
--- a/test/unit/Microsoft.Azure.Relay.Bridge.Tests/Microsoft.Azure.Relay.Bridge.Tests.csproj
+++ b/test/unit/Microsoft.Azure.Relay.Bridge.Tests/Microsoft.Azure.Relay.Bridge.Tests.csproj
@@ -1,16 +1,5 @@
-
- false
- net462;
- netcoreapp3.0
- $(WindowsFrameworks)$(CoreFrameworks)
-
- win7-x64;win7-x86;win10-x64;win10-x86;
- osx-x64;debian.8-x64;ubuntu.16.10-x64;ubuntu.16.04-x64;opensuse-x64;ol-x64;rhel-x64;fedora-x64;centos-x64
- $(WindowsRuntimeIdentifiers)$(UnixRuntimeIdentifiers)
-
-
false
Azure Relay Bridge Tests