I have a WCF Windows service that is used locally only. I need to deploy it in multiple sites and I need the option to auto update it - when an update is released, the service has to be able to get the new version and update itself.
The service will be used in Windows 7, so the permission issue needs to be taken into account somehow.
I have no experience with services and their deployment, feel free to explain thoroughly.
Edit
I've been considering ClickOnce since another application I'm writing is deployed using it. The thing is, ClickOnce only checks for updates on startup and Windows services are supposed to be up and running.
Is it possible to use the ClickOnce detection in my other app and then update the service? (Permission-wise)
Can ClickOnce start and stop the service?
Can the update be silent?
You have to take in account the expected availability of your service and the update policy for your application.
Besides that, you might want to take a look to:
Is there a way to check if a ClickOnce application is running the latest version
http://madprops.org/blog/Updating-ClickOnce-Application-Programatically/
http://msdn.microsoft.com/en-us/library/xc3tc5xx.aspx
Cheers,
Related
I realize that we cannot directly access SQL Server database from a UWP app, and have to use a WCF service as a mediator for this. (Which is totally stupid, since even competitors like MySQL provides API for Microsoft's runtime, while Microsoft's own RDBMS does not!)
I don't have any experience with WCF, but after going through some tutorials, I believe I can make a WCF service to communicate with my SQL Server (although I do not like making my simple application use a 3-tier architecture, which shouldn't be imposed on me). Anyways, I do not want to host this WCF service on my website, since I'm making this only for this UWP app. Is there a way I can bundle/pack this WCF service along with UWP app itself, such that service runs on client machine only when thhe start my app, and stops later when app is closed/suspended/minized.
The UWP app I'm developing, also have a WPF version and a web version (in ASP.NET), all of which were connected to MySQL database till now, and it worked flawless. Recently I decided to shift to SQL Server since I'm using Microsoft technologies for all my softwares and thought SQL Server will have better integration and support. But now I find it rather opposite, and thinking to switch back to MySQL database.
You can not bundle a WCF service (or REST api) with your Universal Windows app. UWP apps run in a sandbox environment on a different .NET runtime than your WCF service. You could run the WCF service in IIS, or even better create a self-hosted ASP.NET WebAPI project (so no need for IIS) to access your database. But this service will have to be installed separately from the app.
Note that because UWP apps run in a sandbox, some in-app databases like SQLite are inside this sandbox and can not be accessed by your other apps (WPF, website) by default (there are some hacks to bypass this).
So I think your best bet is to stick with MySQL and use the MySQL connector.
I am building a client-server application, this is all running locally on my computer whilst I am developing the system. However, eventually I would like to deploy the server-side part of the application to a server to run 24/7, enabling client applications to connect and consume the service at will. What I would like to know is, when I come to doing this would I simply just install the server-side application on the server, hit run and that's it? That just seems... well not right (to me), is this the way it is done? or is there a lot more to it? I imagine there is, but I can't seem to find any content on this subject.
FYI - the server is a self hosted WCF application.
You'd want to take your program's executable, support dlls and config files and drop them into a folder. Then create a Windows Service to run the program; if you don't use a Windows Service, the program will only run while you're logged on, which isn't good. As a Windows Service, a reboot of the server will bring the program back online even if you're not logged on.
Here's a knowledge base article from MS on how to make a windows service.
http://support.microsoft.com/kb/251192
If you're program is compiled as a DLL, then create a small .exe program to run it (a wrapper) then deploy the program as described in the article.
Good luck.
I have the following scenario:
We develop a silverlight 4 app for our customers, that will be used as an out-of-browser app. The app is working offline, i.e. app and database are on the users local machine. The app is using WCF-RIA-services to connect to the local database. The database will be an SQL Server Express, SQL Server CE or MySQL. We are using MVVMLight and MEF.
An external webserver is only used for updating the app from time to time or adding new modules to the app. To achieve this we do something similar as shown in Jeremy Likness blog (http://www.wintellect.com/CS/blogs/jlikness/archive/2010/05/25/silverlight-out-of-browser-dynamic-modules-in-offline-mode.aspx )
The reasons why we are doing such a scenario are complex. But to keep a long story short it is mainly for compatibility reasons for a later online version and we don't want to use WPF. So we need to get this working with Silverlight and WCF-RIA services.
Ok, that's the scenario and here's the question:
Do we need a local webserver in this scenario? The app is programmatically installed as out-of-browser, the database is local and connected via WCF-RIA.
If yes, which webserver would be sufficient? It should be installed and configured via an initial setup that is executed by the customer. The customer should not have to do anything with configuring the webserver.
Any other ideas or comments on this scenario? Any other possible solutions for this?
Thanks for your help
Dirk
silverlight wasn't meant to be used this way I think. So it would be like when you are developing app in visual studio and use Cassini to see result - everything runs locally - but you still need a web server. Maybe more info here - http://www.infoq.com/news/2010/06/WPF-vs-Silverlight
I´m not able to provide with a full answer to your problem, as we are currently facing the same problem. (WPF not being cross-platform, Very specific hardware on some clients)
But I may share some of our thoughts on our type of Thick-Silverlight-Client:
To keep deployment etc. simple we use a self-hosting process (installed as background process)
We may not use RIA as the background process has to run using Mono VM (but for MS-only solution see Can WCF RIA Services be self hosted? )
Architectural thoughts on standalone "Clients":
Depending on your requirements implementing a server for each client communicating with the "main"-server by messages (NServiceBus) may be overkill. But if you want to use a client database if offline and silverlight for ui you should consider using an event-driven-architecture.
There is a slideshow on combining "Event-Driven-Architecture" & "CQRS" with Silverlight. But i would not use it as a blueprint more like an inspiration.
http://www.slideshare.net/dennisdoomen/cqrs-and-event-sourcing-an-alternative-architecture-for-ddd
I have several different c# worker applications that run various continuous tasks: sending emails from queue, importing new orders from website database to orders database, making database backups and restores, running data processing for OLTP -> OLAP, and other related tasks. Before, I released these as windows services, but currently I release them as regular console applications. They are all based on a common task runner framework I created, and I am happy with that, however I am not sure what is the best way to deploy these types of applications. I like the console version because it is quick and easy, and it is possible to quickly see program activity and output. The downside is that the worker computer has several console screens running and it gets messy. On the other hand the service method seems to take to long to deploy and I have to go through event logs to see messages. What are some experiences/comments on this?
I like the console app approach. I typically have things set up so I can pass a switch like -unattended that suppresses the console screen.
Windows Service would be a good choice, it runs in the background no matter if you close current session, also you can configure it to start automatically after windows restart when performing a patches update on the server. You can log important messages to event viewer or database table.
For a thing like this, the standard way of doing it is with Windows services. You want the service to run on the network account so it won't require a logged in user.
I worked on something a few years ago that had similar issues. Logically I needed a service, but sometimes I needed to see what was going on and generally I wanted a history. So I developed a service which did the work, any time it wanted to log, it called to it's subscribers (implemented as an observer pattern).
The service registered it's own data logger (writing to a database) and at run time, the user could run a GUI which connected to the service using remoting to become a live listener!
I'm going to vote for Windows Services. It's going to get to be a real pain managing those console applications.
Windows Service deployment is easy: after the initial install, you just turn them off and do an XCOPY. No need to run any complicated installers. It's only semi-complicated the first time, and even then it's just
installutil MyApp.exe
Configre the services to run under a domain account for the best security and easiest interop with other machines.
Use a combination of event logs (with Error, Warning, and Information) for important notifications, and just dump verbose logging to a text file.
Why not get the best of all worlds and use something like:
http://topshelf-project.com/
It will allow you to run your program as command line or a windows service.
I'm not sure if this applies to your applications or not, but when I have some console applications that are not dependent on user input or they are the kind of applications that just do their job and quit, I run such programs on a virtual server, this way I don't see a screen popping up when I'm working, and virtual servers are easy to create and restart.
We regularly use windows services as the background processes. I don't like command-line apps as you need to be logged into the server for them to run. Services run in the background all the time (assuming they're auto-start). They're also trivial to install w/the sc.exe command-line tool that's in windows. I like it better than the bloat-ware that is installutil.exe. Of course installutil does more, but I don't need what it does. I just want to register my service.
We've also created a infrastructure where we have a generic service .exe that loads .DLLs based on an interface definition, so adding a new "service" is as simple as dropping in a new DLL and restarting the service host.
However, we started to move away from services. The problem we have with them is that they lock up the DLLs (for obvious reasons) so it's a pain to upgrade them. We need to stop, upgrade and then restart. Not hard, but additional steps. Instead we're moving to special "pages" in our asp.net apps that run the actual background jobs we need done. There's still a service, but all it does it invoke the asp.net pages so it doesn't lock up any of our DLLs. Then we can replace the DLLs in the asp.net bin directory and normal asp.net rules for app-domain restart kick in.
I've created a service for one of my apps. How do i create a system tray component in VB.net that can be used to monitor the progress of the service? Is there a way to have this installed via tcpip on multiple client machines such as those that are for our employees?
We do exactly that here, with the server running a really basic HTTP server on a configurable port on a separate thread that returns status in an XML format (nothing else, just that) -- the client just uses a web request to get the XML, before parsing it and displaying it appropriately.
This approach also allows for future extensibility (detailed status, sending service control commands, adding an association to an XSLT file elsewhere for use with a normal web browser, etc.)
You could use WCF for this. Using WCF your service would open up an EndPoint which would expose status information to callers. You could then build a tray icon application that can be deployed to the employees workstations. The tray icon application could periodically poll the WCF service the your Windows Service is hosting and get status information. I know #Johan mentioned Remoting already and this is a similar approach. I'd recommend WCF though as the programming API is more simple, IMHO, and WCF will give you more flexibility with regards to network transports, etc.
I guess your question is not about how to actually do the "traybar"-thing, but how to communicate with the service to get the information you want to show in the monitor/traybar-program?
It can be done in many ways, API is one way, use sendmessage/postmessage/getmessage is one way to make 2 running programs communicate with each other without having to store anything in files or databases first.
DDE is another way. If it needs to do the stuff via net then there is something called NetDDE, but I havent done anything with NetDDE I cant help anything there.
But about the API and DDE, feel free to ask more questions if you want some clarification.
I'll take the second question: Is there a way to remotely install software on client machines?
Yes. However it is very dependent on your environment. For example, if you have an Active Directory domain, you can use group policy to force installation of software on the client boxes.
If you don't like that or if you aren't on active directory, you can buy something like Altiris to push installs down.
Another option would be to use login scripts which would run a custom program to detect if your program is installed and take appropriate action. But then you are probably better off buying Altiris.
For the comunication part, i have used remoting before, and this works very well. With a little bit of configuration, you can even get it working to another machine.