On Friday, 9 December 2016 at 17:05:24 UTC, Kagamin wrote:
> On Friday, 9 December 2016 at 16:47:18 UTC, Jesse Phillips wrote:
>> An MSI can't execute an arbitrary executable, just an arbitrary DLL which could run an arbitrary executable :)
>
> https://msdn.microsoft.com/en-us/library/windows/desktop/aa368563%28v=vs.85%29.aspx this?

Thanks, prove me wrong :)

I suppose you'd use the DLL because it has access to the MSI database during installation while the EXE won't.

I'm doing it because I'm replacing a 3rd party DLL and want to make sure the custom action is called correctly by our installer.

On Thursday, 8 December 2016 at 02:06:30 UTC, Brad Anderson wrote:
> On Monday, 5 December 2016 at 19:33:33 UTC, Jim Hewes wrote:
>> On 12/5/2016 3:19 AM, Kjartan F. Kvamme wrote:
>>> On Monday, 5 December 2016 at 09:24:59 UTC, Basile B. wrote:
>>>> How about a bounty for a new windows installer using inno setup ?
>>>>
>>>> There are several issues related to the nsis-based windows installer
>>>> (even on bugzilla). The problem that happened last Fall with a virus
>>>> false detection may happen again. "Braddr" proposed to handle digital
>>>> signatures in case it would involve payment.
>>>>
>>>> Programming an installer is a small job but it has a long term impact
>>>> on the user experience. Worth 100€ imo.
>>>
>>> Any particular reason to use Inno Setup over for example Wix Toolset?
>>
>> <Delurk>
>> In my last job I worked on installers (which I didn't like but someone had to do it.) I recommend WiX over Inno. The main reason is that WiX produces an MSI and Inno doesn't. An MSI is just a data file, not an executable, and is thus better for security. I normally wrapped the MSI in a bootstrap exe. But we had one customer that was part of the government and wouldn't accept anything but an MSI.
>> If you want, you can generate the XML with a program. I just didn't because I figured it was easier to modify if you can directly see the XML. My install builder was actually a combination of C# and WiX. I never found scripts to be flexible enough and it's just one more language to know.
>>
>> Jim
>> </Delurk>
>
> Yes, if DMD is going to switch the installer to something else it should be MSI. It's the official way to create installers on Windows and IT departments prefer it. Just switching to another installer executable generator is a lateral step, rather than a step forward.
>
> Microsoft seems to be wanting to quietly deprecate MSIs too and are increasingly not using them for their own products (likely to push people to the Windows Store). I'm not sure if the Windows Store is suitable for DMD though and adapting DMD to it would probably involve quite a bit of work and would likely involves legal agreements with Microsoft that only the D Foundation could make.

The "Desktop Bridge"<https://developer.microsoft.com/en-us/windows/bridges/desktop> in Windows 10 lets Win32 apps become Appx packages and work like universal apps. It's really geared toward GUI apps, though, with traditional activation mechanisms (shortcuts, file type associations, protocols).

Building a new MSI installer with WiX for DMD itself is pretty straightforward. MSI and WiX support almost everything but you'd need install-time code for:

  * _ReplaceInFile replacement
  * UCRT manipulation in SDK searches

What's not straightforward is the "extras": Visual D, DMC, D1, Visual Studio. Usually, that kind of thing is handled in WiX with a bundle but that doesn't fit this pattern well, because the expectation is that you're handed off to the other installer. And order matters, because you need to get VS installed first to get the detection right but Visual D expects to come after the DMD installer.

It's not a hard problem, just one that doesn't really fit into the MSI model well.