The Arcade SDK requires that the obj/ and bin/ folders be placed in the top-level artifacts/ folder of the repo. Although this PR does not complete our Arcade convergence, this is a step towards updating our repo to build with the Arcade SDK.
Changes:
* Set output path for build to artifacts/bin/$(ProjectName)/
* Set intermediate output path for build to artifacts/obj/$(ProjectName)/
* Cleanup .gitignore files (remove duplication between repo-root and tested gitignore files)
* Add code check which looks for project files that share the same name (could cause issues)
* Rename project files to have unique names (avoid race condition of build output)
* Update all locations which were hard-coded to expect bin/ and obj/ in the project directory
* Add overrides for tests which still assert test binaries exist in a given location relative to the source code
* Add Windows 7 and 8.1 testing on Helix
* Install SQL Server on-demand in Helix test queues
* Only install mssql on Windows runs
* Use exit /b
* Add targets to better support running helix locally
* Set maxretrycount to 2
* Handle IIS issues on win7/win8
* Make HelixPreCommand's fail the workitem
* Add a pre-generated test cert of IIS Express
* Update helix doc and ignore netsh script failures
* Fix bug in detecting Windows queues and disable Win 7 until we have queues ready
* Fix HttpSys functional tests on Helix
* Add yarn.lock file for NodeServices
* Remove references to 'npm install' (causes double-download of node modules) and replace npm commands in package.json with yarn for consistency
* Upgrade yarn to 1.15.2
Creating a sample for the header propagation package and some various
misc UX improvements based on building the sample.
A small list:
- allow duplicate inbound names
- de-dupe based on outbound names
- add sugar for configuration
- simplify pattern for transforming values
- add error message for missing middleware
Also a few small perf things.
I started this out by wanting to remove the following from the
configuration pattern:
```C#
options.Headers.Add("X-TraceId", null);
```
This pattern with null is undiscoverable, but we didn't provide
something simpler. The most common case was to add a custom collection
type so we can define sugar methods.
The next realization is that in practical case (dist tracing sample) you
either way to *key* off of the same inbound header twice, or you don't
have an inbound header at all, and you will synthesize the value every
time. This means that the way we're treating inbound header names is a
bit wrong. We don't want inbound header names to be unique, we want
*outbound header names to be unique*.
Next, I want to consolidate DefaultValue and ValueFactory. The problems
I saw with this:
- DefaultValue is a trap. It's rare to use a static value.
- ValueFactory really wants the header name *and* value
I think what's there now is much more terse to work with.
Attempt to improve reliability of running yarn commands. Our project structure might cause yarn to be launched multiple times. According to yarn docs, this option should avoid conflicts between multiple instances of yarn
https://yarnpkg.com/en/docs/cli/#toc-concurrency-and-mutex
Fixesaspnet/AspNetCore-Internal#2245
Our tests were flaking out due to this possible race where the directory browser middleware enumerates the directory but a file is deleted while we're formatting the response. This change just catches the FNF/DNF exceptions and suppresses the file from the directory listing
* Update dependencies from https://github.com/dotnet/arcade build 20190423.2
- Microsoft.DotNet.GenAPI - 1.0.0-beta.19223.2
* Adjust to GenApi change in `enum` ordering
- was sorted by name, now by value
* Chain coherent dependencies up through Extensions to EF Core packages
- should reduce incoherent PRs we get from `darc`
- react to AspNetCore-Tooling breaking changes
- use C# Preview version in Blazor integration tests
- update `EnsureOptions_ConfiguresDefaultParseOptions` test to match new C# version default
- react to new newline encoding behavior; thanx @ajaybhargavb!
- update product code and tests to use new GetItem API; thanx @NTaylorMullen!
- RazorProjectFileSystem breaking change
- update ref assemblies
- react to EF Core breaking changes
- react to EF Core method rename
- react to aspnet/EntityFrameworkCore@ccfc5edbc7
- react to aspnet/EntityFrameworkCore@6cb41531df breaking change
- disable new analyzer in `ScratchDatabaseFixture`
- skip `MvcTemplate_NoAuthImplAsync(...)` test for F#
- #8996
- exclude some runtime assemblies from crossgen; thanx @BrennanConroy!
- add direct references to Mvc in AzureAD samples
- unclear why the reference is no longer pulled in transitively
* Run `darc` to grab the latest
- CoreFx packages with version 4.6.0-preview4.19204.1 to ensure coherency
- core-setup packages with version 3.0.0-preview4-27604-05 to ensure coherency
- Extensions packages with verisn 3.0.0-preview4.19204.2 to ensure coherency
- EntityFrameworkCore packages with version 3.0.0-preview4.19204.7 from build 20190404.7
- AspNetCore-Tooling packages with version 3.0.0-preview4.19204.2 from build 20190404.2
* [MVC][Components] Prerendering + Robust reconnect
* Relayers prerendering support on a separate package on top of MVC and
components.
* Implements robust reconects with acknowledgements from the client.
* Improves interactive prerendering with the ability to reconnect to
prerendered components.
* Removes the need to register components statically when prerendering
them.
* Removes the need of using an element selector when prerendering an
interactive component.
* Updates the templates to use the new fallback routing pattern and
reenables the components test.
* Adds eslint to the Typescript project to help maintain a consistent
style.
* Adds logging to support better debugging based on the pattern used by
signalr.
* Fixes exception handling on the server to always report exceptions correctly to the client.
- This change introduces the concept of an IDeveloperPageException filter that runs whenever the developer exception page has encountered an error. It follows the middleware pattern (chain of resposibility) which allows short circuiting or decorating the default logic.
- Added tests
* Ported HeaderPropagation from aspnet/Extensions
* Introduced Middleware
* Refactored middleware logic
* Refactored builder extensions
* Copyright notice
* Test for friendly exception on Builder
* Fixed header name selection when no output name specified
* Set comparer for the dictionary of headers
* Refactored configuration as Dictionary
* Renamed state objects
* renamed OutboundHeaderName in configuration
* Changed DefaultValuesGenerator to ValueFactory
* Missing docs
* Removed AlwaysAdd and added tests for null entry in configuration
* Improved docs
* Update src/Middleware/HeaderPropagation/src/DependencyInjection/HeaderPropagationExtensions.cs
Co-Authored-By: alefranz <alessio@franceschelli.me>
* Moved dependency injection extensions
* DI: reused ServiceCollection extension in the HttpClientBuilder one
* Moved service registration
* Update src/Middleware/HeaderPropagation/src/HeaderPropagationEntry.cs
Co-Authored-By: alefranz <alessio@franceschelli.me>
* more docs
* Improved docs
* Update src/Middleware/HeaderPropagation/src/HeaderPropagationValues.cs
Co-Authored-By: alefranz <alessio@franceschelli.me>
* Fixed build
* Update eng/SharedFramework.Local.props
Co-Authored-By: alefranz <alessio@franceschelli.me>
* Updated tests for null config
* Reversed condition on HeaderPropagationMessageHandler as suggested
* Added docs for HeaderPropagationMessageHandler
* Changed proj to ship package to NuGet
* Make endpoint middleware explicit
This change makes the endpoint middleware explicit again, and updates
all of the templates.
The other change here is make UseEndpoints be the place where you
register endpoints. This is vital because it puts your code visually at
the point of the pipeline where it executes.
Lastly, I removed support for UseMvc with endpoint routing. This is
causing issues for some security features, and we're moving in the
direction of trying to make the middleware heavy implementation required
in 3.0. There are some issues we won't be able to fix in MVC if we can't
unambiguously know if UseMvc was used or the middleware.
* Improved selenium start and tear down
* Selenium is set up and torn down in an assembly fixture.
* Selenium is initialized lazily and in a non-blocking way.
* Selenium processes are tracked as part of the build and their pids
written to a file on disk for cleanup in the event of unexpected
termination of the test process.
* Browser fixture retries with linear backoff to create a remote
driver. Under heavy load (like when we are doing a simultaneous NPM
restore) the selenium server can become unresponsive so we retry
three times, with a longer comand timeout allowance each time up to
a max of 3 minutes.
* Moved test project setup to build time instead of runtime.
* Added target PrepareForTest to create the required files for testing
* The template creation folder.
* The template props file to use our built packages.
* The folder for the custom hive.
* Added assembly metadata attributes to find all the data we need to
run the tests.
* Path to the artifacts shipping packages folder.
* Path to the artifacts non-shipping packages folder.
* Path to the test templates creation folder.
* Path to use for the custom templating hive used in tests.
* Proper cleanup as part of the build
* Remove the test templates creation folder.
* Remove the test packages restore path.
* Recreate the test templates creation folder.
* Recreate the test packages restore path.
* Generated Directory.Build.Props and Directory.Build.Targets in the
test templates creation folder.
* Cleaned up potentially stale templatetestsprops.
* Improved test flows
* Initialization is done lazily and asynchronously.
* Selenium
* Browser fixture
* Template initialization.
* Flattened test flows to avoid assertions inside deep callstacks.
* All assertions happen at the test level with improved error messages.
* With the exception of the migrations assertions.
* Assertions contain information about which step failed, for what
project and what failure details.
* Broke down tests to perform individual steps instead of mixing build
and publish.
* Publish project.
* Build project. (Debug)
* Run built project.
* Run published project.
* Concentrated build logic into the Project class.
* Context between the different steps of a test is maintained in
this class.
* All operations that require coordination are performed within this
class.
* There is a lock for dotnet and a lock for nodejs. When building
SPAs we acquire the nodejs lock to correctly prevent multiple
runs of nodejs in parallel.
[ApiAuthorization template cleanups]
* Fix preview3 issues with breaking changes on Entity framework by
manually configuring the model in ApiAuthorizationDbContext.
* Add app.db to the project file when using local db.
* Fix linting errors on angular template.
* Fix react tests
* Add tests to cover new auth options in the SPA templates.