c # - Sådan udvikler du en server i Windows

Indlæg af Hanne Mølgaard Plasc

Problem



Jeg stiller dette spørgsmål som en fyr med en stærk Linux-programmerings baggrund. Jeg har meget lidt erfaring med Windows-udvikling, og det har hidtil været begrænset til 'Console Application' -type programmer.


Hvad er den kanoniske proces med at udvikle en server, vel vidende at den skal køre på Windows?


Opretter man en Windows Service applikation med det samme? Er debugging processen virkelig så ubehagelig som det ser ud til? Startes en Windows-udvikler med et Kommandolinjeprogram for debugging, og konverterer det kun til en tjeneste til implementering? [2]


Til sammenligning vil jeg tilbyde, at en Linux-server er et almindeligt kommandolinjeprogram på det valgte sprog. Jeg vil definere en server som et program, der stereotypisk,



  1. producerer det meste af dets menneskeligt læsbare output i form af logfiler,

  2. accepterer input fra operativsystemet (fx netværks- eller filsystemhændelser) i modsætning til 'bruger klikket på en knap' eller 'bruger indtastet en kommando' og

  3. implementeres som en dæmon.



Det kan være, at Windows sysadmins forventer helt forskellige grænseflader til at starte, stoppe og administrere servere. Jeg er helt åben for det, jeg har lige tilfældet ikke set den hele siden af ​​tingene endnu.


$ ./my-server &
Starting...
$ head /var/my-server.log
2012-3-10 14:34:43.934 [info] Server started! Waiting for connection from client
$ 

Bedste reference


For det første: Ja, det er næsten altid at foretrække, at en server på Windows implementeres som en systemtjeneste. Det er dog en ekstra bonus, hvis serveren også kan køres fra kommandolinjen til fejlfinding.


Det er normalt ikke for svært at strukturere din kode, så den servicespecifikke logik abstraheres til funktioner, der kan tjekke, om du kører som en tjeneste eller på kommandolinjen og opfører sig i overensstemmelse hermed. Jeg foretrækker at have et enkelt kildemodul, der kun indeholder hovedfunktionen () og de service-specifikke ting. For at opnå de bedste resultater skal du sikre dig, at kun dette modul ved, hvilken tilstand du kører i. (Bemærk også, at dette modul ofte kan arves fra et projekt til det næste med kun beskedne ændringer.)


Den anden fordel ved at gøre dette er, at det betyder, at du kan gøre det meste af din fejlfinding i kommandolinjemodus uden at have flere byggemuligheder. Du skal stadig teste (og sandsynligvis debug) service logikken selv, men det er et meget mindre job.


Der er nogle yderligere oplysninger her, du har sikkert allerede set. [3]

Andre referencer 1


I Windows er en tjeneste noget der



  1. producerer det meste af dets menneskelige læsbare output i form af hændelser, der sendes til hændelsesloggen;

  2. accepterer input fra operativsystemet via uanset arrangementer, som det kan lide at svare, men skal altid svare på anmodninger fra Service Control Manager (SCM) (som 'start service' 'stop service', 'pause service', ... ).


    Præcis hvordan disse begivenheder leveres, afhænger af faciliteterne i det valgte programmeringssprog, du bruger i C (dvs. på OS niveau) skal du oprette en hændelsesløkke og undersøge de modtagne hændelser. Normalt udfører du det egentlige arbejde i adskilte tråde, med hovedtråden på arrangementsløkken.

  3. Udvikles som en tjeneste, som typisk er en konsolkørsel, der registrerer sig til SCM.



For mere info om tjenester i .NET se her; for de nitty-gritty detaljer om hvordan det hele fungerer på C niveau (dvs. uden nogen fancy sprog faciliteter) se her. [4] [5]