Windows服務和Windows窗體應用程序之間的通信

Question

我正在做一個項目，它是一種文件上傳器。 在項目中，有一些由應用程序創建並保存在特定文件夾中的日志文件。 這些文件的內容始終是文本。 這些文件的內容被上載到服務器，此任務由Windows服務完成。 該服務一個接一個地讀取文件，然后將其內容傳輸到服務器。

以前，該任務以前是由應用程序本身完成的。 但這是與應用程序分開的，因為當應用程序運行時，用戶可能處於脫機狀態。 因此，這些文件將保持待上傳狀態。

使用服務的優勢顯而易見，用戶不必擔心上傳的東西。 每當用戶連接到Internet時，服務便會處理。

現在的要求是，當服務上載文件的內容並且正在運行通過其創建文件的應用程序時，該服務應向應用程序發送一條消息，指出正在上載哪個文件的內容。

現在的問題是服務和應用程序沒有通信。 我從服務和應用程序中生成了單獨的線程，這些線程都使用命名管道進行通信。

這是我嘗試過的代碼。

服務代碼：

public partial class Service : ServiceBase
{
Thread t;
    public Service()
    {
        InitializeComponent();
    }

    protected override void OnStart(string[] args)
    {
        File.WriteAllText("D:\\log.txt", "Service started.\n");
        ThreadStart ts = new ThreadStart(Connection);
        t = new Thread(ts);
        t.Start();
    }

    void Connection()
    {
        NamedPipeServerStream server = new NamedPipeServerStream("server");
        server.WaitForConnection();
        File.WriteAllText("D:\\log.txt", "Connection established.");
    }

    protected override void OnStop()
    {
        if (t.IsAlive)
        {
            t.Abort();
            File.AppendAllText("D:\\log.txt", "Service stopped.");
        }
    }
}

應用代碼：

public delegate void SendMsg(string s);
public partial class UI : Form
{
    Thread t;

    public UI()
    {
        InitializeComponent();
    }

    private void UI_Load(object sender, EventArgs e)
    {
        lblStatus.Text = "Waiting...";
        ThreadStart ts = new ThreadStart(Connection);
        t = new Thread(ts);
        t.Start();
    }

    void DisplayMsg(string s)
    {
        lblStatus.Text = s;
    }

    void Connection()
    {
        try
        {
            NamedPipeClientStream client = new NamedPipeClientStream("server");
            SendMsg msg = new SendMsg(DisplayMsg);
            msg("Connecting...");
            client.Connect();
            msg("Connected");
        }
        catch (Exception ex)
        {
            File.WriteAllText("D:\\log.txt", ex.Message);
        }
    }
}

這段代碼有什么問題？

如果我使用另一個表單應用程序代替服務，則相同的邏輯也有效。

在進行此搜索時，我了解到Windows Vista以后版本的Windows中的會話0，該會話專門用於Windows服務，並且與登錄用戶使用的其他會話隔離。 我在系統中使用Windows 8。 這可能是個問題嗎？ 請詳細說明。

Answer 1

我承認我不是很多有關命名管道的專家。 我對它們的唯一經驗是通過Windows Communication Foundation （WCF）進行的，盡管這些問題可能是因為我做錯了，但我還是遇到了間歇性的問題。 因此，我無法明智地談論您的命名管道問題。 我確實知道， 漢斯·帕桑特（Hans Passant）一言以蔽之，通常最好留意。

綜上所述，如果您希望通信要求保持簡單，那么使用命名管道（套接字，內存映射文件等）並沒有錯。 當然，如果服務與應用程序之間的通信有望增長，那么考慮使用WCF之類的更正式的東西可能是有意義的。