I have two components in install shield setup. Now I am going to remove those two components and new two components but I want to keep those older components when user update my product.
Is there any way to keep older components while update ?
As long as you do not perform a Major Upgrade on the target system, the files associated with the deleted components will not be deleted from the system during an update.
Related
How to delete existing servers on PhpStorm? It seems that it is not even possible to delete the wrong ones.
Those "servers" are deployment entries and they can be managed at Settings/Preferences | Build, Execution, Deployment | Deployment.
Please note that most (if not all) of those entries most likely (in your case, of course) will be shared entries (seen by all projects; it's default and only option in older PhpStorm versions) and therefore potentially can be used by more than one project. It's better if you go trough each existing project and make them project-specific (Visible only for this project check box -- if you do not have such option then you are using quite old PhpStorm version).
I have a Drupal site running in production. After some time I had changes in code and through admin as well, some configurations, changed content types and changed body of some pages etc. Meanwhile the production database was growing. Now I want my changes in production by not loosing the data which is already in production DB. One way is to repeat the same steps as of Dev on production. That looks not good to me. Is there any automated procedure to migrate the changes?
Thanks
The modules features and strongarm will do the trick for you.
Features can help you save and migrate the content types, for example, while strongarm will help you migrate site settings and configuration information that is stored in variables.
After installing the two modules, go to Admin --> Structure --> Features --> Manage on your dev site and create features for the changes you want to transfer from dev to production. If you have both features and strongarm installed, it will let you create features that capture both site building components (content types, views you created, roles and permissions you have changed, etc) and site settings (settings stored in variables -- you'll see the long list of settings you can export once you install the strongarm module). When you create your feature, it is exported as code (as a module), and you can then add that module to any additional sites in which you want to add the components you selected when creating your feature(s).
You will have to install the two modules on your production environment too. Then add the features you just created in your dev environment to your production site. Once set up though, you can transfer changes between dev and production environments more easily going forward!
Here is the features documentation: http://drupal.org/node/580026.
Hope this doesn't sound too confusing!
We added some more functionality and database tables in existing drupal site, the site already is in live and having few registered users and their settings. Now we want to add these new functionality to the existing one without affecting the existing data in mysql database.
I am scared to update the new database because there might be chance to delete the existing data in our database. How can we do this?
Modules can not only create tables, but also alter tables and can install records in existing tables (variables, menu items, enabled/disabled flag in the system table, etc...) so while there are 40 new tables there are likely multiple changes/records somewhere in the other 90 tables as well.
I recommend taking #MikePurcell's advice and making a back-up of the existing production database (and module files if you are applying any updates to modules that are on both the production and development sites), installing the new modules, and testing to make sure everything is still working properly. Unfortunately if you've customized those modules you'll need to re-apply your customizations.
Is it possible to maintain multiple workspaces for each build in Hudson? Suppose if i want to keep the last 5 builds, is it possible to have the five corresponding workspace folders also? Currently whenever a new build is scheduled it overwrites the workspace.
Right now, the idea is to reuse the workspace.
It is based on the SCM used (a SVN workspace or a Git workspace or a ClearCase snapshot or dynamic view or ...), and in none of those SCM plugins I see the option to build a new workspace or to save (copy) an old one for each run of the Job.
One (poor) solution would be to:
copy the job four times, resulting in 5 jobs to be modified for specifying 5 different workspaces (based on the same SCM configuration, meaning those 5 workspaces select the same versions in each one of them),
and have them scheduled to run one after the other.
As far as I know, there's no built in way to do it.
You do have a couple of options:
As one of your build steps, you could tar (or zip) up the workspace and record it as a build artifact.
Generate a tag with each successful build (e.g. with the Subversion Tagging Plugin)
Although not ideal, you could use the Backup Plugin.
The backup plugin allows you to back up the workspace. So, you could run the plugin after every build and it would archive the workspace.
Again, not ideal, but if this is a must-have requirement, and if it works with the way you're using Hudson, then it could work.
Depending on what you want to do, you have a few options.
If you need the last five workspace for another job, you can use the clone workspace SCMlink text plugin. Since I have never used it, I don't know if you can access the archived workspace manually (through the UI) later.
Another option worth to try, is to use the archive option and archive the whole workspace (I think the filter setting for the archive option would be **/*). You can than download the workspace in a zipped version from every job run. The beauty of this solution is, that the artifacts will be cleaned up when you delete the particular job run (manually or through the job setting to delete old builds).
Of course you can also do it manually and run an copy as the last step of your build. You will need five directories (you can name them 1 to 5). First delete the oldest one and rename the others (4->5, 3->4, ..). The last step would be to copy the workspace to the directory holding the newest copy (in our example 1). This will require you to maintain your own archive job. Therefore I prefer one of the above mentioned options.
We have a product developed in C#.Net. It is not a web application but a desktop version. It connects to various databases like MSSQL, MySQL etc.
We keep on upgrading the versions of the software for bug fixes as well as new functionality.
These updates changes the exe as well as dll used and the database also.
We would like to know what are the different methods using which we can provide updates to our customer.
Consider deploying your app with ClickOnce . Lets your users easily install the application from a web server, and it has automatic support for updates. It's integrated with visual studio, and will generate the stuff you need with the push of a button.
Well, there are several different paths to take.
Simple: Just provide a new installer that overwrites the previous installation. Send the clients an email when it's ready or simply put it up on your site.
Mid level: Provide a "check for new version" function in your app that compares it's version number to one retrieved from a web service on your side. Fire up a browser to download it and run the installer if necessary...
Best (IMHO):
Create a wrapper application for yours. This wrapper is what would actually be started when they click your icon. It would check for new versions (again once every couple of weeks), then fire off the main program if everything is good. If an update exists give the user the option to download it. Download the file and replace the real app. Then launch it. BTW, This is pretty close to the Firefox model.