I'm using a custom dialog in a wixsharp setup console application project.
I've referenced 2 assemblies that I want to use in the custom dialog.
Whenever the dialog is loaded it tries to load the assemblies but fails.
An error that the files are not found is given.
Is it even possible to load custom assemblies in a custom dialog and how should this be done?
I believe that the EmbeddedAssembly class is what you need to use. It embeds the assembly directly into the MSI file specifically for use in custom actions.
Related
Using Registration-free WinRT it is possible to load WinRT components inside Win32 application.
What's the process to load WinRT component from inside Win32 dll? I tried the steps mentioned as part of Win32, but winmd files are not generating the corresponding header files.
Main usage scenario is dll can be loaded any application, like electron node addon or c# app etc.,
Without any changes to application, dll by itself should be able to consume WinRT component!
Did you add a reference to the WinMD file in the vcxproj and then installed the C++/WinRT NuGet package? This should make it generate the corresponding header files that your DLL project can then consume.
Following is the solution:
Was able to fix this in weird manner i.e. not a standard way to solve this.
Our use case was to use FFmpegInteropX inside win32 dll, so that we can use ffmpeg as a source reader and use the underlying hardware decode support. Mechanism is discussed detailly in the following link:
https://github.com/ffmpeginteropx/FFmpegInteropX/discussions/275#discussioncomment-3091100
Following changes were done to use WinRT component inside a Win32 dll:
Copied the WinRT generated files from the application to Win32 dll project
Before invoking any of the api from the generated runtime class, did LoadLibrary of the specific WinRT component into the dll
Now the make the necessary WinRT component call as it was done in standard win32 application
All modules were working as expected.
Above solution was copied from:
https://learn.microsoft.com/en-us/answers/questions/924996/how-to-consume-winrt-component-inside-win32-dll-pr.html
It's not a straight forward solution, also not sure if MS has any plans to add support for WinRT component inside dll project, if such support comes up then this may not be needed.
I have a web api that handles device connected to COM port.
I created simple installer using isWix that just copies builded app to location specified in installer window. How to add next step where it searches all COM ports that are used and gives user select box to specify where device is connected? I want to change appsettings.json file (one of files that are copied to instalation destination) so it has name of port selected by user.
I'm not sure how isWix is related to Wix. I think that it's a tool that just automatically creates wix project? I can use only Wix if it is not possible or it is just simpler than using isWix.
IsWiX has project templates and graphical designers to accelerate WiX development. There is nothing in it that solves this specific problem other then by uncommenting one line of XML injects a custom dialog. On this dialog you could then author a combobox. You'd need to write a custom action to populate a temporary table to have the list of COM ports and other custom actions to update the JSON file with the value selected by the user.
Is there any way this functionality can be shifted to first run of your application? It would greatly simplify the installer design.
I added references to telerik dlls in the code, with copy local set to true. But, when I am building the project I am receiving an error randomly.
Error1Unknown build error, 'Cannot resolve dependency to assembly 'Telerik.OpenAccess, Version=2015.1.220.1, Culture=neutral, PublicKeyToken=7ce17eeaf1d59342' because it has not been preloaded. When using the ReflectionOnly APIs, dependent assemblies must be pre-loaded or loaded on demand through the ReflectionOnlyAssemblyResolve event.' C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.WinFx.targets2689SMS
I am not using openaccess assembly at all. I have no idea why this keeps coming randomly. I am not even able to find the dll anywhere to add it to the project.
I was trying to use the telerik controls by dropping them to designer from the toolbox (just like typical asp.net controls). Somehow in that case, it was referencing the path of the installation folder (C:\ProgramFiles...). That's why it was failing on different PCs wherever the installation path changed (like telerik 2.0.2 instead of telerik 2.1.2).
So, I copied all the dlls from installation path, uninstalled telerik completely. Then I copied the required dll to bin folder and referenced it in solution from there.
I've created a custom managed bootstrapper in WPF using Wix 3.7. I used an existing XAML themes library to create the bootstrapper UI. I added the same themes library as a payload in the bootstrapper wxs file.
The problem is themes are getting applied during the design time but on running the bootstrapper's .exe file the themes are not getting applied.
Can some one tell me why it is happening?
You'll want to follow up with the implementation of the library to understand how the themes are loaded. Often, those types of libraries make assumptions that the files will be relative to the executable. Because the Burn engine is a native host those assumptions are incorrect. Instead, the library needs to load the themes relative to the current executing assembly.
I'm setting the Isolated COM project settings in a C++ VS2005 project to load an ocx component using the Registration-Free Activation method. If the ocx component is also used in a DLL library my application loads, do I need to set the Isolated COM settings in that DLL project's settings as well? Or would setting only the main application's embedded manifest be sufficient? Thanks!
As I understand it, isolation is per-process, not per-module. So, anything in the application's manifest applies to any process started from that application.
Think of what CoCreateInstance needs to do to support reg-free COM -- it needs to find a manifest file somehow and if it's present, not go to the registry for activation information.
Since there is no argument to CoCreateInstance telling it the path of the manifest, it needs to derive it from context.
There is no real context for a .DLL, but for an .EXE the current process handle can be used to derive the path of the executable, etc., so I suspect that's how they do it.