I have a C# program (I'll call it ProgramA) running on an azure VM running windows server, and it references my MVC site. Currently when I make changes to my MVC sites database structure the program on the VM runs into errors as the database structure has changed.
In order to resolve these errors I simply need to stop the service, update the dll, and restart the service. Currently I do this manually, which is awful as it causes downtime. I am looking to automate this deployment.
UPDATED - DEPLOYING CONSOLE APPLICATION IN CLOUD WITH DEPLOYMENT FROM VS2013
I was thinking of achieving this by creating a small app to run on the VM to check for updates and perform them, but I am now aware there are easier ways to achieve my goal by deploying my application from VS to run as a service in the cloud.
My app is a console app. I simply want it running in the cloud in a way that makes it easier to deploy. I have found https://azure.microsoft.com/en-us/documentation/articles/websites-dotnet-deploy-webjobs/#convert, but following the steps leads me to deploying a website and I'm not sure that's what I want. This isn't a website it is simply a console application.
What is the best way of achieving this?
Related
I am trying to run a background service which just writes to a file on a specified interval.
There are two methods that I tried
1) Created the project with the Console application template
2) Created the project with Web Application as template
When I run the app from visual Studio, both of them run fine. But when I deploy them to IIS, only the web application version works. It must be noted that there is absolutely no difference between the code of the two projects. I have used the WebHost as a hosting strategy in both the projects as well as well as installed all the dependencies in case of Console application as there are in the Web Application version.
I must also inform that I have used the preloadEnabled="true" option in IIS as IIS needs a web request to start the application.
I am wondering what is the difference between both the project types as the code is the same? I don't want the Web Application template.
Edit 1: I forgot to mention that the service will also need to expose an api endpoint for healthcheck purposes. Will the windows service approach listen for http requests?
I used the following article for implementing my background service.
https://learn.microsoft.com/en-us/dotnet/architecture/microservices/multi-container-microservice-net-applications/background-tasks-with-ihostedservice
After years of building background services, I learned that Windows services are the best tools to implement these applications. While there are different techniques to keep an IIS application up and running in the background and prevent it from getting recycled, in practice, the applications on IIS are not meant to be executed forever.
If you had an intention to build your app in the cloud, I would have suggested using something like Azure WebJobs or Azure Functions Timer-Triggered functions, but for on-premise, even using something like Hangfire in the web is not sustainable. The worst happens when you need backward compatibility on Windows servers that don't have the "Application Initialization" module.
My suggestion is to move your application to a simple Windows Service if you control your environment. Windows services consume less memory, are easier to manage, and can run forever without getting recycled.
WebApplications are plain the wrong tools for this.
Being always on and always reachable, WebServers are primary targets for hacking. To compensate for that, they are usually run under the most restrictive user rights you can imagine: Read rights to their programm and this instances content directory. While I do not know why it worked at all, it propably will stop working in Production.
What you wanted to write was eitehr a Service or something executed by the Windows Task Sheduler. Personally I advise for the Task Sheduler as Services have their own set of restrictions. Unless of coruse there is some detail of the requirements that you did not told us.
This article could be helpful. It's a step by step tutorial on how to convert a console application to a web application.
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.
In advance, sorry for stupid question, but all search results in google are off-topic for me.
I want to create a C# application, that will run continuously on an Azure VM. It should NOT be event driven, as it will use different factors (db monitoring, time schedule, overall usage) to decide its activity.
Now, should I just create a console app in VS Express 2013 for Desktop and run it using RDP on VM? Or is there some azure-specific project that I can use (maybe for better integration with management portal)? All I can see and find is web-related (a website, a webjob, a background worker, a webapi), and mine app will not in any way be accessed remotely (it will periodically check db shared with a ASP.NET website)
It is possible. You should create the equivalent of a Windows Service, but then for Azure.
There is a useful question for that already on SO: Windows Service to Azure?
It has a reference to a full walk though: Migrating a Windows service to Windows Azure.
The corresponding azure type is "Cloud Services / Worker role". They work just as windows services.
So you can basically take all classes from your windows service (except Service1.cs) and put them in the new azure project.
The copy all start/stop code from your Service1.cs to the corresponding class in your new Cloud service project.
http://www.windowsazure.com/en-us/documentation/articles/cloud-services-dotnet-multi-tier-app-storage-4-worker-role-a/
I want to publish my LightSwitch application as both a 3-tier desktop app and a web app. Is there any way to do this in a synchronized manner? And are there any commands that would allow me to do checks before trying e.g. OOB actions in a web app? Basically, I can't find anything on the web about deployment in both Desktop(OOB) and web. I want to know if there is any knowledge on this.
You should be able to detect if your lightswitch app is in-browser or out-of-browser, using the AutomationFactory.IsAvailable property, which should return false for in-browser, and true for out-of-browser.
With regard to publishing to both Desktop and Web, I think you can just run the publish wizard for Desktop so that it produces the necessary files in the ../Publish directory, save them somewhere, then re-run the publish wizard for the Web. As long as you are publishing the data to the same location (provided you want shared data between both applications), then this should work (however I haven't tried it so no guarantees).
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.