Installer: Fix problem with missing Office libs in latest version

[aspettl]

When I build the installer locally, the produced artifact does not work: it complains about missing Microsoft.Office.Interop.PowerPoint. I checked with the latest release, actually I have the same problem there (when I uninstall WordsLive and reinstall it). Previously I did not have the issue, maybe because I only upgraded WordsLive. However, I'm a bit confused because earlier versions of WordsLive do not install that DLL as far as I can see, so not sure why I did not have problems earlier.

With the changes in this PR it works for me, but please have a closer look.

[aspettl]

I think I need to try again on a clean Windows without any Office installed. So far, I had this problem after installing WordsLive 0.9.22 at least once, but now I don't. Maybe it has to do with Office itself and its activation status (which my Office lost recently due to some imaginary hardware change... - but I won't deactivate it now for testing).

[aspettl]

Ok, here the update:

When I install WordsLive 0.9.22 on a system where there is no Office, then I get the following when I add a song to the portfolio:

System.TypeInitializationException: Der Typeninitialisierer für "WordsLive.Slideshow.Presentation.SlideshowPresentationFactory" hat eine Ausnahme verursacht. ---> System.Reflection.TargetInvocationException: Ein Aufrufziel hat einen Ausnahmefehler verursacht. ---> System.IO.FileNotFoundException: Die Datei oder Assembly "Microsoft.Office.Interop.PowerPoint, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" oder eine Abhängigkeit davon wurde nicht gefunden. Das System kann die angegebene Datei nicht finden.
   bei WordsLive.Slideshow.Powerpoint.Bridge.PowerpointPresentation.CheckAvailability()
   --- Ende der internen Ausnahmestapelüberwachung ---
   bei System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor)
   bei System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(Object obj, Object[] parameters, Object[] arguments)
   bei System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
   bei System.Reflection.MethodBase.Invoke(Object obj, Object[] parameters)
   bei WordsLive.Slideshow.Presentation.SlideshowPresentationFactory.TryLoadPowerpointBridge()
   bei WordsLive.Slideshow.Presentation.SlideshowPresentationFactory..cctor()
   --- Ende der internen Ausnahmestapelüberwachung ---
   bei WordsLive.Slideshow.Presentation.SlideshowPresentationFactory.IsTargetAvailable(SlideshowPresentationTarget target)
   bei WordsLive.Slideshow.PowerpointHandler.Test(Uri uri)
   bei WordsLive.Core.MediaManager.LoadMediaMetadata(Uri uri, Dictionary`2 options)
   bei WordsLive.MainWindow.AddToPortfolio(Uri uri)
   bei WordsLive.Controller.AddToPortfolio(Uri uri)
   bei WordsLive.Songs.SongListWindow.AddToPortfolio(SongData data)
   bei WordsLive.Songs.SongListWindow.<OnExecuteCommand>d__17.MoveNext()
--- Ende der Stapelüberwachung vom vorhergehenden Ort, an dem die Ausnahme ausgelöst wurde ---
   bei System.Runtime.CompilerServices.AsyncMethodBuilderCore.<>c.<ThrowAsync>b__6_0(Object state)
   bei System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
   bei System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)

With the older 0.9.21 the same procedure works fine.

[Boddlnagg]

Hm, do you have any idea which change in 0.9.22 might have caused this? I'm puzzled ...
But assuming it's okay to redistribute the Office Interop assemblies, your PR looks fine.

[Boddlnagg]

Between 0.9.21 and 0.9.22 the NuGet packages (which include Office Interop assemblies) were migrated from the old packages.config format to the new PackageReference format. But the version stayed the same, and the installer also didn't change in that regard.

[aspettl]

I think I found the reason for this issue. It has to do with the switch to PackageReference - and unfortunately I think it is not yet possible to achieve the same thing as before with package.config.

https://learn.microsoft.com/en-us/visualstudio/vsto/how-to-install-office-primary-interop-assemblies?view=vs-2022 says that primary interop assemblies (PIAs) are embedded by default. So that is why we did not have those files in the old version and everything worked. But with PackageReference, this changed - it is a reference now, so not linked.

Futher information:

• https://www.hanselman.com/blog/clr-and-dlr-and-bcl-oh-my-whirlwind-tour-around-net-4-and-visual-studio-2010-beta-1
• https://github.com/NuGet/Home/wiki/Embed-Interop-Types-with-PackageReference (when I understand that correctly, the interop package author needs to adjust the package so that it can work with PackageReference)
• Enable EmbedInteropTypes for PackageReference (matching Packages.Config capability) NuGet/Home#2365 (issue is closed, but looking at PackageReference to embeddable interop package *references* the assembly instead of *linking* it NuGet/Home#10188 I'm not sure what the actual state of the feature is)

Redistribution of the files: Microsoft provides these DLLs so that parts of them (basically just types/bindings) can be embedded into the end-user application. So I would assume copyright/licensing is not a real issue in practice. But unfortunately I also do not see a clear "allowed to distribute".