Software Deployment

ProcMon - or your favoured process/file/registry monitor - will show you exactly what's going on right before the crash. My bet is that the add-in is trying to write to an HKLM value to which the launching user has no permissions.

Thanks for the reply VBScab,

I didn't mention the fact thst in my original post but I have used ProcMon already with no success. I was also testing the app with an admin user.

I was hoping someone may have had some success re-packaging the application as it appears to run some custom executables to register dlls.

I have used ProcMon already with no successThen, with the greatest of respect, you're not using it correctly. I haven't yet found ProcMon wanting when trouble-shooting this kind of thing.

I would also suggest doing a Gap-Capture using Installrite or picturetaker tool for this prob..Follow these steps:
1. Install ur packaged app on ur test machine.
2. Replicate ur problem.
3. THen run installrite/picturetaker's first scan on ur machine.
4. Install the source on top of ur application
5. Check if ur application works now( has to work as u r installing the source)
6. Run installrite/picturetaker's second scan.
Incorporate the changes occured in ur app... THis ideally has to fix ur prob

Regards,
Harie

@VBScab - Thanks again for the kind words but I have had many years of experience using ProcMon and this is the first time he's failed me.

@hari.ram - I've already tried this method. I have also copied the before and after HKCR and HKLM registry settings and used Beyond Compare to analyze the differences.

Hate to dig this up from the grave yard, but I just wanted to post a solution that worked for me to fix the same issue the original poster was having. It would seem that there is a bunch of pre-reqs under the "<SASDEPOT>\products\sysreqwizard__92400__prt__xx__sp0__1" directory. If you run the pre-req wizard, then it'll scan the PC and install all the pre-reqs. I installed all the pre-reqs and now my captured SAS Office Addin v4.3 works without issues!

ORIGINAL: Crazy8

Hey Guys,

Long time reader first time poster...

So I've been attempting to capture the SAS Office Add-in for a couple of weeks and have had no luck. Each time I launch excel it crashes almost straight away. Has anyone had any luck re-packaging this annoying office add-in?

Crazy8

in addition to what ian (vbscab) and others said, do an installation using the vendor media. does excel crash? if so it's a bug in the plug in and you can't fix it during install.
and iirc office apps do leave log files after a crash, do a google or search microsoft.

@aogilmor: The vendor media works as expected, that's why I've decided to just use the InstallShield silent install. However I'll try my msi again and check what the office log file has to offer.

Regarding ProcMon, I noticed that excel/word was writing to a *_appcompat.log file in the temp directory. So i checked what this file had to say. It mentioned that the main add-in loader failed but nothing further. I tried registering this file, SAS.OfficeAddin.Loader.dll, with regsvr32 and regasm.exe but the add-in still caused an error.

RegSvr32 has no understanding of .Net assemblies so using it against such files is pointless.

Did you install the vendor source files and the MSI on the same build? I would like to recount of an application (that installed addins) that crashed excel when installed on a build with Hyperion Essbase. Check out on a clean machine with only Microsoft Office installed?

so it's installshield eh? is it an msi based intall, i.e. is there an msi in the temp directory when you run the installation? if so try working with that rather than snapshotting. snapshotting sux...too easy to miss things. i agree with ian don't try regsvr32 or registering assemblies manually, not a good idea.

SAS's installer leaves a lot to be desired when it comes to silently installing (at least that's true with the Analytics Pro package I just finished).

If you're using Wise to snap, it has a nasty habit of ignoring any INI files which SAS packages usually have a quite a few. That, and SAS packages tend to require a certain directory set in the PATH in order to work.

@VBScab: I noticed in a log file that the vendor install ran regsvr32 on a few dll files.

@jinxngoblins: I was testing and capturing the application on a clean build of our SOE.

@aogilmor: Yep, it's installshield (Grrr) and so have searched everywhere for the msi.

@icbrkr: SAS's silent install for the Office Add-in wasn't too messy, the uninstall was quite lacklustre though. When snapping the application I used a combination of Wise and InstallWatchPro and ProcMon. The PATH directory was one of the first things I noticed too.

@VBScab: I noticed in a log file that the vendor install ran regsvr32 on a few dll files. I'll bet they weren't .Net assemblies, though. Even so, the use of RegSvr32 to register DLLs merely points up the vendor's packaging incompetence (now, there's a surprise...) Only a buffoon would do COM registration that way. Search this forum for 'RegSvr32' or 'COM' for details.