Thread

Index > Scribe > Install failure with InScribe beta 39 in Win7
Author/Date Install failure with InScribe beta 39 in Win7
pseudocanuck
04/08/2012 10:05pm
Dear Fret,
Last year I posted the following:
"I tried to install beta36 over existing beta35, and got this message upon attempting to start InScribe:
Application failed to start because its side-by-side configuration is incorrect.
This happens whether I try to start from the desktop shortcut or start menu.
Full uninstall, including manual registry clean, followed by a registry clean utility, and reinstall, does not change anything."

The same thing has happened with every subsequent beta release I've tried to install.
In case it's relevant, I have installed to a folder on the desktop.

You responded:
"I built beta36 with a new compiler: Visual Studio 2005, and
so I probably haven't done something right in terms of
settings things up correctly for release in the installer.
I'll have to investigate the situation and get back to you."

It's been a while, and no one else has mentioned this problem, so I'm wondering if you have found out anything.

Thanks.
fret
05/08/2012 6:51am
Sorry I didn't get back with a solution. The problem is that Microsoft released a patch or service pack for visual studio that changed the default version of runtime library that programs link with. From a version that ships with windows to a version that doesn't ship with windows. So now users have to install extra libraries to make things work.

Or at least I have to make sure the right library is present in the users system.

There are a few different solutions to this:
1) I could force visual studio to link against the old version that is installed by default. The downside being I might be opening up the software to old bugs and security holes in the C runtime library (CRT).
2) I could detect the missing library and install it inside the Scribe installer. So far I haven't been able to detect that from within the NSIS installer script language, let alone download and install a 3rd party package. But I have tried.
3) I tell everyone up front that Scribe needs a library to be installed manually, and hope that users do the right things and install the dependency. That is clunky and not really my style but in any case the right CRT can be found here.
4) Bundle the CRT in the install and have it downloaded and installed every single time someone installs or upgrades Scribe. *sigh* A huge waste of bandwidth for everyone involved.

So I'd like to do "2" but I'm stuck trying to get the installer script to work how I want it to. :(
pseudocanuck
05/08/2012 7:59am
So then I have to install this exe you linked to before trying to install the update beta?
fret
06/08/2012 11:25am
So then I have to install this exe you linked to before trying to install the update beta?
Yes. Until I can get the installer to do that automatically that's what you'll have to do to use the current betas.

That setup exe installs the microsoft runtimes that are used by the current build of Scribe. They are part of the redistributable packages Microsoft provide with the Visual Studio compiler. You only have to do it once. Or at least until Microsoft change the default runtime version again.
pseudocanuck
07/08/2012 12:37am
The install works!

What else works:
Crashing when attempting to compact mail folders does not happen -- until after the mail is compacted.

What doesn't work:
It seems the mail may not actually get compacted, since the size of the Scribe folder is now even a little bigger than before.

I had had a problem with Delete Attachments in current folder not working. It's still unfunctional.

I found that somehow Scribe had relocated to my Inbox about 20 items that I had either previously deleted or moved to another folder. Some were about a year old. They were marked as unread. When clicking on these items, nothing showed in the view pane (understandable, since theoretically they don't exist in the Inbox, and they definitely don't exist on the web server). After deleting about 12 of these, Scribe crashed, sometimes without deleting the ones that were in process of deletion. It seems that a solution was to mark them read before attempting to delete.

I understand this is all beta. I can always just delete the desktop Scribe folder and copy over a backup of the previous build I was using, but will continue using build 39, since at this point there's nothing going on that is not easlly manageable.
Reply