Skip to content
This repository has been archived by the owner on Nov 20, 2023. It is now read-only.

Releases: dotnet/tye

Tye 0.1

10 Apr 02:19
ba761e3
Compare
Choose a tag to compare
Tye 0.1 Pre-release
Pre-release

Tye 0.1 Release notes

These are the release notes for the 0.1 release of Tye.

This is the first release uploaded to nuget.org. From here on, we'll be uploading stable builds of Tye to nuget.org approximately every 4 weeks. If you want to have a more stable experience with Tye, then using the builds on nuget.org will give you something that has documentation and has been tested.

The package version is: 0.1.0-alpha.20209.5

See getting started for installation instructions.

Documentation improvments

We've done some reorganization of our documentation, and started to fill out more reference material that describes how Tye works. You can find this in the docs folder.

We've added documentation about how to keep tye up to date with our CI builds as part of getting started.

Notable changes and features

Service discovery

Service discovery (getting URIs and connection strings for other services) has undergone some major revisions to become more consistent and easy to use.

There's new documentation for service discovery that describes the functionality in detail.

We have a new library Microsoft.Tye.Extensions.Configuration that builds on top of Microsoft.Extensions.Configuration to make service discovery easier. This library replaces the copy-pasted code that was previously in our samples and tutorials.

We now have different recommendations about when to use connection strings and when to use URIs for services. TLDR: use URIs for simple things that don't require credentials or parameters, use connection strings for things that are database-like. See the service discovery documentation.

Connection strings in bindings now support some basic templating to make them more useful in a broad array of scenarios. This improvement is meant to remove the need to build connection strings manually in code. Build them in config instead! Let us know what you think.

tye deploy now understands the difference between a URI and a connection string. Previously tye deploy would assume that all non-.NET-projects provide a connection string. Now service discovery will function in the same way between a local application and deployed application.

In the spirit of making local development and deployed applications more similar, we now use environment variables for service discovery in deployed applications.

Improved local development

We've made many improvements to local development - mostly focuses on seamless interop between .NET services running on the local machine and services running in containers.

We now set both ASPNETCORE_ENVIRONMENT and DOTNETCORE_ENVIRONMENT environment variables to Development when using tye run. This is needed for projects based on older versions of ASP.NET Core.

We now suppress console logging colors for .NET applications, resulting in cleaner console output in development.

tye run has the ability to run your .NET services in containers. Use tye run --docker to try it out. This functionality has been added so that you can test a step in-between local development and a deployed application.

Container images will now be pulled prior to starting any services. This gives better UI feedback when pull is taking a long time. This also prevents errors when a service needs all of its dependencies running to start.

Services running in containers now support using named volumes. This allows you to configure Tye to use an existing Docker volume - which is handy when you have persistent data to provide to a container.

name: volume-test
services:
- name: volume-test
  project: volume-test.csproj
  volumes:
   - name: data-vol
     target: /data

This example (from our tests) shows a .NET project using a named volume, and could be run using tye run --docker to run the .NET project in a container.

Named volumes are also available for container images running as services.

We've fixed an issue that was preventing services running in containers on linux from communicating with services running in the user's namespace (localhost). We now workaround docker/for-linux#264 on Linux so that the development experience is consistent with macOS and Windows.

tye.yaml now supports specifying a Docker network.

name: my-application
network: my-network
services:
...

When a network is specified, tye run will place all of the containers on that pre-existing network.

When multiple containers are running, Tye will now create a Docker network and place all of the containers inside it. If a network name was specified, that will be used instead of creating a new one.

Tye now creates a proxy for each service running in the user's namespace and places it in the docker network with all container image services. This makes it possible to use hostnames to route traffic outside of the docker network - and makes development similar to deployed applications.

Improvements to Tye dashboard

We've made some UX improvements to the Tye dashboard. We have a new color scheme.

We also now have a basic metrics display as part of the dashboard. This is similar to dotnet counters but its for all of your services, and it's got a UI. Click on the name of a .NET service to see.

We've changed the message shown when dashboard server is disconnected. Previously this was the default Blazor-server message, now we've made it more clear.

Ingress for local development

tye run now supports ingress for local development. We were hoping to add support for ingress in deployed applications in this release, but it didn't make the cut.

name: apps-with-ingress
ingress:
  - name: ingress
    bindings:
      - port: 8080
    rules:
      - path: /A
        service: appA
      - path: /B
        service: appB
      - host: a.example.com
        service: appA
      - host: b.example.com
        service: appB  

services:
- name: appA
  project: ApplicationA/ApplicationA.csproj
  replicas: 2
- name: appB
  project: ApplicationB/ApplicationB.csproj
  replicas: 2

In this example we'll run nginx in a container and use it as a proxy for services appA and appB. The proxy will listen on localhost:8080 and route traffic based on the rules defined here.

Misc changes

We've added cleanup functionality to tye run. If the tye host process crashes, we'll keep a record in a local folder ./tye of what was running at the time. Any dangling processes will be cleaned up if you do tye run again.

The code for reading tye.yaml has undergone an extensive rewrite. We now validate many more things from tye.yaml for correctness.

As part of this change the name: property at the top level is now officially optional in the schema and documentation. Tye would previously tolerate omitting it, but we've now officially documented that it's optional. The directory name (converted to lowercase) will be used instead.

tye init and other tye ... commands that operate on a solution file have different logic for including and excluding projects. We now consider all projects that have a launchSettings.json to be runnable - which exludes unit test projects and class libraries.

Tye now uses MSBuild to read some information from each .NET project as part of tye run. This fixed many bugs that were due to hardcoded assumptions about target frameworks, output paths, etc. As part of this change we now support .NET project settings that affect running in IDEs like <RunArguments>.

We've added integration between tye and Dapr for local development and deployment. Tye makes it easy to do development with multiple applications using Dapr. Find docs here.

We've added dtye aliases to make it easier to contribue to the repo.

Example:

# sourcing activate.sh puts dotnet on the path and adds `dtye` as an alias
. ./activate.sh

# find a sample
cd samples/multi-project

# runs the `tye run` command but using the local source code for tye
dtye run

Equivalent scripts are provided for powershell/Windows.

Community contributions