I have installed a package in VS 2010 using the regpkg.exe utility.
When I launch the Experimental instance using the switch /rootsuffix Exp the package is loaded.
I would like to disable the package only for the experimental instance
Even if I delete the package registration from the registry (10.0Exp and 10.0Exp_Config) when I launch the experimental instance again the registry keys are restores and the package is loaded. It seems that the registry keys in the experimental instance are inherited from the main instance.
Just in case - check your custom package class attributes - to ensure whether they use values related Exp hive. Maybe there are some attributes pointing to main hive by mistake.
Related
I'm setting new oracle db and want to add SRW package which is used for oracle reports.How to add this package and where can I found the functions and procedures of this package? Or should I write PL/SQL codes myself ?
Edit:DB is used for ERP.
From my point of view, you should install Reports as SRW built-in package is closely related to that product; that is, probably, the best option you might choose.
If you have a database to spare (as I can't guarantee that - if you follow what will be said next - you won't harm the database), find IAS installation which has Reports installed.
Navigate to its reports\admin\sql directory which contains several files, one of them being srwAPIins.sql which should install the SRW package (by calling other files located in that directory); it is editable, have a look at its contents.
Once again: don't do that if you don't know what exactly you are doing.
I added two values in an option set field on the production system (on premise Dynamics solution). I realized the right way would be to first introduce the two values into the option set on Dev, then export the solution as managed, and import it into production.
Now when I try to import the managed solution, I'm getting an error:
An error has occurred. {1}{0}
I believe it's because I had created those first values before in Dynamics, since Dynamics only does soft deletes.
I'm wondering should I go to the StringMapBase table and force delete those option set values, in order for the import to work.
You added those options as unmanaged customizations, so you should be able to delete them in production using the regular customization tooling.
Playing with managed solution is dangerous. That's why I always work unmanaged. I would suggest you to recreate the component manually with the same name or to copy your production database in dev.
I'm having troubles with some could I would like to execute when the service will be uninstalled. I've added the code to both the System.ServiceProcess.ServiceProcessInstaller BeforeUninstall event, and
to the override method OnBeforeUninstall, but that did not work too.
When using my InstallShield msi to uninstall the service this code does not get executed.
How can I force the service to launch some code during uninstall? Do I need to use a different event in my C# service? Do I need to change something in my MSI?
Note:
My problem is identical to the following
https://community.flexerasoftware.com/showthread.php?149176-MSI-Uninstall-NET-Service-does-not-launch-BeforeUninstall-event
Thanks,
sagar
You'll need to be more explicit about everything you've done. For example there is no automatic calling of installer class methods unless they are explicitly added to your setup as custom actions (in your case an uninstall custom action). You should also explain exactly how the service was installed.
Note that installer classes were invented by Visual Studio setups, and there is typically no need to use them because tools like InstallShield usually support the standard ServiceInstall and ServiceControl functionality in Windows Installer. Installer classes are unnecessary. Also, those events are Visual Studio specials, and it's not clear to me if InstallShield supports them. If you are using an Uninstall method to uninstall a service then just add your "before" code to before the Base.Uninstall() call.
If you want code to run when the service is uninstalled, the more usual way is to have a custom action that calls your code, and condition the call on REMOVE="ALL" (for an uninstall) or other conditions depending on your exact requirement. For example, if you do an upgrade MSI to upgrade your existing product do you still want to run that uninstall code?
.NET Installer Class: PhilDW has already said it all, but I just want to add a couple of things. I assume you are using System.Configuration.Install.Installer and the ServiceProcessInstaller Class (there is a sample in the Installshield help file). There used to be (and I think there still is) a flag for each Installshield component called .NET Installer Class. You can set this flag to Yes, and then I believe Installshield itself will take care of running your installer class methods (Install, Commit, Rollback, Uninstall - whichever one is implemented I think, but I have never tested all scenarios. I don't use this feature).
InstallUtil.exe: Running InstallUtil.exe would indeed call these methods. I am not sure how Installshield calls the methods under the hood (during setup execution) - they may actually be calling InstallUtil.exe for all I know, or some more low-level API call.
Conclusion: Just go to the components view and click on the component containing your service.exe file - and set the flag mentioned above. The exe must be a key-file for the component in question - and it must be a .NET assembly. Like PhilDW wrote, I wouldn't use these methods since they are intended to be used during service development only - not during deployment. For one thing you could run into runtime errors when the methods try to run faulting your whole setup (and often unnecessarily so), and there are also likely issues with rollback and potentially other problems. Can we ask what the methods are actually doing? Perhaps you are just deleting some log files? There are other ways to do that - most significantly using the RemoveFile table.
I have an installer implemented with "Packages" which contains the payload and after running some plugins and a post install script it successfully installs the product.
The same package bundle is used for making updates too, as we run it in background with root privileges and it overwrites the current/old installation files.
We now have the requirement to make a lightweight installer having the components (different Packages inside the product) in a web location to be downloaded and installed.
As I know that this is possible in other systems as Windows/InstallShield with "Releases of Web Type", I would like to know if this is possible in OS X. Otherwise, I will have implement it all from scratch (packages management, download, packages versions compare to make selective updates, privileges escalation, etc).
Well, it was long ago and I almost started doing a web installer from scratch but then I found out that the option is in Packages itself. Hope this helps.
It is the "Package Reference" option.
According to the Packages documentation
A Package Reference lets you use a package that is hosted on a web
server or a removable media and to which you may not have a direct
access. This package will not be built during the built phase.
I think that any referenced package will have its own pre-post-scripts so there would be no problem because of the limited options in the Package Reference. But I need to test it.
I have created a module, exported the extension and afterwords I have installed it (on a fresh store) using direct package file upload. The extension works as expected.
Now, I have made some updates, exported the extension with another Release Version number, but when I try to upload the archive (in the same mode) I get an error ("CONNECT ERROR: Package file is invalid [..] './app/code/local/Smart2Pay/Globalpay/Block/Form/Pay.php' already exists")
I read that I could alter some downloader\lib\Mage\Connect\Validator.php file (here) in order to permit file overwriting, but I want to know if there is any other best practice related solution. I need this extension update to work for all magento users.
Like Tim says, the correct way to install a newer version of a Magento extension package is by first running the uninstall option in MagentoConnect Manager to remove the old extension, and then running the install option to install from the newer package file.
Unfortunately this is the (poor) design of the MagentoConnect package manager feature.
Its also worth explaining what happens with any database modifications that the extension / package makes. Magento modules have no way to specify uninstall scripts or instructions. This means that after the original module / package is uninstalled, any database changes are still present and have NOT been removed. When the newer version of the module is reinstalled, this should trigger the module's DB upgrade scripts to run instead of it' install scripts.
So the detailed breakdown of what happens is the following:
When the module is originally installed from a package, the module's newest install script corresponding to the module version in config.xml is run, making any necessary database changes.
When the module is unistalled from MagentoConnect manager, the database is left as-is, so all changes the module made are still present in the DB.
When the newer version of the module is installed, the Magento database core_resource table tells the installer which version of the module was previously installed. The previous version and new version numbers are used to find an applicable database upgrade script in the module code. If the appropriate upgrade script is located, it is then run.