HtmlToText
thomas levesque's .net blog search primary menu skip to content about search for: uncategorized asynchronous initialization in asp.net core with custom middleware july 20, 2018 thomas levesque 11 comments sometimes you need to perform some initialization steps when your web application starts. however, putting such code in the startup.configure method is generally not a good idea, because: there’s no current scope in the configure method, so you can’t use services registered with "scoped" lifetime (this would throw an invalidoperationexception : cannot resolve scoped service ‘myapp.imyservice’ from root provider ). if the initialization code is asynchronous, you can’t await it, because the configure method can’t be asynchronous. you could use .wait to block until it’s done, but it’s ugly. async initialization middleware a simple way to do it involves writing a custom middleware that ensures initialization is complete before processing a request. this middleware starts the initialization process when the app starts, and upon receiving a request, will wait until the initialization is done before passing the request to the next middleware. a basic implementation could look like this: public class asyncinitializationmiddleware { private readonly requestdelegate _next; private readonly ilogger _logger; private task _initializationtask; public asyncinitializationmiddleware(requestdelegate next, iapplicationlifetime lifetime, ilogger<asyncinitializationmiddleware> logger) { _next = next; _logger = logger; // start initialization when the app starts var startregistration = default(cancellationtokenregistration); startregistration = lifetime.applicationstarted.register(() => { _initializationtask = initializeasync(lifetime.applicationstopping); startregistration.dispose(); }); } private async task initializeasync(cancellationtoken cancellationtoken) { try { _logger.loginformation("initialization starting"); // do async initialization here await task.delay(2000); _logger.loginformation("initialization complete"); } catch(exception ex) { _logger.logerror(ex, "initialization failed"); throw; } } public async task invoke(httpcontext context) { // take a copy to avoid race conditions var initializationtask = _initializationtask; if (initializationtask != null) { // wait until initialization is complete before passing the request to next middleware await initializationtask; // clear the task so that we don't await it again later. _initializationtask = null; } // pass the request to the next middleware await _next(context); } } we can then add this middleware to the pipeline in the startup.configure method. it should be added early in the pipeline, before any other middleware that would need the initialization to be complete. public void configure(iapplicationbuilder app, ihostingenvironment env) { if (env.isdevelopment()) { app.usedeveloperexceptionpage(); } app.usemiddleware<asyncinitializationmiddleware>(); app.usemvc(); } dependencies at this point, our initialization middleware doesn’t depend on any service. if it has transient or singleton dependencies, they can just be injected into the middleware constructor as usual, and used from the initializeasync method. however, if the dependencies are scoped, we’re in trouble: the middleware is instantiated directly from the root provider, not from a scope, so it can’t take scoped dependencies in its constructor. depending on scoped dependencies for initialization code doesn’t make a lot of sense anyway, since by definition scoped dependencies only exist in the context of a request. but if for some reason you need to do it anyway, the solution is to perform initialization in the middleware’s invoke method, injecting the dependencies as method parameters. this approach has at least two drawbacks: initialization won’t start until a request is received, so the first requests will have a delayed response time; this can be an issue if the initialization takes a long time. you need to take special care to ensure thread safety: the initialization code must run only once, even if several requests arrive before initialization is done. writing thread-safe code is hard and error-prone, so avoid getting in this situation if possible, e.g. by refactoring your services so that your initialization middleware doesn’t depend on any scoped service. uncategorized hosting an asp.net core 2 application on a raspberry pi april 17, 2018 thomas levesque 12 comments as you probably know, .net core runs on many platforms: windows, macos, and many unix/linux variants, whether on x86/x64 architectures or on arm. this enables a wide range of interesting scenarios… for instance, is a very small machine like a raspberry pi , which its low performance arm processor and small amount of ram (1 gb on my rpi 2 model b), enough to host an asp.net core web app? yes it is! at least as long as you don’t expect it to handle a very heavy load. so let’s see in practice how to deploy an expose an asp.net core web app on a raspberry pi. creating the app let’s start from a basic asp.net core 2.0 mvc app template: dotnet new mvc you don’t even need to open the project for now, just compile it as is and publish it for the raspberry pi: dotnet publish -c release -r linux-arm prerequisites we’re going to use a raspberry pi running raspbian, the official linux distro for raspberry pi, which is based on debian. to run a .net core 2.0 app, you’ll need version jessie or higher (i used raspbian stretch lite). update : as tomasz mentioned in the comments, you also need a raspberry pi 2 or more recent, with an armv7 processor; the first rpi has an armv6 processor and cannot run .net core. even though the app is self-contained and doesn’t require .net core to be installed on the rpi, you will still need a few low-level dependencies; they are listed here . you can install them using apt-get : sudo apt-get update sudo apt-get install curl libunwind8 gettext apt-transport-https deploy and run the application copy all files from the bin\release\netcoreapp2.0\linux-arm\publish directory to the raspberry pi, and make the binary executable (replace mywebapp with the name of your app): chmod 755 ./mywebapp run the app: ./mywebapp if nothing went wrong, the app should start listening on port 5000. but since it listens only on localhost , it’s only accessible from the raspberry pi itself… exposing the app on the network there are several ways to fix that. the easiest is to set the aspnetcore_urls environment variable to a value like http://*:5000/ , in order to listen on all addresses. but if you intend to expose the app on the internet, it might not be a good idea: the kestrel server used by asp.net core isn’t designed to be exposed directly to the outside world, and isn’t well protected against attacks. it is strongly recommended to put it behind a reverse proxy, such as nginx . let’s see how to do that. first, you need to install nginx if it’s not already there, using this command: sudo apt-get install nginx and start it like this: sudo service nginx start now you need to configure it so that requests arriving to port 80 are passed to your app on port 5000. to do that, open the /etc/nginx/sites-available/default file in your favorite editor (i use vim because my rpi has no graphical environment). the default configuration defines only one server, listening on port 80. under this server, look for the section starting with location / : this is the configuration for the root path on this server. replace it with the following configuration: location / { proxy_pass http://localhost:5000/; proxy_http_version 1.1; proxy_set_header connection keep-alive; } be careful to include the final slash in the destination url. this configuration is intentionnally minimal, we’ll expand it a bit later. once you’re done editing the file, tell nginx to reload its configuration: sudo nginx -s reload from your pc, try to access the app on the raspberry pi by entering its ip address in you
Informations Whois
Whois est un protocole qui permet d'accéder aux informations d'enregistrement.Vous pouvez atteindre quand le site Web a été enregistré, quand il va expirer, quelles sont les coordonnées du site avec les informations suivantes. En un mot, il comprend ces informations;
Domain Name: THOMASLEVESQUE.COM
Registry Domain ID: 1716121666_DOMAIN_COM-VRSN
Registrar WHOIS Server: whois.ovh.com
Registrar URL: http://www.ovh.com
Updated Date: 2017-04-01T03:28:18Z
Creation Date: 2012-04-26T08:34:12Z
Registry Expiry Date: 2018-04-26T08:34:12Z
Registrar: OVH
Registrar IANA ID: 433
Registrar Abuse Contact Email:
Registrar Abuse Contact Phone:
Domain Status: clientDeleteProhibited https://icann.org/epp#clientDeleteProhibited
Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited
Name Server: DNS101.OVH.NET
Name Server: NS101.OVH.NET
DNSSEC: unsigned
URL of the ICANN Whois Inaccuracy Complaint Form: https://www.icann.org/wicf/
>>> Last update of whois database: 2017-08-29T13:58:31Z <<<
For more information on Whois status codes, please visit https://icann.org/epp
NOTICE: The expiration date displayed in this record is the date the
registrar's sponsorship of the domain name registration in the registry is
currently set to expire. This date does not necessarily reflect the expiration
date of the domain name registrant's agreement with the sponsoring
registrar. Users may consult the sponsoring registrar's Whois database to
view the registrar's reported date of expiration for this registration.
TERMS OF USE: You are not authorized to access or query our Whois
database through the use of electronic processes that are high-volume and
automated except as reasonably necessary to register domain names or
modify existing registrations; the Data in VeriSign Global Registry
Services' ("VeriSign") Whois database is provided by VeriSign for
information purposes only, and to assist persons in obtaining information
about or related to a domain name registration record. VeriSign does not
guarantee its accuracy. By submitting a Whois query, you agree to abide
by the following terms of use: You agree that you may use this Data only
for lawful purposes and that under no circumstances will you use this Data
to: (1) allow, enable, or otherwise support the transmission of mass
unsolicited, commercial advertising or solicitations via e-mail, telephone,
or facsimile; or (2) enable high volume, automated, electronic processes
that apply to VeriSign (or its computer systems). The compilation,
repackaging, dissemination or other use of this Data is expressly
prohibited without the prior written consent of VeriSign. You agree not to
use electronic processes that are automated and high-volume to access or
query the Whois database except as reasonably necessary to register
domain names or modify existing registrations. VeriSign reserves the right
to restrict your access to the Whois database in its sole discretion to ensure
operational stability. VeriSign may restrict or terminate your access to the
Whois database for failure to abide by these terms of use. VeriSign
reserves the right to modify these terms at any time.
The Registry database contains ONLY .COM, .NET, .EDU domains and
Registrars.
REGISTRAR OVH
SERVERS
SERVER com.whois-servers.net
ARGS domain =thomaslevesque.com
PORT 43
TYPE domain
RegrInfo
DOMAIN
NAME thomaslevesque.com
CHANGED 2017-04-01
CREATED 2012-04-26
STATUS
clientDeleteProhibited https://icann.org/epp#clientDeleteProhibited
clientTransferProhibited https://icann.org/epp#clientTransferProhibited
NSERVER
DNS101.OVH.NET 213.251.188.145
NS101.OVH.NET 213.251.128.145
REGISTERED yes
Go to top
thomaslevesque.com rapport :
Visitez le site