I would like to reuse one installation of Sitecore every time I need to make code changes. I currently have a branch to fix a problem, but now I need to create another branch to fix another problem. The problems are in different websites so I need to keep the seperate branches. I really do not want to create another Sitecore installation for this second branch. Is there a way to "swap" out these solutions and "reuse" the same Sitecore installation?
Mark Ursino's comment about removing the code got me to thinking. Since the solution binded to the Sitecore installation resides in the Website folder, I'll map both solutions to somewhere arbitrary, like "Sitecore Dev Folder", and then map the branch I'm working in to the Website folder of the Sitecore installation. When I change the mapping, the solution will download from TFS into the Website folder (blowing away the existing solutuion.) And that's how I can achieve the "swapping" of solutions.
Yep, we need more info here to really answer the question.
But... in general, I would advise you not to do this. Creating a new Sitecore installation is a piece of cake with the installer, and not exactly resource intensive. You could have it use the same DB if necessary to make things easier.
Mixing two different branches with the same Sitecore instance... it seems inevitable that something would get "F'd up", to use the technical term.
Related
We are currently running Sitecore CMS 6.5 (120706) with the shared source Item Buckets module installed from here:
https://github.com/jerrong/Sitecore-Item-Buckets/tree/master/sitecorepackages/ItemBuckets%206.5%20NET_40/Final
We wish to upgrade to CMS version 7.0. I'm told that there is currently no upgrade path and to expect one in a few months. However we would prefer not to have to wait on this.
Item buckets is used only for a single section of our site. Everything else is delivered via the standard content tree.
We have tried upgrading to 6.6 first as required by the documented upgrade procedure, despite it mentioning later in the instructions that the shared source item buckets module is unfortunately unsupported for upgrade. Confirmed that this definitely does not work, we receive the error:
Exception Details: System.IO.FileLoadException: Could not load file or assembly 'Lucene.Net, Version=2.3.1.3, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
We also tried disabling Item Buckets by removing the .config files etc. but we had further problems, presumably because of the actual content/data template changes that were made by the Item Buckets update.
We are thinking of trying a clean install of CMS 7.0, and then migrating our custom code base, items in the content tree (including data templates, layouts, renderings, etc) with Sitecore packages to work around the issue.
Can someone validate this approach, or better still suggest a much less painful solution!?
Many Thanks
(this is not official Sitecore advice as that is still being worked on disclaimer,disclaimer!)
Some ideas that might help ..
First we need to work on the data side of things (forget front end code for a second)
You could Un-bucket your items so that they are again plain Sitecore items. You could then remove the item bucket module templates and fields as you mentioned before (by 'unbucketing' you should now have no reliance on the bucketing templates etc.)
You could also look at creating an 'anti-package' using Sitecore Rocks, either way this should give you a site closer to a site before the item buckets module.
You could then get a base/clean install of 6.5 (120706) and then compare it to your working copy 'master' database using a tool like Sitecore Courier.
Sitecore Courier - https://github.com/adoprog/Sitecore-Courier - Allows you to compare 2 versions of Sitecore DB against each other and make an update package of that difference.
This should make you an update package of all the changes that have been made to your 'master' database so that you can, in theory, install this into a fresh copy of Sitecore.
You could see how far this gets you when you install this update package, in theory then you can re-bucket your section that used the old buckets module but using the new built-in buckets.
Front-end code wise, the old item buckets modules way of accessing the search has been completely re-written as that it now uses Linq To Sitecore. Hopefully this will be easier to migrate and the buckets will still work in largely the same way (hopefully better hehe!)
Like Ruud I would be interested to hear about others techniques for doing this.
Any extra complexity could come from thing like :
1) How much customisation of the core database you have done
2) How many new field types and XAML applications you may have written
At this point, there is no good solution for this yet.
If you are actively using the module, there is no way to upgrade right now (not that I know of).
If you are not using the module at all, you can remove everything in Sitecore that has to do with ItemBuckets.
This is a manual job for now... (I've done this with success in a 6.5 environment).
To be sure you remove everything, open the item buckets installation package (the ZIP file) to see what items are installed and manually remove all those items from Sitecore (this will include templates, fields, field types, settings).
You can also use the search in the content editor to search for "itembucket" or "item bucket" and find related items that way.
Another way is to search with SQL directly in the master and core database.
Once you have removed everything in Sitecore and configuration that is related to the buckets, rebuild the link database and run a database cleanup (from control panel) and you should be good to go.
It's a dirty job...
If anyone has a better way, I'd love to hear about it!
the problem you are having there is that the item buckets code was compiled against Lucene.Net 2.9 and Sitecore 7 has v3.0.3.
You could add an assembley binding in in the web.config configuration/runtime section that maps the old version to the new and then fix any issues you get with deprecated methods etc...
You will probably also want to remove the Item Buckets module before the upgrade as suggested as the new bucket templates & items may conflict with the shared source versions. You would at least need to remove the Item buckets config and dll's from the bin folders as these could also conflict.
I don't think there is a simple way of doing it yet or Sitecore would have given out an upgrade path already.
This question already exists, but it is over one year old now and a lot has probably happened if the documentation is a good judge. There is no documented path to migrate from current redmine (2.1) to chiliproject for example.
Chiliproject is a fork of redmine, but I am unable to decide wherever I should migrate or not. There is no clear path as to how I should do the migrations and how much functionality I might loose.
Is there a way to compare the differences between the two projects? Is it worth to spend the time investigating the migration path?
If you have migrated what is your experience?
I searched StackOverflow for the "redmine vs. chiliproject" question because I am having a lot of trouble with installing plugins of any kind on the newest chiliproject version.
Usually, it looks like everything is working fine until you try to update the settings for the plugin (for example, install the Contact Form plugin and try to change something on http://SERVER:3000/settings?tab=contact_form), the debug log shows that the changes were made in the database, but they changes are never loaded back to the plugin page.
I have not been ale to find any documentation on potential changes to the plugin architecture in ChiliProject that would cause this. The plugin page does not list many plugins that are known to work with ChiliProject 3 either.
TL;DR: If you think that you will have any desire to use any existing plugins to extend the functionality of the program you choose, go with Redmine.
I've got all these great new plugins enabled, and I can enable them on any given project.
However, I don't see a way to add/remove them from many projects at once.
Perhaps I need a module management plugin? ;-)
In my case Redmine 3.1.0 and MySQL is used as DB server. I think, you'll get the main idea in case of other confuguration.
DELETE FROM `enabled_modules` WHERE `name` = 'module_name_here';
INSERT INTO `enabled_modules`
(`project_id`, `name`)
SELECT
`id`, 'module_name_here'
FROM
`projects`
You can activate module for one project to discover its name from enabled_modules. Or you can find it in plugin sources, it should look like 'project_module :module_name_here'
Please, don't do this if you do not completely understand, what is this answer about!
PS: Yes, I know - it is a dirty solution, but it's fast and easy enough for operation which is neccesary once a year or less.
It's been a while and I reckon the OP has since solved his problem. In case someone else has the same problem:
We also had to activate a few modules in all projects and wrote a small script to do it for us:
https://github.com/EugenMayer/enable_chiliproject_modules
Edit:
This was created and tested for the Redmine fork "Chiliproject" but should work without changes in Redmine.
how can I enable it many projects at once?
You can't - at least not by using the UI.
Let me first say I am aware of this faq for Mach-II, which discusses using application specific mappings as a third option when:
locating the framework in the server root is not possible and
creating a server wide mapping to the Mach-II framework directory is impossible
Using application specific mappings would also work for other ColdFusion frameworks with similar requirements (ColdSpring). Here is my issue however: my (I should say "their") production servers are all running ColdFusion MX7, and application specific mappings were introduced in ColdFusion 8. I most likely will be unable to do option 1 or 2 because they involve creating server wide changes that could conflict with other applications (I don't have a final word on this but I am preparing for that to be the case).
That said, is there anybody out there who was in similar bind and has done an option 4, in any ColdFusion version, or with any similar framework? The only option 4 I can think of is modifying the entire framework to change this hardcoded path, and even if that worked it would be time consuming and risky. I'm fairly sure that if there was a simple modification or other simple solution it would already be included in the framework (maybe it's included in version 1.8 of Mach-II and I don't know about it yet).
Any thoughts on solving this problem or even unorthodox setups with libraries that have specific path requirements would be appreciated. Any thoughts from Team Mach-II would especially appreciated...we're on the same team here Matt! ;-)
EDIT
Apparently, the ColdBox framework includes a refactor.xml ANT task which includes a target that refactors the ColdBox code to use a different absolute path as a base along with several other useful refactoring targets. So problem solved for ColdBox users.
Looking at the build.xml for Mach-II (1.6 and 1.8) I don't see any target in there that would allow me to refactor the code. I thought about creating a feature request ticket for such a task for Mach-II but frankly I don't think creating such an ANT task is a big priority for the MachII team since the need really only relates to either
a) users of ColdFusion versions below 8
b) someone who wants to use multiple Mach-II versions in the same application, a use I doubt they want to support
The ColdSpring code I have doesn't come with any ANT tasks at all, although I do have unit tests, and I bet if I poked around the SVN I'd find a few build scripts.
Using Ant tasks to refactor and retest the code, or the simpler (and sort of cop out) solution of creating a separate ColdFusion instance for the application are the best answers I've been able to come up with. I don't need this application to exist in the shared scope of other applications, so my first solution is going to be to try and get a dedicated CF instance for this application.
I'm also going to look at the ColdBox refactor.xml ANT task however and see if I can modify it to work generically to recognize and refactor CFC references with modified absolute paths. If I complete this task I'll be sure to post the code somewhere and edit create an answer to link to it. If anybody else wants to take a crack at that or help me out with it feel free.
Until then I'll leave this question open and see if someone comes up with a better solution.
Fusebox is not so strict, I think.
In XML mode (maybe I call this not 100% correcly, just mean using the Application.cfm) it's just proper include in index.cfm, something like:
<cfinclude template="fusebox5/fusebox5.cfm" />
In non-XML mode it will need proper extending in the root Application.cfc:
<cfcomponent extends="path.to.fusebox5.Application" output="false">
All you need is to know the path.
Perhaps you could create a symbolic link and let the operating system resolve the issue for you?
I've been playing with FW/1 lately, and while it may look like you need to add a mapping and extend org.corfield.framework, you can actually move the framework.cfc file into your web root and just extend="framework". It's dead simple, and gets you straight into a great framework with no mess and very little overhead.
It should be as simple as dropping the 'MachII' folder at the root of your domain (i.e. example.com/MachII). No mappings are required to use Mach-II if you just deploy at the root of the domain of your website.
Also:
Please file a ticket for the ANT task you mentioned in your question. Team Mach-II would love to have this issue logged:
Enter a new ticket on the Mach-II Trac
If you want to tackle an ANT task for us, we can get stuff like this incorporated into the builds faster than waiting to for a Team member to work on the ticket. Code submissions from the community are welcome and appreciated.
We don't keep an eye on Stack Overflow very often so we invite you to join our official community group at called "Mach-II for ColdFusion" at Google Groups. The Google Group is the best place to ask questions or comments like this if you want feedback from the Team.
We have been using ClickOnce deployment for some time now and all has been fine until recently. We have one of our clients that is now deleting their clients Documents and Settings directories which inturn is totally erasing our clickonce cache. From what I have seen, there is no way of setting an alternate location for this, but many of my references online were from 2005.
I was hoping someone may be able to provide a definitive answer as to whether or not they have changed this and there is a way to change the installation directory and if not, do you have any recommendation where I may be able to find a solution to this problem.
In then end, we would like the same Clickonce functionality regarding auto updates, however a way of letting the user choose where they want to install their files to. Any info would be great! Thanks!!
Dan
I found a post that seems to ask the same question as you do, and according to the answers it received, it is not possible to set the destination folder of a ClickOnce application.
Anyway, I think it's a reasonable assumption to make when developing an application for a client that the application data folder will not be deleted on an ad-hoc basis (unless this is a condition that has been known during the requirement gathering of the project).
If this client of yours doesn't have a very specific (and good) reason to remove the app data folders, I think you should just explain that "no, that's not going to work with our solution".