I was starting Windows Azure using WebSites, now I'm facing with the situation where I need Crystal Reports in my site, so I'm looking for a way to install the Redistribute Files to use it in my web page to generate reports.
I follow this page:
http://dotnetspeak.com/2012/07/running-crystal-reports-on-windows-azure
So instead of having a simple website, I'm gonna use a cloud app. Unfortunately, I'm updating frequently my website (role in Windows Azure project).
Do I need to redeploy all the time my cloud app each time I update my MVC project? Because it takes so long (like an hour, because I included a msi installer)
Thank you
Unless you build some custom extensibility into your application with some very robust dependency injection, yes, you have to redeploy.
EDIT: After re-reading your question again, I realised that you're using Windows Azure Websites.
The correct way to accomplish this is to use a webrole rather than the Websites
What you need to do is to store the installer as a blob in Cloud Storage.
Then part of a Azure Startup Task you can download from the blob and execute the installer.
If possible, you can also use the WebPICmdline (i.e the Web Platform Installer Commandline) to download and install for you from the Startup Task.
Steve Marx has done a few posts on using Azure Startup tasks. Here is one of them http://blog.smarx.com/posts/windows-azure-startup-tasks-tips-tricks-and-gotchas
Adding a bit to #Robert's answer: If the actual execution of the MSI is taking an hour, then this is not a very good use case for web/worker roles. Anything that takes more than a few minutes doesn't really fit well with the stateless scalable model. If that's the case, you should consider running a Virtual Machine for running Crystal Reports. Then you can use your web role for everything else.
If, on the other hand, the one-hour time is mostly consumed by the uploading of the MSI, then I'm completely in alignment with Robert: Store the MSI in a blob, and then download it to your role instances upon startup.
I would suggest to split your single Cloud project into two - one for Crystal Reports only. This way you can deploy it separately from MVC site. You could also build extra smarts into start up task, maybe checking if Crystal is already installed. However, I think splitting them up should be good enough for you
Normally the update process does not lead to an complete re-image of your webrole, only the approot gets destroyed! Here you can find a very detailed information about what is happening on update and deployment: http://msdn.microsoft.com/en-us/library/windowsazure/hh472157.aspx
What does that mean to your problem? Code deployment is an "in-place update" process. If you install Crystal Reports in Drive C: or D: it wont get destroyed on each deployment.
In your Start-Up Task you have to check, whether the software is already installed, or not. In case it is not installed, just install it, as mentioned above on Drive C: or D:
Edit: I got the Point: Does your update Process takes so long, because of the file-size of your MSI? If so, i also suggest to upload the MSI into Blob-Storage.
Related
Suppose I have Rails 4 app, call it "Super SaaS". Now my client says he likes my appvery much, but he doesn't want his data to be in the cloud. So he says he would buy a licience from me to deploy "Super SaaS" on his own server. More like Atlassian Jira.
The question is: is there any secure way(in terms of protecting source code) to do that?
While you can probably package up your code as a JRuby application with JAR files and Java byte code, there are decompilers for that, so you can never presume your source to be 100% secure.
Ideally you'd offer some sort of VM appliance that the customer can install, a system image compatible with VMWare or whatever virtualization system they're using. This helps package up a fairly secure environment, but won't protect against a determined adversary trying to get your source code.
If you're giving out your code to someone in any form, compiled or otherwise, you have to have a certain amount of trust. Even compiled executables are not immune to reverse-engineering.
Ok, please bear with my noob question here.
I'm doing the simple task of making an update to my mvc application, compiling it and then moving in onto the production server.
I just wan't to know the best way to upload the compiled files. I have a single application pool, use ftp to upload the new application files and the site points to a single directory.
If I update just one view then which
files do I upload after compiling?
Is there a way to keep the site running
while I upload new code/views?
Where can I go to find out this
information?
Generally, you can update views without needing to re-cycle your web application. You would just want to replace the old version of the file with the new version, which can be done with a simple X-Copy command.
If there are code changes, then you will need to upate the web project DLL, which requires the app to recycle. This may or may not be a huge disruption, but it does mean that users may have their session interrupted, and lose some state.
Now, the question of how you could go about doing this is a little more complex. You can write a deployment process into your build scripts, which may be the easiest approach. The trick here, though, is that if you want to only include files that have changed, this can be a little trickier using vanilla NAnt or MSBuild tasks. You may also want to look at the WebDeploy tool from the IIS team. I've not used it much myself, but it is designed specifically to deploy web projects.
You may also want to hit google for some commercial deployment tools if none of the options so far seem to work for you.
We have a suite of programs that check for new versions at startup, and then download new versions to run if required. This is obviously a problem in Windows 7, when it is locked down as a 'standard user', as they can't write to the c:\program files directory and below. Anyone seen a example of an application that gets around with issue ?
Our applications are written in Delphi, but an example in any language would be useful.
Thanks in advance
Update:
We already have a system for determing whether a new version exists, the only problem is the download and install (if required), as this requires elevation. I can't think of a way that doesn't require an elevation prompt, or our users to reduce their security settings.
Update 2 :
I've asked a subsequent question, rather than adding a new one here
There are two options for application installation:
Application is available for all users: installation or update requires elevation for Windows Vista and up
The application is available for one user: install or update the application in the user profile in %LOCALAPPDATA%, no elevation is required
Ad 2: Google Chrome does this. It installs the .exe here:
%LOCALAPPDATA%\Google\Chrome\Application\chrome.exe
--jeroen
Typically what you will see an application do if it needs to escalate permissions is something like this.
Application determines if upgrade is needed
Application launches an "updater" service that requires "Administrator" permissions
Application updates itself with this updated
Application re-starts
This is a pretty common scenario, especially since to update your own DLL you need to go to a secondary process anyway.
Here are some tips for you to get around updating challenges:
If your file is names 'update.exe' or 'install.exe' then it will automatically force a UAC elevation prompt. This is an easy way to make existing software bypass Windows Vista/7 permissions.
It is not a good idea to have the update checking and update process managed from within your application. The problem is that your app is likely to lock files and need updating itself. An external app should manage your updates.
The simplest update solution is to make an HTTP call that checks for the current product version number, and then download the installer binary if necessary. This won't give you any flexibility in updates, but it is a quick and easy solution.
Our company sells software that specifically helps with automatic updates on Windows 7 UAC (you can visit AutoUpdate+ by clicking here: link text). The best reasons for using a third party solution - any solution - are that you will have more flexibility with your updates and also avoid the finicky challenges of supporting different Windows releases.
Or you can have it so that the user runs a launcher app.
The application uses the LOCALAPPPATH\ folder to store a cache of the main application.
Launcher checks to see if the internet has newer version of file(s) than the cached file.
Launcher launches the cached application in LOCALAPPPATH
Your app can check if a new version is available on the remote server. If it does, then it can download update files in one of user-specific folders, like user's temp folder. You can get address of such special folders using SHGetSpecialFolder API function.
Once the download is done, you can pop up a dialog box telling user that you are ready for update. If user agrees with update, then you can run the updater process with elevated privileges (as administrator), and updater process can replace existing files in your installation path with the ones already downloaded in user Temp folder. To run your updater as administrator, you can use ShellExecute:
ShellExecute(0,'runas','notepad.exe',nil,nil,SW_SHOWNORMAL);
When updating is done, your updater process can restart your app.
You need to have a separate executable to the updating work. The updater needs to have a manifest that marks it as requiring elevation.
See: http://msdn.microsoft.com/en-us/library/bb756929.aspx
If your application uses MSI (Windows Installer) for its installer, then User Account Control Patching, if properly configured, can let you install updates without elevation.
If your installer wasn't run under admin - you don't need any additional rights to install update.
If your installer was run under admin - then it can create a task in Task Sheduler. Say, run this task once a week, under this account (admin) and with highest privs. Task will be your updater. Simple.
It has been a long while since I have really worked with J2EE so please excuse my ignorance. My recent engagement in a Grails project has peaked my interest in Java once more and especially in Grails as it makes building web applications on the Java platform fun again. That being said, I would like an expert to comment on the following requirement that I have for an application built using Grails:
The Design Team (web designers) require access to the GSP pages and edit the view files (layouts, templates, etc.) without bothering the development team (software developers). This scenario can take place both during construction and after deployment into production.
The communication level between the Designers, Developers, and Business Users are not an issue here. However, about 40% of the time, the Business Units involved request changes to the front-end that have no impact on the Developers time but require the time of a Design Team member. Currently, the deployment workflow follows the Grails application through the deployment of a War file to a Tomcat server. I imagine there is a simpler way to allow the Design team to make UI changes without going through the build and deploy lifecycle.
Several of the Design Team members have had exposure to PHP in the past and at times miss the ability to just overwrite a template file to make a UI piece more functional or improve a layout template. I hope there is a similar way to accommodate such simplicity within Grails. I have been told that exploding the War file might be an option but that still requires the reload of the Tomcat hosted application.
If you believe that I looking at the desired solution the wrong way, please do chime in as I am more interested in a workable compromise for all the team members involved. Thank you.
You need to specify the following settings in Config.groovy:
grails.gsp.enable.reload=true
grails.gsp.view.dir="/path/to/gsp/views"
The 'grails.gsp.view.dir' is typically the path to your checked out SVN repo. You can then just 'svn up' everytime you want to update the views.
There is one caveat: When a GSP view is compiled it uses up permgen. Eventually you will run out and need to restart the server.
You could run a server with a version of the application via run-app in development mode. The designers can then make changes to the views and they will reload. They would need to be able to acccess the source code on the server via a share of some kind. As a plus, if you checked out the source the designers could then commit their changes from the server.
The downside is that if the reloading fails or you run out of memory (has been known to happen with lots of reloading) either a developer would need to stop and start the app or you could provide the designers with a script to run to bounce it.
You'd obviously take a performance hit by running in development mode and via run-app but it might a ok trade off in your case.
cheers
Lee
This may not be the direct answer for this question but since you seem to pay attention to designers' role in a project, you may also check my designer friendly GSP implementation which enables designers to view GSP pages even with custom tags thanks to the "tag declaration via attributes" feature.
If I have a windows service on a server, what is 'best practise' for updating the service? (say there was a bug in it, or I need to ad more features to it).
Is there a way I could shutdown the service, patch it and get it up and running in a more automated way?
(any links with code would be great)
Well, you could always up the version on the installer (if you used one) and run that, from my experience it overlays old versions with the newer one.
Or you could simply shut down the service, copy in the new .exe (and dependencies if any) and start it back up. This could all be done with scripting and the NET start/stop functions I would imagine.
I'm sure there is a better way to do it than this though...
Depends how your service is written - monolith EXE - you'll need to stop and restart it using a process of choice e.g. Installer, Script + Service Control, batch and NET STOP/START etc.
If you structure it a little differently e.g. bootstrap EXE loading your service implementation as modules that can be unloaded/reloaded then you can have a different conversation. This is of course a quite a bit more complicated.
I've had some success in C# with a hosting solution like this, similar conversation here:
I want my C# Windows Service to automatically update itself
InstallShield supports Windows Services. Leveraging installers will make your task much simpler.