* Use environment variables for secrets
- Updating in place does not apply to connection strings specifically since they are usually configured at startup as singletons.
- This brings consistency with the development experience.
- Gets rid of AddTyeBindings
- "Less secure", sure but to be pedantic env variables are stored in virtual file on disk while the process is running. I'd argue if you want full security then use keyvault/vault/name your secret store.
Fixes#313
* Removed the last AddTyeSecrets call
Fixes: #206
This change only applies to the logic that we use to look at solution
files. This adds a heuristic that we only include projects with a
launchSettings.json for these operations (when considering a solution).
This will exclude unit test projects and class libraries.
In this case where the user has a `tye.yaml` then whatever's in there
will win. Likewise if a user passes a path to a project directly then
we'll try to run it without asking questions.
I chose `launchSettings.json` for this because it's a decision we can
make really quickly without having to run any MSBuild code. When we
think about operating on a solution with 50 projects with `tye run` we
really really don't want to have to evaluate each project with MSBuild
to figure out what kind of project it is (500ms).
Implements two flavor of library support for service-discovery:
- GetConnectionString (arbitrary strings) augmenting existing
functionality already in asp.net core
- GetServiceUri (uris) can be combined
from a protocol/host/port triple
See the **extensive** doc `service_discovery.md` that is filled out in this PR. That documents pretty much everything about how this works now.
- Ran into a strange case where some properties weren't being set (need to see if that means the right targets aren't running on the first pass). This was in a 2.1 application.
* Added container proxy for talking to the host
- This change introduces a container proxy which makes it possible for docker containers can talk to host services using container networking. These proxies will not show up in the dashboard as they are "infrastructure" containers.
- Added Private and NetworkAlias to DockerRunInfo but did not expose these configuration.
- All container communication is done using host names.
- Fix host shutdown again
- Bind to all interfaces on linux
* Add configuration option to enable the containers usage of an existing network
* Use IsNullOrEmpty instead IsNullOrWhiteSpace to check the value of Application.Network
* Add tests for network assignment
* Remove network-test assent and use frontend-backend for network tests
* Improve logs in DockerRunner
* Fix whitespaces
* Fix whitespace formatting
* Fix format with dotnet format
* Add assertions to make sure the app working on network tests
* Add test for container -> host communication.
* Small tweaks
- Modify frontend-backend app to print backend url
- Fix log in docker runner
- Rename test to use docker instead of container
* More clean up
- Don't set container port if the service isn't a container
* Bind to all interfaces on linux only
This removes the need to copy-paste code that reads a specific directory
in Program.cs.
Updated docs/samples and tests.
We need a workaround in tests to be able to use a P2P for the library. What
I did here is the same trick we do in Razor.
- Force everyone to use an MSBuild variable to locate the library
- Set that variable in a Directory.Build.props for the normal build
- Drop a special Directory.Build.props for testing
Updates a bunch of test code to use new helper methods for copying
stuff, so we can correctly do this.
- Turns out the same alias works fine and docker will
associate multiple IPs with a single alias
- Remove the docker run command from the output and leave it in the log
- Dump out the backend host names in the frontend backend example