Due to some (insane) limitation at my customer, I built up a WCF layer using Azure, just as a proof of concept. Now, what is a smooth way to re-deploy it to their on-premises server? Is there such a way?
I understand that the publishing of my service to the cloud is a nice luxury that can't be performed as easily when deploying on-premises. :(
Because of some (equivalently insane) limitations, I'm not able to connect my computer (with the IDE and source code) to the internal net of the customer. I might be able to get an IDE installed on their computer, though. Is moving the source code files and recompiling the only option?
In a perfect world, I'd like to copy the entire project to the customer's computer and just change some settings in a deployment file (or whatever thing stores that information). Is it possible?
Well, what about the deploying the solution to the local temp folder by using the Deploy Wizard from Visual Studio and then simply create by hands a new application on server side and copy all files there.
Related
I have an MVC4 web application that uses jquery and some other libs (jquery-ui in particular).
Yesterday I decided to update all the packages via NuGet package manager; my web application worked correctly on my local machine, but when I deployed it to my azure website a javascript error popped out in my browser (it was related to jquery-ui library, something like "$browser is not a function").
I searched the web and found out that the cause of this error was that I was still using an old version of jquery. It seems that deploy process didn't publish the new version of the js libraries even if they have been updated in local project.
I solved the problem connecting via RDP to the Azure machine, deleting the contents of "Scripts" folder and deploying again, but I'm wondering if there's a way to "force" script/libraries update when deploying to Azure.
Edit 1: I'm developing with Visual Studio 2012, using Mercurial as source control provider
Edit 2: I'm deploying to Azure Web Sites
Please, in your future questions clearly indicate what type of Azure Service do you use. An MVC4 web application can be deployed to 3 different type of services: Azure Web Sites, Azure Cloud Service, Azure Virtual Machine!
Since you are talking about RDP, the viable options are Cloud Service or Virtual Machine. But then you say
I solved the problem connecting via RDP to the Azure machine, deleting
the contents of "Scripts" folder and deploying again, but I'm
wondering if there's a way to "force" script/libraries update when
deploying to Azure.
Now the question is how you do deploy to Windows Azure? Is it via Visual Studio's Publish feature to Azure Cloud Service. Is it Visual Studio's Package feature and then using any other method of deployment (upload the package from the portal, use Azure PowerShell cmdlets, or use third party tool to deploy the package)? Is it integration with Mercurial and deployment is done automatically when you check-in?
Any any case, the issue you face is a mixture of NuGET failing to do real clean update of everything. Browser caching - especially for local development - IE caches all the scripts, CSS and images and it is hard to say (without explicitly deleting all locally cached files) which script are you actually using. Simple version control issue - keeping old and new scripts.
When you do a JS/CSS updates I strongly advise all the customers to first delete all browser's cache (crtl+shift+del - works for all browsers) before testing locally.
I highly doubt that if you use a Cloud Service, RDP-ing and deleting anything in the sitesroot folder will help you when you redeploy. What you do in the ROLEROOT drive (usually E:, sometimes F: drive) is dropped of/forgotten when you re-deploy regardless of the re-deploy method you use: in-place-upgrade or full re-deploy. So what you did is actually creating new package and re-deploying your new package.
The fact that you deleted some folder has no effect on your re-deploy action.
I am developing a C#, MVC4, EF5 Code First application on .NET in Visual Studio 2012 and have used the VS publish mechanism to deploy it to an Azure Website with an Azure SQL Database.
I now want to use Git and GitHub for version control and involve others in the project.
However, although I am familiar with using Git in a LAMP environment, I have no experience of using Git with Windows, Azure Websites and a compiled environment.
I would like to use the Azure Website as the production server, another Azure Website as a Staging server, developer Windows machines using Visual Studio for development and GitHub as the central repository.
There is a helpful article here: http://www.windowsazure.com/en-us/develop/net/common-tasks/publishing-with-git/ . I can get my head around what would be needed here for, say, a PHP application on Azure. But I am unsure of the best approach with a compiled application and what I can achieve using Azure Websites and Visual Studio.
A nudge or two in the right direction would be greatly appreciated!
don't publish from VS to azure, instead setup your azure website to pull from the github repo. the deployment process compiles your solution.
watch http://www.youtube.com/watch?v=5NGieL0tinw&feature=youtu.be&hd=1 or read http://vishaljoshi.blogspot.com/2012/09/continuous-deployment-from-github-to.html
Also SocttGu announced this on his blog # http://weblogs.asp.net/scottgu/archive/2012/09/17/announcing-great-improvements-to-windows-azure-web-sites.aspx he also talks about a cool feature of publishing branches, this will nail your requirement for a stage server and production server. Have a stage branch and a production branch and merge to them as desired. see the section "Support for multiple branches"
looks like they added support for private repos finally.
appharbor is a competitor to azure that does something similar.
You are basically introducing a new step with the requirement that the source code must be compiled before it can be deployed to the server. Where you implement this step is up to you. You could:
Ensure that your target server has the capabilities to compile the source code (some Continuous Integration tools could help with this, such as CruiseControl.NET). This has the caveat that the target server be able to compile source code (possibly even requiring Visual Studio to be installed), so that may not be an option.
Check the compiled binaries into source control. You could keep these compiled binaries separate from the main source branch, to keep things clean. Deploy the binaries to the target server.
Some hybrid of the previous two options is also possible; you could set up a Continuous Integration server with CruiseControl.NET, which can check out the current source, build it, and check the resulting binary back into a special branch, then deploy that branch to your target Server.
Say I have a c# web application project in a TFS Team Solution that I am deploying to a development server (IIS7). I want to be able to promote only certain code changes to a test server, and then later promote ONLY those changes to the production server.
So for example changes to a web user control and a javascript file should be promoted, but a change to a web form should not be promoted.
Using the deployment feature in Visual Studio seems to be an all-or-nothing proposition.
Short of manually selecting files to copy/paste, or write some kind of app that compares files in a target and source directory, list files that are different, and lets you select source files to promote, what do teams usually do in this situation?
In short: how can I reliably promote select files/code from environment to environment without also including other changes that should not be promoted?
Create two branches in TFS, one for development and one for production.
Merge dev->production only changes that you need.
Create deployment packages from production branch.
I want to create an application that will automate a very specific build process that is repeated daily.
I need to build a C# web app, package the dlls and other necessary files (diff from last checkin in svn) into a .zip file in a certain structure.
Connect to a secure remote Windows web server (with specific authentication), copy, unzip and deploy the files to the correct locations.
I was thinking a C# console app which will handle the connection to the remote server, and a combination of file operations in the code, or batch files run on the local machine and the remote server. I intend to use batch script to build the Visual Studio project, and run a diff on the svn tree and export changed files to a certain directory structure.
Is this at all possible? How would I achieve the remote connection and copy the files?
Just wanting to see your thoughts.
Thanks for any help.
What you're trying to create is effectively build automation for which there are some excellent continuous integration products available. My advice would be to jump on the free, Professional version of TeamCity and use this to orchestrate your builds. It plays great with SVN and has built-in Visual Studio and MSBuild runners.
While you're there, unless you're trying to do something very bespoke, take a look at using Web Deploy to push the app out. There's a five part blog series titled You're deploying it wrong! which walks you through the entire process.
What is the best strategy for making changes to a specific file within a C# .NET project and a DEV server and then moving that file to a different environment, say server B? I noticed it always wants me to recompile on the destination server and I figured I was doing something wrong because I didn't think I would have to (plus the server isn't in-house so it is really slow and time consuming).
Any suggestions or strategies you or your company uses would be appreciated.
Make sure you are using a Web Application project where it compiles a DLL, not web site which uses loose code files.
You could use a source code versioning system like Subversion.
use a source control program for source files (like SubVersion) and Cruise Control for binaries built out of those files...
For web application development my experience has been:
Developers have a development environment on their local machines that is attached to source control
A DEV web server with shares to the projects created allows developers to COPY files to the web application folders manually.
A TEST web server where MSI installations ONLY are used to distribute the changes for UAT
A PROD web server where MSI installations ONLY are used to distribute the UAT approved MSI
The size of projects I am involved with usually makes build scripts overkill, most times a project is being worked on it is built many times for debugging etc.