[wix-users] Installation damaged by Windows update

[Christopher Painter]

That's why a wrote "a program you wrote".   Yes,   regfree wouldn't be an option  for built-in ActiveScript hosts such as  cscript, wscript or MSIExec (VB/JScript CA host).

Since you've already moved most of the logic into a .NET assembly that is marked ComVisible, what would be preventing you from creating another one to replace the remaining code.  That is, give it the same ProgID as the scriptlet.

If the code is that thin and really not changing at all, you could throw VB6 on a VM and dev/compile a replacement for it also.

________________________________
From: Helge Kruse <Helge.Kruse at gmx.net>
Sent: Sunday, February 10, 2019 3:43 AM
To: Christopher Painter; Blair Murri; WiX Toolset Users Mailing List
Subject: Re: [wix-users] Installation damaged by Windows update

Christoper and Blair,

many thanks for your input.

Yes it's an very old component, 15 years ago might the starting point
since we use it. It was a plain scripting component at the start. As the
logic got more complex it was implemented in a .NET assembly. But there
is still a thin shell around the assembly in this scriptlet.

The .WSC component is not there just for fun. There are tons of scripts
that instantiate it using "new ActiveXObject" and use the automation
interface to perform the operations.

We know about registration free COM and use it elsewhere. But it
requires that you have a client manifest along with the client.exe, and
the references the server manifest which itself includes the COM server
information. The problem is that the client .EXE file is the Windows
Scripting host (cscript.exe or wscript.exe). Here it's difficult to
place a client manifest, isn't it? Am I wrong, do you see a possibility
to use RegFreeCOM here?

The scriptlet instantiates the .NET object using
  <object id="cSharpFD" progid="FileDistributor.Wrapper"/>
and uses the cSharpFD object. The .NET assembly exposes a COM compatible
object. This is also registered in the registry. And it survives the
Windows update.

> I'm going to guess that MSFT doesn't want that component publicly
registered.
Do you have any hints where I can read more about this?

> Where did you find documentation specifying that it should be manually
registered for you to use?
There are several resources how to register .WSC scriptlets. e.g.
https://www.vbsedit.com/html/f5cd59db-46cf-4159-8cbc-4d6292f81d42.asp
There were also official Microsoft documentations when we started.
Nowadays it's hard to find the meanwhile hidden documentation like
https://docs.microsoft.com/en-us/previous-versions/zt97f40t(v%3dvs.80)
After the registration we detected the difference in the registry and
created the appropriate installer scripts to re-create the registration
with the installer.
I don't think that it would make a difference to run a custom active to
register the scriptlet. The Microsoft update would remove it anyway.

I am astonished that Microsoft throws some COM registrations for some(?)
scriptlets out, but still supports COM registration for others. Would it
be possible to change the WiX installation source to make it compatible
with the Microsoft rules for valid COM registration?

Best regards,
Helge


Am 09.02.2019 um 23:06 schrieb Christopher Painter:
> Wow what a blast from the past.  15 years?   There was a day before .NET that I thought scriptlets were cool.  Not so much these days.
>
> Not that I'm really encouraging this but if you want to create the COM object from a program you wrote you could add the  necessary registration to the manifest.
>
> https://docs.microsoft.com/en-us/previous-versions/dotnet/articles/ms973913(v=msdn.10)
>
> ________________________________
> From: Blair Murri <osito at live.com>
> Sent: Saturday, February 9, 2019 2:48 PM
> To: Christopher Painter; WiX Toolset Users Mailing List
> Cc: Helge Kruse; WiX Toolset Users Mailing List
> Subject: Re: [wix-users] Installation damaged by Windows update
>
> I'm going to guess that MSFT doesn't want that component publicly registered. Trying to search information about it on Microsoft's web domain, I found this discussion "fixing" the documentation (of that time: ~6 years ago) to create a typelib (which compiled code can easily use to access unregistered COM).
>
> Where did you find documentation specifying that it should be manually registered for you to use?
>