Witajcie,
Chce napisać usługę która będzie monitorowała dany katalog w poszukiwaniu nowo utworzonego pliku, następnie nowo utworzony plik ma być wypychany na drukarkę (tutaj póki co jest wszystko dla mnie jasne). Dodatkowo chcę stworzyć aplikacje GUI korzystając z WPF, w której będzie można zdefiniować folder który ma być monitorowany. I tutaj nie wiem jak to zrobić, jak skomunikować serwis z aplikacją GUI?
Jest kilka sposobów.
Najprościej, ale nie koniecznie najlepiej - jeśli aplikacja działa na tym samym komputerze to można wykorzystać jakiś plik konfiguracyjny który serwis monitoruje, a który jest modyfikowany przez aplikacje z GUI. Rozwiązanie raczej słabe, mało przenośne i podatne na błędy (ktoś może plik usunąć).
Kolejny sposób to bezpośrednie wykorzystanie mechanizmów komunikacji między procesami w Windowsie (np. potoki nazwane). Trochę upierdliwe i też mało przenośne.
Najlepiej wg. mnie użyć do tego WCF. Wtedy usługa windowsowa wystawia endpoint do którego łączy się klient. Jeśli aplikacje i serwis są na jednej maszynie , to warto użyć połączenia namedpipe (wtedy mamy od razu zapewnione bezpieczeństwo plus szybkość). Konfiguracja wtedy sprowadza się do dodania wpisu w pliku app.config, wszystkie niskopoziomowe operacje zapewnia już wcf. Rozwiązanie jest dosyć przenośne, jeśli chciałbyś kiedyś mieć GUI w innej sieci po prostu zmieniasz endpoint w plikach .config klienta i serwisu.
Jeśli masz dostęp do kursów pluralsight to polecam to: http://www.pluralsight.com/courses/wcf-end-to-end .
Jeśli nie to kurs na msdn https://msdn.microsoft.com/en-us/library/ms734712%28v=vs.110%29.aspx?f=255&MSPPError=-2147217396
Nie chce modyfikować pliku przez notatnik, nie chce iść najprostszą drogą. Serwis ma monitorować katalog i najnowsze pliki drukować, ma to działać cały czas w tle. Pojedyncza aplikacja może zastąpić ten serwis?
@mały Orzeł, WCF wykorzystać do stworzenia klienta, który będzie się łączył z usługą, czy po prostu wszystko zrobić z wykorzystaniem WCF?
Lukassz napisał(a):
Plik konfiguracyjny raczej odpada, zbyt podatne na błędy.
Aplikacja i serwis będzie działała na jednej maszynie, możesz podać trochę więcej informacji na temat WCF, jak zacząć?
Im więcej elementów, tym większa podatność na błędy. Stawianie WCF po to, aby skomunikować program z usługą systemową na jednej maszynie jest całkowicie pozbawione sensu.
Lukassz napisał(a):
Nie chce modyfikować pliku przez notatnik, nie chce iść najprostszą drogą. Serwis ma monitorować katalog i najnowsze pliki drukować, ma to działać cały czas w tle. Pojedyncza aplikacja może zastąpić ten serwis?
Może, tylko aplikację łatwiej przypadkowo zamknąć albo wywalić w inny sposób.
somekind napisał(a):
Może, tylko aplikację łatwiej przypadkowo zamknąć albo wywalić w inny sposób.
Sugerujesz coś jeszcze innego?
Mam pytanie jeszcze odnośnie drukowania plików, pliki które będę chciał drukować będą formatu .html, .rtf. Muszę je konwertować do pdf? Jaką klasę polecacie? Czy programowo mogę ustawić sobie np. wydruk lustrzany?
Mam taką aplikację/proces w Wpfie, która działa w tle. Gdy plik „C:\Logs\LogCtrl.txt”
z logiem zostaje mieniony, aplikacja otwiera go (rejestruję w nim bugi). Wygląda to tak:
C# 
private BackgroundWorker _bgw = new BackgroundWorker();
private DateTime _dt;
public MainWindow()
{
InitializeComponent();
_dt = GetLastWrite();
_bgw.WorkerSupportsCancellation = true;
_bgw.DoWork += BgwDoWork;
_bgw.RunWorkerAsync();
Hide();
}
private void BgwDoWork(object sender, DoWorkEventArgs e)
{
while (true)
{
var dt = GetLastWrite();
if (dt != _dt)
{
System.Diagnostics.Process.Start(_pathFile);
PlaySound();
Thread.Sleep(1000);
_dt = GetLastWrite();
}
Thread.Sleep(1000);
}
}
private void PlaySound()
{
System.Media.SoundPlayer player = new System.Media.SoundPlayer(@"C:\Windows\Media\notify.wav");
player.Play();
}
private DateTime GetLastWrite()
{
return new FileInfo(_pathFile).LastWriteTime;
}
Musiałbyś dostosować ten kod do swoich potrzeb (nie konkretny plik a katalog, nie ostatnia zmiana a nowy plik, nie otworzenie a drukowanie i ścieżka katalogu, która jest na bieżąco aktualizowana)
Plik exe można wrzucić do katalogu 'startup' – może być automatycznie uruchamiany.
To nie jest rozwiązanie tylko sugestia.
Powodzenia!
Skoro nie plik konfiguracyjny, to trzymaj info o folderze w rejestrze. Tam nikt nie wlezie i nic nie zmieni.
Zresztą, do appata też nikt raczej nie wlezie, a jak ktos wlezie i coś usunie to sory, może wleźć i do program files albo do katalogu Windows i sobie coś pousuwać, jego problem.
Też uwazam stawianie webserwisu do takich zastosowań za bezsens, jeśli wiesz że to zawsze będzie działać na jednej maszynie.
Usługa lepsza niż pojedyncza aplikacja, bo można łatwo ustawić tryb uruchamiania, automatyczną reakcję na błędy itd.
Oczywiście jeśli plik to w appdata i nie jakiś wzięty z dojpy a serializowany obiekt do pliku xml.
somekind napisał(a):
@lknew, tylko czemu samemu implementować jakieś pętle, zamiast użyć
FileSystemWatcher?
FileSystemWatcher jest dobrym rozwiązaniem.
Ta pętla obsługuje specjalne traktowanie zmiany pliku– np. jeśli w ciągu 1s pojawi się 10 logów to plik zostanie otwarty tylko raz. To jest coś ekstra i takich rzeczy może się pojawić więcej. Dostosowanie FileSystemWatcher może po jakimś czasie okazać się trudne. Poza tym FileSystemWatcher sam w sobie nie jest doskonały: http://stackoverflow.com/questions/1764809/filesystemwatcher-changed-event-is-raised-twice
lknew napisał(a):
Ta pętla obsługuje specjalne traktowanie zmiany pliku– np. jeśli w ciągu 1s pojawi się 10 logów to plik zostanie otwarty tylko raz. To jest coś ekstra i takich rzeczy może się pojawić więcej. Dostosowanie FileSystemWatcher może po jakimś czasie okazać się trudne. Poza tym FileSystemWatcher sam w sobie nie jest doskonały: http://stackoverflow.com/questions/1764809/filesystemwatcher-changed-event-is-raised-twice
Nie no, jasne, ale tutaj chyba chodzi o przechwycenie tworzenia pliku, a nie modyfikacji. No i wydaje mi się, że robienie tego jakimś magicznym mechanizmem Windowsowym zawsze będzie wydajniejsze niż własna implementacja. :)
private void SendToPrinter()
{
ProcessStartInfo info = new ProcessStartInfo();
info.Verb = "print";
info.FileName = @"c:\output.pdf";
info.CreateNoWindow = true;
info.WindowStyle = ProcessWindowStyle.Hidden;
Process p = new Process();
p.StartInfo = info;
p.Start();
p.WaitForInputIdle();
System.Threading.Thread.Sleep(3000);
if (false == p.CloseMainWindow())
p.Kill();
}
Zadziała jeśli w systemie jest coś, co potrafi otworzyć i wydrukować pdf.
