... so it can do the pre-registration of bundled extensions in
INSTALLLOCATION/share/prereg/bundle.
The meaning of Type of custom action is the following:
msidbCustomActionTypeDll + msidbCustomActionTypeBinaryData +
msidbCustomActionTypeInScript + msidbCustomActionTypeNoImpersonate +
msidbCustomActionTypeCommit = 3585
So it is a binary in a dll from the MSI itself, it runs deferred
with system privileges and after commit, because msvcrt90.dll is
available only after commit. The same type was chosen for the
removing part, it works.
Change-Id: I14c347b5cbc47789eb0484769a676703361c2193
64-bit registry entries were entered via a custom action, which
did not always work. By default the custom action ran with user
privileges, which were not sufficient to write the registry.
It is not necessary to use custom actions for this task. Windows
installer supports it well.
Change-Id: Id65458c363c2b90b3e7d166b4c836bfb1ff19bf4
This makefile must be included from other makefiles, which means it must
be delivered first, which does not play so well with gbuild's
all-in-one-process build. Because the version has not changed once since
the library was introduced in 2006, I consider this just an unecessary
complication of already complex build process.
Change-Id: I8304f0e8ef9e59a046b10f423dbe61d75e3fc5c2
In some circumstances installation of embedded VC++ runtime
fails with error code 1935. This usually occurs, when there are
many different versions of VC++ runtimes installed on the computer,
including beta versions. We can workaround this Microsoft bug, if we
don't install our VC++ runtime. A new property was introduced. It is
called VC_REDIST, and installation of VC++ runtime depends on its
value. (BTW the solution is general, ComponentCondition can be used
for any merge module, now we have only the VC++ runtime merge module.)
When the user experiences error code 1935, he should try to install
LibreOffice with the following command line:
msiexec /i <msi file name> VC_REDIST=0
The patch fixes another minor issue. 64-bit VC++ runtime will
not be installed on 32-bit systems any more.
Change-Id: I I6c5e066c6e60b011235e6019a8a35c9e953209bc
4478b739dd "convert bean to gbuild and add to
tail_build" broke the following:
* The name of the officebean dynamic library must not be changed (by adding the
"lo" extension), as code in officebean.jar uses it in NativeLibraryLoader.
* With gbuild's per-default hidden visibility, JNIEXPORT functions must instead
use SAL_DLLPUBLIC_EXPORT. (Windows-only code in bean/native/win32/ should be
safe to continue using JNIEXPORT.)
Change-Id: I I3c312dd05c90421ba0c726496b7149a26d155604
It is done the same way the beanshell is handled.
Currently it can't be enabled by default as internal version has
patched-in debug interface.
We can choose two paths, rewrite the code to the new rhino debug
interface or just strip the current one out.
Change-Id: I48af18c635816db8269f13a649b62e9c454ee1e6
Do not install the benashell/javascript stuff if they are not actually
bult.
Build rhino only when required by javascript extension.
Change-Id: Icc378524008389af35631c64a1a0288eb4f271be
move vbaobj.uno.so into -calc subpackage and vbaswobj.uno.so
into -writer subpackage to fix dependencies
Change-Id: Id9457d71ee38537b07456816845cb870c7b7a041
this removes dmake completely out of the build for migrated modules
build.pl now assumes modules to be gbuild, unless there is a
prj/dmake file
Change-Id: I674a036b182ee13c5ec093e83cb3d38133112d3b
Although Microsoft says that SelectionTree control can publish a control
event only on Windows Server 2003 and above, the custom action seems to
be working under a fully patched Windows XP SP3. Maybe it fails silently
on older Windows XPs, not to mention Windows 2000. I did not test those.
Instead of a pleiade of libraries, one for graphic filters (wpftdraw)
and one for text document filters (wpftwriter) to diminish duplicate
static linking.
