* Don't overwrite dotnet env when transforming projects into containers
* use System.Text.Json instead of Newtonsoft
* escaping the whitespace police!
* Apply suggestions from code review
Co-authored-by: David Fowler <davidfowl@gmail.com>
* Set up tests for new dashboardPort functionality
* Add in new dashboardPort values to test data
* Map from tye.yaml configuration file into Application model
* Core change: apply DashboardPort from configuration (if cli --port argument is not specified)
* Add dashboardPort documentation to the tye schema page
* PR feedback: requested YAML (JSON) schema update
* 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.
* 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
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.
David Fowler
josdeweger
dependabot[bot]
Phillip Hoff
Jean Llorca
Dan Simpson
Justin Kotalik
Hossam Barakat
TeBeCo
John Luo
Christian Kadluba
areller
Oscar
Shayne Boyer
Ryan Nowak
Igr Alexánder Fernández Saúco
Thang Chung
Simon Cropp