I've got a XLL Addin and I'm trying to run it under Excel 2007 XP without VBA installed.
My addin is well registered (OPEN key as /R "C:\Program Files (x86)\MyAddin\myAddin.xll" in HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Excel\Options). When debuging, I see that DLLMain is called... but not xlAutoOpen (neither others xlSomethings functions): my UDFs are thus not registered (it was done in xlAutoOpen).
Do I miss something ? Do I absolutly need VBA installed ? If yes, is there another way to avoid installing it ?
I had the same issue. When I installed Office I deliberately did not install any Excel Add-Ins -- it looks like this actually cripples the loading of any future Add-ins.
After running the Office installer again and choosing to install the 'built-in' Add-Ins, I finally hit my xlAutoOpen breakpoint.
Related
first things first:
It was working when I used it last time (which is about more than a month ago).
The Problem is, that no command which is from an extension is working, it seems like no extension is loaded.
Only the default commands do work (like version etc.)
The output of the command "Version" is:
Extension DLL chain:
dbghelp: image 6.2.9200.16384, API 6.1.6, built Sat Nov 20 12:57:48 2010
[path: C:\Windows\system32\dbghelp.dll]
ext: (Not loaded)
wow64exts: (Not loaded)
exts: (Not loaded)
uext: (Not loaded)
ntsdexts: (Not loaded)
It says that no extensions were loaded, but the folder winext does exist in my system32 folder (C:\Windows\System32\winext), where the extensions are located in (as far as I know).
Commands like !gle do not work :/
I really have no Idea what I can do, please help me :)
Does the DBGTOOLS definition in your IDA.CFG point to the x86 WinDBG installation directory?
The following comes from IDA Pro's help:
Windbg debugger plugin has the following configuration options:
- The Debugging Tools folder: This should be configured to point to the same
folder where Microsoft Debugging Tools are installed. The plugin will try to
guess where the tools are, but if it fails, a manual intervention will be
required. If this option is not set, then the plugin will try to use dbgeng.dll
from MS Windows system folder, while normal debug operations will work,
extensions will not.
This information indicates that if IDA Pro is using dbgeng.dll from the Windows system folder, the extensions command (like !gle) will not work.
If you have already setup the DBGTOOLS to point to your WinDbg (x86 version) directory correctly in your /cfg/ida.cfg but IDA Pro is still using dbgeng.dll from your Windows system folder, then probably your IDA context is not configured to analyze the IBM PC processor. This may happen when you launch IDA Pro and click the 'Go' button directly to work on your own and start the WinDbg debugger.
Check the DBGTOOLS in the ida.cfg, you will find it is wrapped by #ifdef __PC__ #endif.
The __PC__ will only gets defined by IDA Pro if you are analyzing a Windows EXE file for example. Give a try to launch the WinDbg from the IDA Pro menu after you have successfully disassembled a Windows EXE file and see what happens.
If this still hasn't been answered your problem is most likely that you didn't uncomment the DBG Tools line in the ida.cfg file.
I just fixed this myself. hope this helps.
Also the other guys are correct as well. make sure you are escaping with double back slashes "\\" and make sure you pointing to the (x86) directory.
I have installed the new version of Windows debugging tools and I got a AdPlus.exe. I don't know if there are any changes but I remember when I installed it sometime ago on another computer, what i got was a ADPlus as vbscript file ( and not an executable). In the installation directory I still see there is a vbscript file but does any one know what is the difference between executable and vbscript. Thanks
According to this "what's new" article, they seem to be pretty much the same in that the vbs can still be used if you don't have .net framework 2.0 installed on the machine. That's not to say that there isn't something extra in the tool. You could find out by checking out adplus.doc in that same folder.
Any one knows how can I make an Installer Common for the both office 2003 / 2007 plugin.
Installer should automatically select the appropriate Office Version (2003/2007), depends on which Office is installed.
I'm using VS2008, Extensibility - Shared Addin, for my Office Plugin. I have 2 Projects for 2003 and 2007, I want to make a Common Installer for both.
is anybody has done similar thing prior ?
I need a deployment (msi) package such that user doesn't need to choose which version he needs to use.
Ive used this bat file command in the past to install the correct PIAs perhaps you can find it useful, if there is "HKLM\SOFTWARE\Microsoft\office\12.0\Excel" means that Office 2007 Excel is installed ect...
#Echo off
:BEGIN
CLS
reg query "HKLM\SOFTWARE\Microsoft\office\12.0\Excel" || GOTO INSTALL11
REM *************** INSTALLING OFFICE 12 PIA *****************************
%programfiles%\{InstallFolder}\O2007PIA.msi /passive
exit
:INSTALL11
reg query "HKLM\SOFTWARE\Microsoft\office\11.0\Excel" || GOTO INSTALLNOTHING
REM *************** INSTALLING OFFICE 11 PIA *****************************
%programfiles%\{InstallFolder}\O2003PIA.msi /passive
exit
:INSTALLNOTHING
REM ... Clean up left out for brevity
perhaps you could write a msi script that does the same.
The link below explains how to tell if Office XP is installed. I'm sure a similar page exists for all other recent versions of Microsoft Office. You can even filter by specific versions of Office XP.
http://office.microsoft.com/en-us/orkXP/HA011364611033.aspx
I used the "target the lowest common demoninator" strategy as explained here. It worked well for me.
That is quite easy.
within you msi you only need to search for the key paths of the office installations.
this key paths are documented by microsoft.
Office 2003 Keypath and Default Installation Settings workbooks
there are also documents for other office version.
maybe you can also use the find related products feature from installer in detect mode.
MSI Upgrade Table
after detecting the versions you need only an expression on the components/feature
We have a windows app and we were using Wise for deployment. Recently we switched to InstallAware and though it has some good points we are facing some issues. Can someone recommend another deployment and packaging app? We are a small company and we do not have a dedicated staff for packaging etc. Also our package includes SQL server express installation and we would love to have the simplicity of such includes as is in IA.
How about NSIS or InnoSetup? They're both widely used, and not that hard to use. (If you choose InnoSetup, also download ISTool, it's a lot easier than writing the script file manually.)
We've used NSIS several times, both for full regular desktop installers, and for small, silently installing patches. It's easy to write a basic installer, especially if you use HM NIS Edit which acts as a wizard and IDE for NSIS. Because it's scriptable, you'll be able to check if SQL Server Express is already installed - if not, it can be installed as part of your installer process.
I have never used anything but Windows Setup and the setup projects that come with Visual Studio. Do you have any unusual requirements that prevent you from doing that?
I assume your requirement as follows,
You are using wise package studio to create\customize the application to create MSI and these msi package will be deployed or installed to your environment.
My question is : How many desktops \laptops are their in your company (Infrastructure)
Solution to your question based on my assumption:
At present Admistudio is the best product to replace the Wise and you can use Installshield repackager to create or customize the applications.
Install anyware is used to customize the Dll files (Build and release method) and create custom actions in that build file and build it to MSI
Installshield Repackager is used to create MSI from Exe files and also customize existing MSI using transform file (no need to modify existing MSI instead we can create MST file to MSI and perform the customization to MST file and same file will be applied while deployment.)
Please let me know if you need further assistance.
I have always wondered about this. So many application setups have a zip file that you unzip, and in it are a bunch of files, among other things an exe and an msi. What is the difference? They are often even about the same size. I am never really sure which one to execute, sometimes I do the exe and sometimes the msi, and it usually works with either one. But does one of them do anything that the other doesn't do? And if not, isn't it kind of a waste having two files that does the same thing? Especially when thinking about download size, etc...
Not sure if this should be here or on ServerFault, or maybe neither, but I figured since developers usually are the ones creating setup files, then developers might know why this is like it is =)
In the case where you have both exe and the msi the exe is just a loader for the msi. If you have an installation supporting multiple languages then the exe applies a language transform (mst) on the msi before installing.
You can consider the exe as a wrapper around the msi. The msi file may or may not be given separately. The reason why people give the msi file too is to facilitate a group policy installation (in a Windows Active Directory infrastructure) as you can only push down installations of msi files and not exes.
The setup.exe is a wrapper for the MSI, but it is not only a wrapper.
The setup.exe can rely on a setup.ini to define parameters
The setup.exe checks for the Windows Installer (a MSI cannot be installed otherwise)
The setup.exe can check for frameworks, like the .NET framework. The developer can pick one of those defined in C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bootstrapper\Packages (for Visual Studio 2008). If it is lacking, it will try to download it from http://www.microsoft.com/
The setup.exe can be reconfigured with msistuff.exe
The actual installation is done in the MSI. As Prashast said, the exe is just a wrapper, but the reason for having the exe, is that an exe is allways possible to run. If the user do not have MS Installer installed on the computer, or his version of MS Installer is older than the version required by your installation, then the MSI file is not possible to run.
The exe provides automatic installation of MS Installer (including some question to the user if he/she wants to do this) before running the MSI file. In most cases, the install packages needed for Microsoft Installer is included inside the setup.exe, or sometimes it is just the prerequisites check with a link to download the installation from Microsoft.
In very basic words,
you can deliver just the .msi file and it will install. but .exe will not work without the .msi