I've written a client-server application. There is one computer running the server application, and several computers running the client application.
So far, every time I had a new version / patch of my application, I copied the binaries first through VNC to the server application, and then start a script, that performs a script on client-side, that is copying the binaries to a local folder (network execution is not working!)... Then the client application is started on every client computer...
So what are good opportunities that can replace my old-style method?
I tried creating a click-once application that is updating over http/ftp... but without success ^^
We use an open source app called Presto: http://presto.codeplex.com/
After doing the initial setup, there are only two manual steps with each deployment:
1. Copy the binaries to a network location
2. Press the button in Presto to initiate a new deployment
The big win with Presto is that you use it to initially set up your apps and servers, and specify the appropriate config settings for each environment. Once you initiate a deployment, the installation happens automatically, and the correct values are written to the config files (QA gets QA values, production gets production values, etc...).
With Presto, you can stop services, delete folders, copy new binaries, update config files, etc... and it's all automated.
That's why web front-end is so popular :)
Try to implement good auto-update mechanism and versioning. Client has hard coded server version, with first call all with each call server includes own version. When version mismatch - time to auto update. On server - it's just endpoint to download client application installation, which is standard across versions.
So client has external updater process, that is initiated after client knows that new version exists. Goal of updater process is to download new installation/package and that either to run installation that will update/re-install client either unpack and copy new/modified files.
When not using some external libraries. Process looks like this.
Click-once is another approach and also should work.
Similr question is here
Auto update .NET applications
Anyway probably your client apps need a good installer. When you have installer just left to implement simple downloader/updater and versioning on service.
It is not that hard to do this with less code.
Set up a http service in your application.
Create a File where the current version is listed.
Set up a ftp service in your application to provide the new binaries.
Add a Updater.exe application to the client, this will check for new updates via http and download the new version via ftp. Also a client version file should be made.
So you just have to do your old-style method just one more time and you are done!
Now I don't know if the client application can run the server, if that case is so, I would advice to seperate the services (http, ftp) from your server app.
Related
I write small apps to help automate daily work of some colleagues and want to put on a shared folder on my machine so that others from local network can execute when my computer is on. I don't have the luxury of my own server so this is the best I can do.
One of which is a Winform app that connects to an Oracle database via an Oracle client and Oracle Data Access installed on MY machine to retrieve information. I would hope that people can execute the app (.exe file) when my machine is on, without installing anything on their machine. The app will write to an output file (.html) on the same folder and open it on THEIR browser.
My question is : What should I do to make it possible ? How can people run this .exe file using Oracle Client, Oracle DataAccess and .Net framework already installed on MY machine as if I am running it locally.
I mark all C# Assemblies (automatically added by Visual Studio) as Copy Local to True (Microsoft.CSharp.dll, System.Data.dll, System.dll, System.Data.DataSetExtensions.dll, System.Deployment.dll, System.Drawing.dll, System.Net.Http.dll, System.Windows.Forms.dll, System.Xml.dll, System.Xml.Linq.dll). Would people still need .Net framework installed ? My app is quite simple with only one external dll Oracle.DataAccess.dll. How about Oracle client and Oracle Data Access.
Many thanks.
Best solution for your situation is create a webservice and make the clients that'll consume your webservice instead of them making direct calls to your database. It removes system dependencies and easier maintenance.
Your colleagues can go to your computer via remote desktop if it is feasible. In the probable case that this is not feasible, you need to decide what the colleagues will see. If they only need to see the generated html and they only need to trigger the execution of your exe, then you will need to have a program which listens to a port and make sure that the given port is requested correctly by your colleagues via a small client app.
But honestly, the use-case you describe sounds like a website used by your colleagues. You can create a website in .NET, the exe you have would be the controller or code-behind depending on the approach you use and the HTML would be the response. Then the colleagues will just request your page with the port you are listening at.
There are 2 ways for publish website to Azure - via simple Publish feature vs Deploy as Cloud service. I have also one worker role in solution, so, I selected Cloud Service instead of simple Publish website feature.
But I'm very disappointed with Cloud service. First at all, deploy as cloud service takes in 10 times more time, than simple Publish website. Second problem - I have to each time, when I want to deploy, change connection strings in web.config to SQL Azure (instead of my local SQL Server). Website Publish has ability to set necessary SQL connection strings for deploy. Maybe I do something wrong and deploy can doing in 10 sec and exist ability to set different connection strings (like Website publish)?
I think about put to Cloud only worker role and website deploy as website, without Cloud service...
First, I would highly recommend that you go through this question comparing Azure Websites and Cloud Service: What is the difference between an Azure Web Site and an Azure Web Role
Now coming on to your questions:
First at all, deploy as cloud service takes in 10 times more time,
than simple Publish website.
It is bound to happen because when you deploy a cloud service (say through Visual Studio), following things happen that will cause the delay:
As a part of build process for cloud services, Visual Studio creates a package file and uploads it into blob storage. This package is then used to create a cloud service.
Azure Fabric Controller which is responsible for managing life cycle of a cloud service creates a brand new Virtual Machine for you, installs necessary software (IIS for example) and then deploys your code from the package file.
Both of these things don't happen in websites.
Second problem - I have to each time, when I want to deploy, change
connection strings in web.config to SQL Azure (instead of my local SQL
Server). Website Publish has ability to set necessary SQL connection
strings for deploy. Maybe I do something wrong and deploy can doing in
10 sec and exist ability to set different connection strings (like
Website publish)?
You're not doing anything wrong per se. Your web.config file gets bundled into the package file so after any change you make to your web.config file, you would need to recreate the package and update the deployment (which will include uploading to blob storage).
One possible solution for your problem would be to use config transformation and have your web.config.release file contain the connection string for your production database. When you build your project in release mode, you will have correct connection string in your web.config file.
I think about put to Cloud only worker role and website deploy as
website, without Cloud service...
This is certainly a viable option. Another alternative would be look into WebJobs. Like Worker Roles, they are meant for handling background processing workloads but have the same convenience of a website when it comes to deployment. You may also find this blog post useful as well: http://www.hanselman.com/blog/IntroducingWindowsAzureWebJobs.aspx.
I have a web app and want to transfer data from client's machines to us every day. Assume there is a common API on every client machine to extract data from. To make this work, I have to create:
An API to receive data from clients - using WCF, seems ok at this point
An application that's installed on client machines
The client app needs to store info from the user (eg username/password to access our API - encrypted with DPAPI). The app needs to run daily (probably with a random Sleep() command so our API isn't overloaded all at once). It also needs to be easy to install.
I've created a console app which talks with the client API and our own API. I've used Visual Studio's Settings.settings with a user scope to save the persistent settings - if parameters are provided then it stores these settings, if no parameters it uses the stored settings.
How can I make this usable for the end user? I'm thinking a separate installer/configuration program that installs the exe file (and its dependencies) and asks the user to enter the settings to be stored (which can also be read by the client app). It would have to set up the scheduled task and also offer the ability to change the configuration (the stored shared variables).
Hoping someone can help architect this solution?
Thanks so much!
I think that your idea about an installer is correct since you will most likely have dependencies or prequisites to install.
However, rather than building the settings logic into the installer, I would recommend that you build a UI for this in your application so that the user can adjust it post-installation if needed.
For example, if the user changes their password, in your current design, the user will have to uninstall and reinstall the app. Also, if the scheduled time is incompatible with some other operations on their machine, then they will need to adjust the time without uninstalling and reinstalling.
You could build the UI and API interface into a single application: just change the behavior (runtime or configuration) with a command line switch (for example, only use a /runtime command line switch for the scheduled task).
I published an application,when publishing it i checked that the application should check for updates-now how do i make it realy check for updates-where should i put the new files and in which format?
You'll need it on some kind of Web server.
I would imigine that you also want some authentication so that only the application it self can gain access to the new version of the software.
I'm going to assume you mean you are using CLickOnce as the installer. If you want the app to check for updates every time it is ran you need to publish to a location all the apps can see. If this is an internal app I believe a network share will do. If not then you need to publish to a web server or ftp server.
You can use ClickOnce as nportelli mentioned above, or you can use a 3rd party utility to do the heavy lifting for you.
I wrote an open-source library to do just that transparently - including an external update application to do the actual cold update. See http://www.code972.com/blog/2010/08/nappupdate-application-auto-update-framework-for-dotnet/
The code is at http://github.com/synhershko/NAppUpdate (Licensed under the Apache 2.0 license)
What are some best practices for being able to deploy a Windows service that will have to be updated?
I have a Windows service that I will be deploying but might require some debugging and new versions during the beta process. What is the best way to handle that? Ideally, I'd like to find a ClickOnce-style deployment solution for Windows services but my understanding is that this does not exist. What is the closest I can get to ClickOnce for a Windows service?
A simple solution that I use is to merely stop the service and x-copy the files from my bin folder into the service folder.
A batch file to stop the service then copy the files should be easy to throw together.
Net stop myService
xcopy \\myServerWithFiles\*.* c:\WhereverTheServiceFilesAre
net start myService
I have a system we use at work here that seems to function pretty well with services. Our deployed system has around 20-30 services at any given time. At work we use a product called TopShelf you can find it here http://topshelf-project.com/
Basically TopShelf handles a lot of the service related stuff. Installing, Uninstalling etc all from the cmd line of the service. One of the very useful features is the ability to run as console for debugging. You build one service, and with a different cmd line start you can run it as a console to see the output of the service. We added one custom feature to this software that lets us configure profiles in advance. Basically our profiles configure a few things like logging, resource locations etc so that we can control all that without having to republish any code. All we do is run a command like
D:\Services\ServiceName.exe Core.Profiles.Debug or
D:\Services\ServiceName.exe Core.Profiles.Production
to get different logging configurations.
Our build script creates install.cmd and uninstall.cmd scripts for each of our services all we do is copy the files to the server and run the script. If we want to see debug output we stop the service and double click the exe and we get a console to read all the output.
One more thing that topshelf has which we don't use because its not necessary is the concept of shelving (there is documentation on this website for this). This allows you to update the service without having to "restart" but you still need to copy the files manually unless you build an automated system for that.
However, my suggestion if you need 100% service availability is to have a redundant system. No matter how you configure your service for updates you cannot avoid hardware failure causing downtime without an automated failover system. If said system was in place my recommended update strategy would be to turn off 1 node, update, test, turn on turn off the other node, update, test and turn the 2nd node back on. You can do this all of course with a simple script. This may be a more complicated system than you need but if you can't take a service offline for a simple restart that takes 5 seconds then you really need some system in place to deal with hardware issues because I can guarantee it will happen eventually.
Since a service is long-running anyway, using ClickOnce style deployment might not be viable - because ClickOnce only updates when you launch the app. A service will typically only be launched when the machine is rebooted.
If you need automatic update of a service then your best bet might be to hand-code something into the service, but I'd forsee problems with almost any solution: most install processes will require some level of user interaction (if only to get around UAC), so I can't imagine this would lead an answer that doesn't involve getting a logged-on user in front of the screen at some point.
One idea that might just work is active-directory deployment (or some similar equivalent). If your service is deployed via a standard MSI-type installer, AD allows you to update the application silently as part of the computer policy. I suspect you'd have to force the server to refresh the AD policy (by rebooting or using gpupdate from the console), but other than that it should be a hands-off deployment.
I would suggest using the "plugin" approach on this, that is, using the Proxy Design Pattern.
While using this pattern, an independant thread may verify over a folder for updates. You will need to use ShadowCopy over your assembly deployment. When your service update-thread encounters a new version of your service, it shall unload the current production assembly and load the new version, without stopping the service itself. Even more! Your service should never notice the difference, if there is no breaking code within your assembly.
I would suggest to create a normal setup project, and add the windows service project output in that setup project.
For more information please refer to http://support.microsoft.com/kb/816169.