I have a managed package which I would like to be installed in a Professional Edition.
When I try to install the package in the PE, I get following error, of course, my package has few Apexclasses/Pages/ControllerExtensions etc and does HttpCallouts to a third party WS.
Installing this package requires the following feature and its
associated permissions: Apex Classes
I came across a post somewhere stating that this error would go away if I get my package "Security reviewed and Certified", which seems to be a lengthy process BTW, but not too sure about this.
My question is, does "Security review and Certification" allow me to install the same package in the PE?
Or are PEs missing ApexClasses altogether, i.e my package can only be installed in Enterprise/Unlimited editions.
Check out this page from Salesforces documentation. It should answer all your questions. http://www.salesforce.com/us/developer/docs/packagingGuide/Content/dev_packages_apex_ge_pe.htm
Related
I'm maintainer of azcopy chocolatey package. https://chocolatey.org/packages/azcopy
Microsoft released version 10 of azcopy (from version 8).
The tool is now a single exe (in a zip file).
The old one was a MSI installer.
The command line is completely different between v8 and v10.
I've got two choices :
Create a new azcopy10 package for this package and have both living and at some point deprecate the old one
Simply "upgrade" the azcopy package to v10 as I don't expect MS to upgrade v8 anymore. If people are willing to keep v8 they still can avoid upgrade (I was going this way)
In case I just upgrade the azcopy, how do I manage the upgrade ?
If v8 is installed, do I uninstall it ? Is it allowed to uninstall a package in the chocolateyInstall.ps1 of a new version ?
Do I just manage the actual installation of v10 and let v8 if already install?
So, here are my thoughts on this...
Are these tools intended to be used side by side? You say that there are differences in how the command line functions, so it sounds like maybe that is the case. If you can use them side by side, then that in my opinion would be a case for a new, standalone package, named azcopy10.
That leaves the question on what to do with the existing azcopy package though. Should this be changed to be azcopy8? If so, should the existing azcopy package become a meta package, that points to either azcopy8 or azcopy10? That would certainly fit with how some other packages out there work.
However, this leads us back to the question of what to do if azcopy is already installed...
If they "can" work side by side, then simply blowing away the existing installation probably isn't a good idea, as some people might want to have both installed. As a result, a package parameter might be required to handle the uninstall if someone specifically chooses to uninstall it.
Long story short... There are lots of choices here, and there is unlikely to be one "correct" answer, as you will never please everyone. Likely, this doesn't help you though :(
For some reason I can't get SQL Server 2017 installed on my Windows 10 machine.
First thing to do with this buggy installer is that I had to uninstall VCRuntime 2017 in order for the installer to work.
And now, the installer is stuck at this point exactly every time I try to install it:
What I've tried so far:
Killing msiexec process
Running the setup with additional parameter as mentioned here
Setup.exe /SkipInstallerRunCheck
Restarting ... reinstalling ... turning off anti-virus ...
[Solved]
The problem was due to a background download that was taking forever especially on a low internet speed (i.e. python or R-support component).
[Solution]
If you really need python or R-support just wait until download is complete
Else, deselect python and R-support from the component list.
(or) kill the child process for python or R-support component downloader from task manager.
UPDATE:
The actual problem turned out to be the R-support component(s) slowly downloading in the background locking up the installation GUI
with no notification or warning show to the user as to what is
actually going on.
So it seems this "locked install problem" can be caused by installing several different components, at least by Python or R-support. As mentioned below, please check any available logs or event logs for clues.
In summary, options:
Maybe try to unselect such components for install if you do not need them.
If you need the components, leave the setup to complete, and check progress in log files as explained below. Verify Internet access (proxy?).
Stuck Download?
UPDATE: Did you see this blog? Looks like the setup tries to download and install the Python runtime, and this can take forever. Are you behind a proxy btw? No direct connection to the Internet? If so I suppose this could also cause further problems. Probably not the cause, but worth a mention.
Apparently you can check the following log file for progress for the installation:
%ProgramFiles%\Microsoft SQL Server\140\Setup
Bootstrap\Log\DATE_TIME\RSetup.log
DATE_TIME in the above path must be converted to your valid values. For example: 20170804_162723 (date part and time part).
See this answer as well: SQL server 2016 installation freeze. You could also try the suggestion to deselect all components you do not need to prevent any background downloads?
General Debugging
Leaving in the general purpose debugging suggestions below.
Generic Advice: From experience I would create a new local admin user and try to install using that account. This is to avoid any "unclean" or special conditions that have occurred in your user profile or registry during regular Windows use. Might not do much, but sometimes it gets the job done with surprising ease. Worth a try I think.
Some Further Things: I wrote up a little check list a while back, I'll add it and see if it inspires some new ideas that can help you. See under "Core Deployment Problems". That first "check list" was condensed from a longer and somewhat excessive first writeup - one of those answers that unintentionally turned into a blog and maybe a hard one to read.
Logging: Did you check log files and / or event logs properly for clues as to what is happening? I find the best approach for deployment to enable logging for all MSI installations. The performance hit it triggers is minuscule compared to the benefit of having a real log-file always available when you suddenly need one. You can enable logging for all MSI files as explained on installsite.org (section: "Globally for all setups on a machine"). MSI log files will then just sit in your %TEMP% folder after installation. They have a random hex name, and you can flush them all regularly if you do not need them. You sort by modify date / time to find the latest one(s) created - obviously.
Jedi trick: You will want to go home and re-think your life if you don't enable logging for all MSI files. Moral of the story: MSI log files are cool. They are very verbose, but they are beautiful. There are some hints on interpreting them here (bottom).
My 2 cents: SQL Server Installer consists of several small MSI installers. MSI installers can only be installed one after each other (as fas as I know). In my case, I launched another MSI setup while installing SQL Server. This caused SQL Server Setup to hold until I finished the concurrently running setup.
So, at least in my case the problem was self-made.
You have to remove configuration settings for SQL Server from Windows Registry editor.
Sql server
2017
VS
it might be a strange question, but does anybody know how to
check the name of the database which is used for a typo3 website?
Because I need this DB but I can't remember its name and I have got a lot DBs.
Thanks if Somebody knows the answer.
You can log into the install tool, via url (/typo3/install) or Backend Module.
Depending on TYPO3 Version you will find it in different places there.
In latest version you will see the information directly after accessing the install tool.
Log into the install tool, either under typo3/install, or via the menu in the backend when logged in as admin.
Go to "all configuration", and check the settings under $TYPO3_CONF_VARS['DB'] - everything database related is listed there.
TYPO3 7 LTS
Open the Install Tool of your TYPO3 installation with the following link (only a example): http://example.com/typo3/install. Make sure your Install Tool is enabled with the file ENABLE_INSTALL_TOOL on the folder typo3conf.
After login to the Install Tool you can see the database information. The informations are available on "All configuration" too. Here you can find the database area Database [DB]. The name of the used database you can find on [DB][database].
As nobody mentioned it yet:
If you have file access you can directly view the file typo3conf/LocalConfiguration.php (typo3conf/localconf.php for TYPO3 before version 6.x).
All configurations from the install tool are saved there. Just search for database.
If a Chef recipe (or any of it's cookbook dependencies) use the package resource without specifying a version, then the latest version of the package is installed. If you want to control and test exactly what you are installing, then you must always supply the package version. What can you do when the cookbooks that you depend on do not take the same precautions?
See for example the default recipe in the ark cookbook. If this recipe is used on a production server, it could install packages that have not been tested. This is just one example (with over 5m downloads) so I am wondering how people are getting around this problem.
What can you do when the cookbooks that you depend on do not take the same precautions?
I don't think there is a simple answer. This is basically "the Chef way" ...
(Actually, I would suggest that hard-wiring package versions could do more harm than good. One of the good things about using a (good) distribution's package repo is that they regularly release updates with patches for security issues and bugs. But if you wired fixed package versions into your recipes or roles/nodes or something, you would prevent any such patches from propagating to your system.)
However, if it is critical to you that package versions are stable then maybe ...
Clone and hack the cookbooks in question to use specific versions. (Actually, you probably need to do this anyway, to avoid being bitten by unstable cookbooks!)
Use a distro (such as RHEL or its "clones") that values long-term stability, and only pushes out package updates that are "really important".
Create your own private mirror of the distro's package repos with only the "good" versions of the critical packages in it.
Modify Chef so that the package resources pick/install specified versions by default. (I don't imagine this would be easy. But if you did come up with a good solution at this level, it would be a pretty useful addition to Chef! IMO.)
UPDATE
Actually, there is a way to do this for (at least) Debian-based systems; see the apt cookbook and in particular the references to "pinning".
Or with yum, you could "lock" particular versions using "yum versionlock ..." as described here: https://www.zulius.com/how-to/yum-install-specific-package-version/
UPDATE - 2
Another possible trick would be to "inject" a version attribute into the "unsafe" package resources. Something like this:
# first, include_recipe a recipe that specifies 'package "foo"' without
# a version attribute
# then ...
r = resources("package[foo]")
r.variables['version'] = "1.2.3"
With a little ingenuity, one could create a "package version lock" recipe that pulled the versions from a databag, and dealt with missing resource exceptions and version attributes that were actually provided. But I don't know if this is "A Good Idea" (tm).
Chef's package resource uses the package manager of the node's operating system (like apt, yum, etc). These tools always install the most recent version that is available through the repositories. That's why chef's package resource also installs this version.
What the ark cookbook is that it downloads the source code and then compiles it - obvious that you can specify the version to install (through the passed URL).
So it depends on your actual need. If you want to install the version that is available through the distro's or your own package repo, then it's totally fine (and that's what most cookbooks do). If you want to compile everything from source (where you usually have the option to specify the version, the coverage of chef cookbooks supporting this is lower.
Personally, I'd suggest that you set up an own apt/yum/whatever repo for the software for which have specific version requirements.
In short : I'm not managing this.
In a more complete answer:
All distro/release go throught a validation phase before releasing new packages, I'm confident over it and it helps me keep in sync with security fixes.
As far as I know all package managers takes care of not upgrading a package in a breaking way if it is a dependencies of a package installed manually, again you have to trust the package maintainer about this.
i.e.: the package ressource without version won't update make nor gcc if it is a dependency of one package you installed with a fixed version.
For exemple under ubuntu, if you set the nagios package to manual, it will never try to update the libc package over a breaking change, and so I could break other package isntallation as dependencies are not satisfied.
If you're absolutely concerned about it, you have some choices:
Rewrite each pacakge ressource to use fixed version of packages
Fork any cookbook to fix thooses issues (you can write a foodcritic rule to help you detect package ressources without specific versions)
Have your own repos, stable and testing, and move packages inside stable repo once tested and use testing repo on your staging/QA environement.
The 3 is the most conservative as you choose what is in the repo in the stable branch and it won't change magically. The drawback is security fixes you'll have to manage.
Hope it would help.
We had the same issue in our cookbook. So we decided to use data bags.
Data bags can be easily changed, for example:
knife data bag from file my_data_bag host1
OR
knife data bag edit my_data_bag host1
Your recipe will be able to see the specified version from the data bag using the code like this:
my_bag = data_bag_item('my_data_bag', 'host1')
Chef::Log.info("You have changed the version to: #{my_bag['version']}")
package 'java' do
version my_bag['version']
action :install
end
So finally you don't need to modify Cookbook or Recipe. All you need is to pass the version to the data bag.
I have a Solution with a Project which uses a MSSQL Database and generated for this a VisualStudio setup projekt. Then i have made another project with an installer class that should deploy my database on the installation.
So I generated the CustomAction Installer class using this Tutorial and also tried this C# Solution which is similar.
When im running now my setup project and want to install my Application i always get an error:
While initializing the installation an
exception occurred:
System.BadImageFormatException: File
or assembly ... \ CustomAction.dll or
one of its dependencies not found. The
assembly is inserted by a term that is
more recent than the currently loaded
term, and can not be loaded.
I hope the error is understandable, i translated it from german to englisch ...
So im grateful for any hints or tips to solve this.
regards
Perhaps this article will help:
http://msdn.microsoft.com/en-us/library/k7137bfe(VS.80).aspx
There seems to be 2 possible causes:
The DLL path is not being resolved correctly so the DLL is not found. You can try checking how the DLL relative path is resolved against the working directory.
There is a problem with the custom action. In this case you can try creating a log and see if you can find out more. You can create logs with msiexec.exe, for example:
msiexec.exe /i package.msi /l*v "C:\package.log"
One of the many reasons to not use InstallUtil ( Installer Class ) custom actions is the are "sticky" when it comes to the hosting process and the version of CLR being jitted. If a 1.1 CA fires then a 2.0 fires it'll fail with a BadImageFormat exception.
I really reccomend doing a good search for WiX Deployment Tools Foundation. It's a much better hosting model for your managed code and solves the problem and many others.