Hi Friedrich,
it seems, I have missunderstood the function "register all pending file
operations". Could you please clarify, under which circumstances I will
need this funtionality?
Thanks in advance.
Markus
Printable View
Hi Friedrich,
it seems, I have missunderstood the function "register all pending file
operations". Could you please clarify, under which circumstances I will
need this funtionality?
Thanks in advance.
Markus
Hi Markus,
> it seems, I have missunderstood the function "register all pending file
> operations". Could you please clarify, under which circumstances I will
> need this funtionality?
Let us assume, you install two (OCX) files that support self-registration
and you have the "Register as OCX/DLL/EXE/TLB" option enabled. The
self-registration process is not automatically executed after the file
installed. Instead, it is "queued" and at the end of the installation
process, the "Register all pending file operations" function will execute
the OCX self-registration process.
HTH,
Friedrich
Hi Friedrich,
thanks for your answer. But unfortunately, I have further question.
1.) I have no OCX-Files, just a few self-registering dlls. Is this relevant?
2.) your famous documentation (PDF) says on page 395 (408):
"Queued files are registered automatically at the end of the script."
Why do I need "register all pending file operations" at all?
I will tell you the reason, why I ask all this questions:
Sometimes, "register all pending file operations" causes my Setup to
hang, and I dpn't know why. After a reboot, you can install the
application succesfull. And with our old self-written setup, there was
never be a problem with registering our dlls. Even if one of our dlls
causes this problem, I have no chance to see, which dll it is.
Thanks for your reply and thanks for the new maintenance build. It
solves two major issues in our setup.
Markus
Hi Markus,
>
> 1.) I have no OCX-Files, just a few self-registering dlls. Is this
> relevant?
>
The self-registering OCX file was just an example for a pending file
operation. Pending file operations include self-registration files, shared
files registration, true type font registration, .NET file operations (e.g.
register the file in the GAC), and replace in-use file actions.
If no file operation is "pending", then the function is not executed at all.
BTW, the uninstall .log should display the "last" successful operation.
Perhaps this can help to find out what the next file operation might be.
Please note that the installer just executes the self-registration process
in self-registering DLLs. If the setup "hangs", then the DLL does not
return to the installer (means, there is a problem with the registration
procedure in the DLL).
Friedrich
Hi Friedrich,
thank you for your explanation. This was very helpful.
To know, which last action was successful is not very helpful. The more
interesting thing is, which action just has started.
Perhaps you can wrote this Information in line 2 of the progress bar
screen and ensure, that the repainting is done, before you start the action.
I think about lines like that:
Registering "special.dll"
Registering Font "MyFont.ttf"
Register replace file action for file "iwasinuse.exe"
Or do you see another way to determine, which action fails?
Because there was never a problem in the past, I can't guess which
action might be the evil.
This thing drives me crazy and is very problematic for our customers.
Thanks for your reply.
Markus
Hi Markus,
>
> This thing drives me crazy and is very problematic for our customers.
>
There is a /E command switch that creates a c:\sbevents.txt. This feature
will enhance in the future and I don't know if it covers pending file
operations yet. Could you please start your installer with the /E switch
(e.g. setup.exe /E) and send me the created sbevents? Perhaps this already
gives more information. If not. we'll add some more code so we can see
where it "hangs".
But as far as I know (I checked, re-checked and checked again the release
history), there was no modification in that runtime area.
Friedrich
Hi Friedrich,
I'm sure, it has nothing to do with your new release. I had this issue
already with SB 6.9, but since a few weeks, we ship our main product
with the SB-Setup too and the little problem grows faster as I wish...
I can't reproduce this problem every time and I can't tell every
customer, to start the setup with /e.
Is it possible (in an upcoming release), to activiate sbeventlog.txt
programatically and to set the path to the file and the filename?
Do you close or flush the file after every write access?
If no: How can I be sure, that last line I see in the file is the last
line sb has written?
Thank you, for your support.
Markus
Hi Markus,
> I'm sure, it has nothing to do with your new release. I had this issue
> already with SB 6.9, but since a few weeks, we ship our main product with
> the SB-Setup too and the little problem grows faster as I wish...
>
> I can't reproduce this problem every time and I can't tell every customer,
> to start the setup with /e.
>
> Is it possible (in an upcoming release), to activiate sbeventlog.txt
> programatically and to set the path to the file and the filename?
Yes, it should be possible to add an installer flag to always create the
sbevents.txt.
> Do you close or flush the file after every write access?
> If no: How can I be sure, that last line I see in the file is the last
> line sb has written?
The file is not closed but flushed and accessible, so you should see the
previously written item without any problem.
If it is a self-registering DLL and this process "hangs", then it's
definitely caused by the DLL itself because the call to "DllRegisterServer"
in the DLL never returns. The installer does nothing more (or less) than
calling the "DllRegisterServer" API. The DLL does all the registration
stuff and the installer can't continue until the DLL returns.
Friedrich
Hi Friedrich,
thank you. At the moment, I don't even know, wheter a dll causes the
problem or if there is another queued item, I don't think about.
I will wait until you have added the installer flag (and perhaps to set
the sbeventlog.txt-path too) in a developement build, than we will see,
what's going on.
Thanks again.
Markus
Hi Markus,
> thank you. At the moment, I don't even know, wheter a dll causes the
> problem or if there is another queued item, I don't think about.
Yes, you are right. Perhaps it's not caused by this self-registration DLL
scenario at all.
> I will wait until you have added the installer flag (and perhaps to set
> the sbeventlog.txt-path too) in a developement build, than we will see,
> what's going on.
We'll add some more "events" to the installer runtime to log all possible
pending file situations. This should provide us with more information.
Friedrich