10 replies to this topic

[VBScab]

As part of my install, a couple of virtual directories are created. Now, for these, I normally just use the 'Web App' dialog and let Wise get on with it, thus I have no knowledge of what goes on "behind the scenes", as it were.

What we're seeing is a 1723 error (A required DLL could not be run...) and from the log, I can see that it's the VD creation bit that's failing. Last night, I did some digging and discovered that ALL the "File Name" entries in the Installation Expert's Project Definition/Resources pane were showing as "Unspecified", including the CustomAction responsible for the VD creation. Thinking I was on to a winner, I edited all of these to point to their correct locations, e.g. [WiseResourcePath]Stub\WiseAPI.DLL and so on. I compiled the MSI (note that no MSI has ever errored for these missing entries, so there's a HUGE bug, in my opinion!), ran it but got the same error.

Now, I imagine that when it runs, the MSI is *supposed* to copy the files referred to in the Resources list somewhere, I presumed beneath where it copied the local MSI e.g. %temp%\Stub. I searched the install target for them, but they're not present (but they ARE present on the compiling machine). So, do I have to add these files into the File table manually or *should* this be handled automatically by Wise?

Sorry to seem so thick but, as I say, for me this has always been a thing that just, well, works!

[Stefan Krueger]

Did you change the package code, and/or test this on a clean machine?

[VBScab]

This is on a clean machine, yes, so no code changes required.

How is that relevant, Stefan? 1723 means WI couldn't run the DLL. If it was having a problem creating the VD e.g. if it already existed, there'd be a different error, no?

[Stefan Krueger]

I suspected that it might be using a cached copy of your msi file from a previous test (where the DLL is missing).
Could you open your msi file with Orca to see if the DLL is really included?

[VBScab]

I *believe* that these Wise files get put into the Binary table so it's hard to know: all you see there is a CA name and [Binary Data]...

[Stefan Krueger]

You can export the binary data to a file. you can compare the exported file with the one from Wise.

[daylward]

I am having the exact same problem with my install. It gets error 1723 during the install, when it tries to create the virtual directory using WiseAPI.dll, and also during uninstall, when it tries to remove the virtual directory. I followed the suggestion above to export the binary field containing the DLL to a new file, and compared it with the original (using Windiff) and they were identical. The path for the source DLL is correct also.

The CustomAction table for this contains the following:

"RemWiseVirtDirCallDll5","3073","Callwiseapi","RemoveVirtualDir"
"WiseVirtDirCallDll5","3073","Callwiseapi8","CreateVirtualDir"

(note that the "Callwiseapi" and the "Callwiseapi8" both exist in the "binary" table, and they both point to the same DLL - I'm guessing I could get rid of one of these, but this is how the setup arrived on my plate, and it should work fine anyway...)

Any other ideas?

Thanks!

Dan

Edited by daylward, 16 December 2005 - 22:56.

[VBScab]

If you drop WiseAPI.DLL onto MS's Dependency Walker, you'll see that it has no such functions (i.e. RemoveVirtualDir and CreateVirtualDir) exported.

I have no idea what's going on, particularly after expunging all traces of the old set-up, re-doing the whole web site/VD/IIS app thing and *STILL* getting a 1723! That was no surprise, as the function call names were the same and therefore STILL don't exist in the DLL.

As I said, I just knocked up a VBS to do it and call it via a CA. The considerable bonus with that approach is that it works 100%...

If you want a copy of the script, you're welcome to it.

As an aside, I've raised a ticket with Altiris/Wise because we hit a similar problem on another site, where packagers were opening Wise v6 WSIs in v5 and compiling them. Wise was happy to do so, even though the v6 WSI was using v6-specific Wise API calls. My contention is that the software ought to be intelligent enough to look inside any DLL being called to check that it exports the functions being called AND that all the required parameters were being passed. As it is, Wise seems to simply ignore that, compiles to completion and produces an MSI which doesn't work. I am SO ready for them to come back and say that it's down to the packager to version-check because I can simply throw the above scenario back.

As an exercise today, I'm going to create a CA which calls a non-existent function in a DLL of my choice and see if it compiles. I have a fairly substantial wedge which says it will...

Edited by VBScab, 19 December 2005 - 10:23.

[mfw]

Hello all,
do you have defined the entry point for your dll-function like this:

#pragma comment(linker, "/EXPORT:YourFunction=_YourFunction@4")

I have had the same error, but with the pragma comment, it works fine.

cu mfw

[VBScab]

WHAT?!? This is all taking place in the Wise for Windows Installer MSI-creation environment.

In Wise, you select 'Web files', select the folders and files you want, indicate a VD and/or IIS application name (the UI is very like IIS's...) and Wise is supposed to do the rest. Unfortunately, it has the habit of, er, screwing it up completely.

What you can see, when you look at the MSI tables after doing the above, is that Wise sometimes changes the called function names to be the same as your Custom Action name or, more usually in my recent experience, uses a seemingly arbitary, but vaguely correct-looking name. For example, instead of 'CreateVirtualDirectories' which is the actual function name, we'll get 'CreateVirtualDir' or 'WiseCreateVDir'.

[daylward]

I looked at the WiseAPI.dll that came with Wise 6 in Dependency Walker, and you're right, those functions aren't there. But we had an old version of this setup, which was compiled in Wise 5.something, and it always worked fine. So I opened up the .msi file in the old setup, and exported the WiseAPI.dll from that. Guess what? The old version has CreateVirtualDir and RemoveVirtualDir functions in it! So for some reason when they upgraded to 6, they took these functions out! Was this on purpose, or is it a bug? If it is the former, what are we supposed do do instead? Just use a custom action VBS like VBSCab did? Either way, yes, that would be very handy to have a copy of your script! :-)

Thanks!

Dan