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.
Related
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?
I have a asp.net web application that has been deployed in the local IIS server of clients. These clients are more than 100 in number as of yet.
Since the application is in early phase of release, it gets updated almost on a daily basis. It becomes cumbersome to deploy new updates to each client's server individually.
Therefore, I would like to implement a mechanism where the user can automatically check for updates, download and replace the IIS application file.
I did try the solution given in this article Building a Self Updating Site Using NuGet but it felt as if it wasn't very reliable and scalable.
So any help on this would be highly appreciated.
Many Thanks.
I have an C# web application using mvc5. It currently runs on Azure and I have a dev, test, and production instances. What do I need to do to ensure that the database connection strings will automatically change as the application is pushed to each environment? I know this is possible with web.config as you can define Web.Debug.Config, etc, but how would I go about this for different worker roles on Azure? I have been all over the internet looking for a solution. In a nutshell, I would like to do the same approach used for the multiple web.config files but for Azure.
As some additional background, for my solution I have my repositorybase broken out into a separate project and there I am trying to grab the connection string from the configuration files (let's say domain.dll is the name of the library that contains it). As first this worked when I was only using web.config but when I had to run my domain DLL files from another worker role the configuration began to return null; because this code would not run when run from a different worker process(non web). This seems to introduce an interesting problem, what if I need to use the domain.dll code outside the web and outside of Azure? How do I still maintain the connection string benefits that Azure and web.config provide?
Assumption: you are using Web-Services, not Web-Sites. There is a difference.
There are 2 ways to get what you need:
For worker role you can do app.config transformations almost in the same way you do in web.config. Only you'll need to do it with SlowCheetah. There is a nuget package for that, also there is VS extension to create transform files. There is too much faffing-about with this method. I never liked it, so move on to second option.
If you run Web-Services, you can specify connection strings as part of worker-role configuration. Go to your Azure project and open properties of your worker-role:
There you can add database connection string. And create a configuration for every environment you run (dev, test, prod). And place a different connection string for every environment.
To get your connection string you execute:
CloudConfigurationManager.GetSetting("DatabaseConnectionString")
Once your site is deployed you'll see these configuration values in Configure tab in Azure Portal.
You should make the distinction between 'building in release mode' and 'deploying to environment X'.
Building in Release mode should just transform your configuration files to be 'production-ready'. With MsDeploy you can parameterize your configuration files so upon deployment they will be filled with the parameters as supplied by you to your MsDeploy script.
There is no magic bullet which will automatically change your connectionstrings etc per environment. But this way you can standardize your process which will greatly help with the stability of your product.
One thing to note is that the parameterization of your deployments will break the easy workflow 'publish' from within visual studio due to the fact that you are not given an option to fill in your parameters during the publish wizard... :'(
You should manage the connection strings through the azure portal rather than through config file transformations. With the MVC app this will be easy, go to the configure tab and set your connection strings there
For items like web jobs use Microsoft.WindowsAzure.ConfigurationManager which
provides a unified API to load configuration settings regardless of
where the application is hosted - whether on-premises or in a Cloud
Service
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.
I'm currently building an Azure Web Role. I am testing this project against a local database server on localhost. Then, when confident that the project is working, I publish it to Staging on Windows Azure.
However, I also have to remember to change the connection string to point to the live SQL server on SQL Azure before deploying, and then change it back to localhost afterwards.
Is there any nice way to automate this, or perhaps a different process to take to avoid the issue altogether? For example is there a way to have a configuration file for Azure that isn't updated with every deploy?
I ended up just referencing the machine name and whether or not I was using Azure, dynamically switching the ConnectionString I referenced accordingly.