Closed kipamgs closed 1 month ago
morning, really intresting one. Am i right, if i think, you want to extract zip from msi to dest dir? If so, your zip has to be binary and embeded ressource in project. CA for ExtractZip is ElevatedAction, but why you use it ? If you use Before or AfterInstall event, is automatically elevated.
i had same issue for extracting file.
public static bool ExtractFile(SetupEventArgs e)
{
try
{
// Get the path to the temporary folder
string tempPath = Path.GetTempPath();
string targetFilePath = Path.Combine(tempPath, "<your_file>");
if (System.IO.File.Exists(targetFilePath) == true)
{
System.IO.File.Delete(targetFilePath);
}
// Get the current assembly (your custom action DLL)
var assembly = System.Reflection.Assembly.GetExecutingAssembly();
// Extract the Embeded file from the embedded resources
using (Stream stream = assembly.GetManifestResourceStream("<YourNamespace>.Resources.<your_file>"))
{
if (stream == null)
{
throw new FileNotFoundException("Embedded resource not found.");
}
using (var fileStream = new FileStream(targetFilePath, FileMode.Create, FileAccess.Write))
{
stream.CopyTo(fileStream);
}
}
e.Session.Log($"XML file extracted to: {targetFilePath}");
return true;
}
catch (Exception ex)
{
e.Session.Log($"Error in ExtractFile: {ex.Message}");
e.ManagedUI.Shell.ErrorDetected = true;
return false;
}
}
you could try it. For me it works, i also tested it as zip, rar and exe.
@Torchok19081986, you can also use that alternative approach that I shared with you a few days ago. The one that avoids using resources. Even though there is nothing wrong with that using resources.
https://github.com/oleg-shilo/wixsharp/issues/1645#issuecomment-2381258983
For testing and to keep it simple i just created a custom action that creates an empty txt file. It works for a 32 bit installation but as soon as i set it to 64 bit the installation waits for the timeout of the custom action and then fails.
The issue is also reproducible wiht an empty custom action. It also happens for ManagedAction if they are executed deffered. The only difference is that there seems to be no timeout for ManagedAction.
It's unlikely the problem is caused by the configuration (x64 vs x86). Most likely it's all about what you do in your custom action.
Put an exception handler there and log the error. You can debug it - even better. Most likely you will see that the timeout is caused by your custom routine but not by the CA itself.
Debugging seems to work. You just need to ensure your debugger is elevated and you attach to the correct process (rundll32.exe):
I also checked the DTF_(ManagedCA) sample for debugging. It's also OK. So maybe first try and see that you can debug the sample. Just add this to the sample code:
As a side note, I prefer to use events (e.g., project.AfterInstall
), which is just easier to work with.
And AfterInstall event is nothing else but a deferred ManagedAction. And being deferred is what makes a CA to be elevated.
I had to edit my .csproj file. I had to remove the line <RuntimeIdentifier>win-x86</RuntimeIdentifier>
.
If I understand it correctly this caused a mismatch of 32 and 64 bit between the installer and the custom action.
WixSharp-wix4.WPF 2.4.0.1
When I create a project (Custom WPF UI Wix4) with an ElevatedManagedAction and add
project.Platform = Platform.x64;
the installation fails. The custom action is not executed.Part of the installation log:
Full installation log:
MyInstaller.zip