* adding a sample project with plural form of TargetFrameworks for debugging purpose
* add --framework argument to RunCommand
* Pass down "framework" as a BuildProperty if not already defined in the YAML
* Do no throw anymore when multiple TargetFrameworks are found, if one was specified as a BuildProperty
* replicating Signature change on code base (that does not look like a good idea)
* adding comment to be explicit on what this does
* Check that the specified BuildProperties["TargetFramework"] is on of the TargetFrameworks
* add launchSettings for debug
* Create a BuildCommandArguments for the BuildCommand / add a "framework" options to it and move some logic to the CommandHandler (just like the RunCommand)
* add "-f {framework}" to dotnet publish if a TargetFramework BuildProperties exists
* Create a GenerateCommandArguments for the GenerateCommand / add a "framework" options to it and move some logic to the CommandHandler
* Create a PushCommandArguments for the PushCommand / add a "framework" options to it and move some logic to the CommandHandler
* Create a UndeployCommandArguments for the UndeployCommand / add a "framework" options to it and move some logic to the CommandHandler
* Create a DeployCommandArguments for the DeployCommand / add a "framework" options to it and move some logic to the CommandHandler
* framework is now an optional parameter defaulted to null
Co-authored-by: Justin Kotalik <jukotali@microsoft.com>
* Change sample to use LTS only
* Make "framework" argument nullable / optional / defaulted to null
* remove "Force" from "PushCommand" and "PushCommandArguments" if it's not used
* re-use the equivalent message than "dotnet run" on a project with multiple TargetFrameworks
* Create a StandardOptions for Framework
* Remove unused StandardOption.Force and add StandardOption.CreateForce with customizable "description"
* Use StandardOptions.Framework in various commands
* use StandardOptions.Force ni various commands
* Create a new InitCommandArguments and re-use the same OutputContext like the other Commands
* prefer type alias (String.IsNullOrEmpty => string.IsNullOrEmpty), not sure if it was intended
* Adding assets for E2E about multi-targetframeworks that returns the current TargetFramework on every HttpRequest
* Adding test for "tye run" with either buildProperties in the yaml or framework passed directly to ApplicationFactory.CreateAsync
* Add test and testasset project for both TargetFrameworks and TargetFramework
* Always overwrite the TargetFramework if one is specified from the CLI (like dotnet CLi) even if it means it wont build / run etc ....
* Test the ability to override TargetFramework from CLI even if define in csproj or in yaml
* Consistency over ApplicationFactory.CreateAsync in all E2E tests
* rename testasset project to multi-targetframeworks to match generated Dockerfile
* Add E2E for tye build when project uses multi-targetframeworks
* Adding test directly for ApplicationFactory to check that it overrides YAML existing buildProperties
* Adding test to make sure it still throw if there's no explicit TargetFramework or that it is one of the predefined one
* Adding test for ApplicationFactory.CreateAsync with a framework if nothing is set in yaml
* make cli arguments class private
* review: remove extra line
* review: remove 'framework' notion from Undeploy
* Fix project evaluation of multi-targetd projects
* Fixup a few more tests
* Comment updates
* Ensure TFM is only applied for multi-targeting projects
Co-authored-by: Justin Kotalik <jukotali@microsoft.com>
Co-authored-by: John Luo <johluo@microsoft.com>
* Fixed issue #620
* Produce a useful error message if the path of a project file is incorrect in tye.yaml.
* Added a test.
* Fixed test on Linux and OSX.
* Check full exception message in test and fixed test name.
* More deterministic behavior considering directory check and test execution.
Moved directory check one level higher from EnsureMSBuildRegistered() to the caller ReadProjectDetailsAsync(). This means that this code is always executed. In EnsureMSBuildRegistered() it was only executed once per proces because of the static field "registered". The placement of the check after evaluation of the the field "registered" was the reason why the test WrongProjectPathProducesCorrectErrorMessage worked when executed alone but not when any other test that called EnsureMSBuildRegistered() was executed before.
With this change the directory check is always executed now, even if the EnsureMSBuildRegistered() was already executed successfully. But the performance impact should not be significant while the type of generated error message is more deterministic and not dependent on execution order.
* Removing color from deployed app console logs
* Updating generated testassets for E2E test fixes wrt Type Serialization.
* Removing color for ApplyContainerDefaults with DockerFileServiceBuilder, fixing test files to include new env variables
* Removing color dependent code in DockerfileGenerator.cs for DockerFileServiceBuilder
* Add buildArgs to service configuration and capture build configuration as global property to setup msbuild project
* Fix format
* Fix - Error CS8600: Converting null literal or possible null value to non-nullable type.
* Improve configuration format for build arguments
* Fix whitespace format
* Fix error CS8618: Non-nullable property 'Properties' is uninitialized. Consider declaring the property as nullable.
* Fix error CS8601: Possible null reference assignment.
* Translate non first class properties as /p:{Key}={Value} into the build command
* Fix property translation
* All properties are used to create the msbuild project
* Change the name (to BuildProperties) and the type (to List<BuildProperty>) of ConfigService property to load build properties
* Add support of build properties when tye run with --docker option
* Fix ComprehensionalTest
* Add tests to verify the output directory for the corresponding build configuration
* Fix whitespace format
* Override the correct CreateTestCasesForTheory to fix error CS0618
* Remove the usage of BuildPropertiesToOptionsMap and fix the code format
* 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.
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.
* Add Dapr integration to Tye
Adds a new `extensions` integration point. Currently all extensbility has
to be inside the Tye codebase. There's no functionality for loading or distributing
plugins.
Enable dapr for an application like:
```yaml
name: test_app
extensions:
- name: dapr
```
The dapr extension currently accepts and requires no additional options, and applies
to all services defined in the application.
What it does:
- In local run: starts a dapr sidecar for each project that does http
- In local run: sidecars start in the directory of tye.yaml, so dapr will look for
component manifests in ./components (relative to tye.yaml
- In deployment: adds required annotations to deployments
Some new features that were added to tye to enable this:
- Config: Ability to parse and conditionally run extensions
- Run: Ability to token replace env-vars into command line args
- Deploy: Ability to configure labels and annotations
* format
* Massage labesl:
* PR feedback
* Fix tests
Fixes: #189Fixes: #153
This change rejiggers the docker build infrastructure to publish the project
and generate a Dockerfile in the same directory. This way they can't be on
separate drives!
Also added some focused tests for single-phase docker build.
Merged the data model we use for m8s features with the features
that come from rynowak/opulence. The `ApplicationBuilder` type (and related
types) now capture all of the details we use for everything.
There's a lot of just moving stuff around in this change - the goal
is to have a separate data model for:
- The config we read
- The representation we mutate
- The data model used by Tye.Hosting
So in this PR there's a lot of righthand/lefthand.
This tries to add some auto-detect magic to make common scenarios work
without any extra configuration, which avoiding doing obtuse stuff.
- We ignore the ports in launch settings (avoid conflict in the
hello world multi-project case)
- When we infer bindings based on launch settings we set them to
auto-select a port
- The user setting a port via tye.yaml will always win
- Bindings that are not inferred from launch settings still work
the same way (we don't auto-auto-select a port)
- When we deploy we ignore https
The HTTPS behavior might need discussion, but we haven't started looking
at a recipe for HTTPs inside the cluster in k8s, and it's not clear
whether we even want to.
One could also make the argument that we should skip TLS locally because
we're not doing it inside the cluster. Someone writing an app today that
assumes TLS in their code (using https URLs, or gRPC + TLS) will have
a non-trivial path to k8s for now anyway. So, skipping https bindings
for k8s really just makes us more honest.
Justin Kotalik
Glenn Condron
Thomas Freudenberg
Hossam Barakat
TeBeCo
John Luo
Christian Kadluba
areller
Matt Smith
Oscar
Shayne Boyer
Ryan Nowak
Igr Alexánder Fernández Saúco
Thang Chung
Justin Kotalik
David Fowler
Simon Cropp