Today, most of the applications consist of multiple projects. Most of them have some kind of front-end application (e.g. Angular) that consumes one or more .NET C# APIs, which in their turn might also be linked to each other.
Because applications are built like this, running your local development environment can become a lot of work, and the environment also needs to be maintained. When there goes something wrong while spinning up the environment, for example, an API that isn't started, it can be hard to find the cause of the problem. This is time that is wasted. Your local environment might even take up a lot of resources when you have multiple Visual Studio or Rider instances open. Again, this is time that is wasted.
Thanks to the Project Tye this doesn't have to become a problem. The best thing is you aren't required to learn anything new, and you can get up and running in just a few minutes. Besides being easy to use, another benefit is that Tye contains a few utilities that can be used to help you with your development.
Tye is a tool that makes developing, testing, and deploying microservices and distributed applications easier. Project Tye includes a local orchestrator to make developing microservices easier and the ability to deploy microservices to Kubernetes with minimal configuration.
In this post, we're applying the Pareto Principle(80/20 rule) to discover how easy it is to set up Tye. By following this rule, our team can run our whole local environment with just a single command.
In the short run, using Tye just seems like an improvement to your developer experience. On its own, this already sounds like a good thing but in the long run, you'll also notice that a lot of time is saved.
Tye is installed as a global dotnet tool with the following command. For more info, take a look at the Getting Started guide.
When Tye is installed, create a
tye.yml file and start to configure your environment.
Do this by including your .NET projects to the
A service has a reference to the
csproj file that needs to be started.
Optionally, create a binding (ignore this if the port doesn't matter, tye randomly assigns an available port when the binding isn't specified) for this service.
As mentioned before, Tye is focused on the .NET ecosystem but you can also include different technologies, for example, an Angular front-end application. To do so, add the Angular application to your configuration as an executable. To start the Angular application, define the script to run the application.
As shown below, you can also add a reference to a different repository that contains a tye config.
Instead of the whole environment, it might be useful to solely run a subset of the environment.
tags within the configuration to filter the services.
Once your environment is configured, you can run it with the
tye run command.
After running the command, the hosted environment (with logs) is visible in the Tye dashboard.
http://localhost:8000 to open the dashboard.
Without using Tye, you probably started the API service manually by clicking on the
Doing this automatically hooked the debugger to the spawned process.
If you're using Tye, debugging is isn't automatically anymore. Instead, you have to attach your IDE to the spawned process when you want to start a debug session.
Bonus tip link
I like to be able to run my environment with a single command, no matter in which directory I'm currently in.
Therefore, I've added a shortcut to my PowerShell profile.
The profile executes the
tye command and provides it the full path of the config.
- Tye is installed as a global dotnet tool
- The environment is configured with the
- Run the environment with the
tye run --watchcommand
- To debug, attach your IDE to the spawned process
And that's it!
If you're hooked to Tye as I am, check out the Tye documentation for more information and different scenarios (with example configs).
I appreciate it if you would support me if have you enjoyed this post and found it useful, thank you in advance.