We are migrating the project from sitecore 6.2 to sitecore 7.1.
I am trying to install the Active Directory Package "Sitecore Active Directory 1.1 rev. 130705" after upgrade of Lucene Search.
I am getting the error
"Sitecore.Exceptions.ConfigurationException: Could not create instance of type: Sitecore.ContentSearch.LuceneProvider.Analyzers.DefaultPerFieldAnalyzer. No matching constructor was found.".
This is when I try to install the package using Installation wizard in sitecore 7.1
As the Exception Message states its an issue with Sitecore's ContentSearch. It's not relating to version of Lucene or upgrade issues. The source of the issue is an incorrect Lucene or Solr (depending on which on you are using) IndexConfiguration.config file.
Check this first
Before proceeding make sure its not human error. This error will be displayed if you have the index file in the App_Config/Includes/ more than once. Or if two or more Index Configuration files with the same xml element name.
Option 1 - Remove the file
You can either remove the offending IndexConfiguration.config from the /App_Config/Includes/ folder and update the relating Index config files to use the DefaultIndexConfiguration in the configuration XML node;
<configuration ref="contentSearch/indexConfigurations/defaultLuceneIndexConfiguration" />
Option 2 - Fix the file
The other option is to amend the custom IndexConfiguration. Most developers are familiar with creating a custom Index by copying the entire content of the config file so will copy the entire DefaultIndexconfiguration config to create a custom IndexConfiguration causing the Exception. This is not needed.
You only need a small number of the settings from the DefaultIndexconfiguration config as shown in this blog on how to create a custom IndexConfiguration.
I havn't checked out any code, but it sounds like the caller ("Sitecore Active Directory 1.1 rev. 130705") is compiled with an older version of Lucene.Net. Check the references of the AD-package and make sure you're using same version of Lucene.Net, or upgrade your AD-package to use the newer version.
I can't say how much coding is involved when upgrading the Lucene.Net related code (if you have access to it), but updates during the last year or two are mostly casing changes or get-methods transformed into real properties.
I had a similar issue and it had to do with a developer creating a backup file in the app_config\include directory.
They were updating one of the config files and in order to create a backup they just copied the file, which created another .config file (SameName-copy.config)
To fix we just renamed it to SameName-copy.config.bak-ccyymmdd
Hope this helps someone in the future with similar issue.
Note that you cannot upgrade directly from 6.2 to 7.1. You will have to go in steps, going to 6.5, 7 and then 7.1
Related
We're making a project that is primarily a Windows Service EXE.
We're using WIX (with heat) to create an installer, that creates the relevant files and registers the EXE with Windows Services.
We've got to the point of implementing the installer upgrade logic, which largely JustWorks(TM) by setting the Version attribute of the Product tag in the .wxs file.
One issue that I can't see how to manage is the config files of the tool.
The tool has various config settings that can be modified from within the tool.
We're using ASP.NET, which has built in settings/config management, and the config settings that get changed are declared as "User" settings. When we run the save the config changes, it creates a secondary config file which overrides the default settings in the primary config file.
The primary config file exists at <installRoot>\MyCustomService.exe.config, and the secondary config file is at <complicated\Path>\vX.Y.Z\user.config.
Where X.Y.Z is the AssemblyInfo version number which is held in sync with the WIX Version number.
When we install a new version, the tool starts looking in a new path for the user.config ... and can't find it. So functionally, installing a new version resets all of the user's configuration :( .
What is the appropriate way to get a WIX upgrade installation to maintain the existing config?
ASP.NET config supports upgrading user settings from one version to the next, using the .Upgrade() method. You're better off using that rather than manage this in the installer.
This question has details on how to manage that: How do you keep user.config settings across different assembly versions in .net?
but the core solution is:
if (Settings.Default.UpgradeRequired)
{
Settings.Default.Upgrade();
Settings.Default.UpgradeRequired = false;
Settings.Default.Save();
}
Having created UpdateRequired as a user property existing only to manage this process
I am trying to add the functionality to uninstall a previous version before installing a new version of a certain installer. The CPackWIX documentation page (https://cmake.org/cmake/help/v3.3/module/CPackWIX.html) is not clear about how to use CPACK_WIX_PROPERTY_PROPERTY or CPACK_WIX_PATCH_FILE to modify CPack generated WiX XMLs. Let's assume the following doesn't already exist in the CPack generated XMLs. Is there a way to add the following to them using a patch file?
<InstallExecuteSequence>
<RemoveExistingProducts Before='InstallFinalize' />
</InstallExecuteSequence>
The documentation shows how one could add an environment element to a component. Is there a way we can do the above extending that logic?
I had the same issue as you (uninstall previous version of a package) and had some troubles trying to use CPACK_WIX_PATCH_FILE so I thought about another solution: using CPACK_WIX_TEMPLATE macro and setting it to point a modified version of the default template.
The default template can be found here: https://github.com/Kitware/CMake/blob/master/Modules/Internal/CPack/WIX.template.in
I know it's not ideal since this file might change after CMake upgrade.
But the interesting is that I realized adding "RemoveExistingProducts" didn't work because this was already handled in the default template file (as part of MajorUpgrade).
The real issue for me was that CPACK_WIX_UPGRADE_GUID was never set in our project, so CMake was always generated a new one (there was a nice warning everyone ignored) and as a result, all installers look like they are referring a different application.
After setting CPACK_WIX_UPGRADE_GUID, installing previous versions automatically removes old packages.
But this doesn't work on packages which didn't have yet the CPACK_WIX_UPGRADE_GUID set.
I ran into an issue that some of the files in my installation were not replaced on upgrade. The problem is not too severe yet, but I would like to avoid it in the future. According to https://msdn.microsoft.com/en-us/library/aa368599(v=vs.85).aspx files with higher version are always used. I considered using a CompanionFile to force upgrade the relevant files. But I would like to know what file should be used as the companion parent. Does it have to be an exe or dll? I am asking because I found online (in WiX: A Developer's Guide to Windows Installer XML) an example of FileSearch on .txt file with MinVersion and MaxVersion. Can txt files be also versioned? And is there anywhere a list of file types WiX searches for version? I did not find anything like it.
If your product has one main exe it is probably best to use that since it logically follows that your new version should always put the new exe there since the exe will have the new version as its file version. In reality, it doesn't matter what file you companion file reference as long as you know it will always be installed (have a higher version) than the previous installation.
I don't think you can version a txt file and probably the version info in the file search is ignored if the file has no version.
Using Web Deploy 3, is there a way to exclude certain assemblies which a project depends on?
The scenario is:
Install the first package, platform-like assemblies.
Then we install product-like assemblies
Yes, I know that that we can use –enableRule:DoNotDeleteRule flag to prevent the second package from overwriting the files.
I think it is just a bit dirty to have unwanted assemblies in the second ZIP package.
Any thoughts?
I used the following switch
-skip:objectname='filePath',absolutepath='logs\\.*\\someNameToExclude\.txt'
to skip certain files when deploying from commandline (I used sync verb)
Update
As mentioned by msuhash - complete command-line reference can be found on technet (see skip setting).
I am creating an install package using InstallShield Pro X. The upgrade works properly. However, the product manager wants the upgrade to replace all files on an upgrade even if the create date != modify date on the file.
I see that to do this I need to set REINSTALLMODE=vamus rather than vomus. However, I don't see how to tell InstallShield that I want it to use that setting. By default setup.exe always passes vomus to windows installer.
There is a property in the InstallShield project named ReinstallModeText that I changed from omus to amus but that seemed to have no effect.
So, how what do I set in the install project so that when setup.exe detects to run an upgrade it sends REINSTALLMODE=vamus? Thanks.
Update: Tried adding the following to the MSI Command Line value in the Release section:
REINSTALLMODE=vamus
This did not work. Setup.exe didn't set REINSTALL=ALL on the command line what I did this. I added that to the MSI Command line and the upgrade worked as expected. But, not the problem is if it is a NEW install those properties are still being set and the installer fails.
In investigating this further and testing more options I think the best answer is to modify the product code in addition to the product version and author it as a major upgrade which removes the previous version first and then installs the new files.
The main problem with this is that it takes alot longer for the installer to run. I also think that you can not issue this as a patch, but I could be wrong on that count.
Don't set the REINSTALLMODE to amus or vamus (force overwrite files). These settings apply to all components in the MSI, and could hence in theory downgrade system files or at least shared files - this typically involves files included via merge modules. It is normally safe to set REINSTALLMODE to emus (replace files with lower or equal version number). Even this can trigger a file replacement error if you try to overwrite a system protected file on newer versions of Windows featuring Windows Resource Protection (wikipedia) (Windows Server 2008 and Vista onwards). On older Windows versions the file would likely be overwritten and then restored in its right version from the dllcache via the Windows File Protection feature provided that feature had a good day. There was (and is) an associated tool for system file checking: System File Checker.
If you have issues with files that should be replaced even if they have been edited, you can use the RemoveFile table to schedule the file for removal during install (and then it will be reinstalled).
The real solution is to consider the installation folder in %ProgramFiles% as read only, and not have the application save ANY settings or change any files. All config files should go to the user profile or the alluser profile and the application EXE file should be responsible for the copy to the profile locations.
See my answer here.
I don't have IS X handy, but in later versions of InstallShield you would go to "Releases", highlight your release, go to the "Setup.exe" section and there's a field called "MSI Command Line Arguments". There you would indicate any command-line arguments that you want Setup.exe to pass to Windows Installer. E.g. REINSTALLMODE=vamus
You mentioned you used ReinstallModeText with "amus". Have you tried ReinstallModeText equal to "vamus". The "v" causes the installer to run off the source package, not the cached package, and that may be your problem.