首先,考虑一下运行平台。最终大家最终怎么用你的app。
我推荐用Web App。这个平台有最广泛的平台支持。基本上所有的电子产品现在都有网页浏览器,所以都支持Web App。工具也很全,容易上手。而且有Javascript的背景很有优势。
The following steps should be followed when contributing work to this repository.
Outages caused when system activities exceed the system’s capacity is a leading concern in system design. The ability to handle system activity efficiently, and gracefully limit the execution of activities before the system is under stress is a fundamental to system resiliency. .NET does not have a standardized means for expressing and managing resource limiting logic needed to produce a resilient system. This adds complexity to designing and developing resilient software in .NET by introducing an easy vector for competing resource limiting logic and anti-patterns. A standardized interface in .NET for limiting activities will make it easier for developers to build resilient systems for all scales of deployment and workload.
Users will interact with the proposed APIs in order to ensure rate and/or concurrency limits are enforced. This abstraction require explicit release semantics to accommodate non self-replenishing (i.e. concurrency) resource limits similar to how Semaphores o
Last week, we discussed the idea of consolidating some of the labels we use for issue management. The main goals of this effort are:
We want to add the capability to control the format of the logs produced by our console logger. Currently, there is an option to choose between Default (logging on multiple lines with colors) and Systemd. We would like to add a compact format which will log using a single line, as well as a JSON based log format. We would also like to add an extension point so that users can specify their own custom log format. The motivation for these log formats can be found at https://github.com/dotnet/extensions/issues/2479. Finally, we need to be able to control the formatter used as well as the formatters via Configuration.
We are considering limiting the scope of the formatter API to Logging.Console for now, instead of Logging.Abstractions.
| Category | Current Grade | Cost | Aspirational Grade | Notes | | |
|---------------------- |--------------- |------ |-------------------- |------- | | |
| Planning | C | L | B | There are now more documentation of this process via OKRs and specs so I feel the transparency has increased. | | |
| Design | C | XL | B | Need to factor in infrastructure when designing features. E.g. Blazor WebJS. | | |
| Build/Infrastructure | D | XL | B | Need to align with rest of dotnet, we have too much "special" logic. | | |
| Coding | B | XXL | A | Need to respond to community PRs more promptly. | | |
| Testing | C | L | B | How do we know we have the right amount of coverage? Coverage is mostly driven by devs but may become out of date over time. Need improvements in tooling for debuggability/reliabil |
Branching steps
?. Update Maestro subscriptions
using System; | |
using System.Buffers.Binary; | |
using System.Collections.Generic; | |
using System.Net.Http; | |
using System.Reflection; | |
using System.Security.Cryptography.X509Certificates; | |
using System.Text; | |
using Grpc.Core; | |
namespace Sample.Clients |
Distribution | Windows | Linux | macOS |
---|---|---|---|
x64 | 2.1 - crossgen'ed | 2.1 - crossgen'ed | 2.1 - no crossgen |
x86 | 2.1 - crossgen'ed | NA | NA |
Arm64 | post-3.0 pending | 3.0 - no crossgen, not tested | NA |
Arm32 | 2.2 - not tested | 2.2 - no crossgen, not tested | NA |
Musl64 | NA | 2.1 - no crossgen, not tested | NA |
using System; | |
using Microsoft.Win32; | |
namespace TestVersion | |
{ | |
class Program | |
{ | |
static void Main(string[] args) | |
{ | |
var key = Registry.LocalMachine.OpenSubKey(@"SOFTWARE\Microsoft\Windows NT\CurrentVersion"); |