-
Notifications
You must be signed in to change notification settings - Fork 176
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cannot build .net 8 example project #1574
Comments
I have checked and the sample in repo has a project structure problem but not the one that you described. |
Thank you for your fast response. I can't seem to build the sample zip you send me. I unpacked it, removed everything expect the csproj and the program.cs and ran the following commandline from a commandprompt in the folder: This produces the same error (log attached). Is there a link to a specific Wix version that needs to be configured / added? |
I notice there is a My Product.wxs in my root directory where there is an msi in yours. I made a dir listing after build (too big for upload), maybe that helps. |
From the log it's clear the CA dll is built successfully. So, you are failing to build the msi. Meaning that you most likely will have the same problem if you try to build trivial .NET Framework targeting WixSharp project. It seems that in your environment, you have problems with executing the wix.exe command (part of the VS project build). You can troubleshoot it by changing the build command to This batch file is all you need to build the msi. It has no dependency on either WixSharp or VS/MSBuild. YOu can use it to troubleshoot and see what is missing. Most likely some of the WiX tools. |
Nice option, that really helps! The resulting cmd doesn't work out of the box, I need to modify a couple of things:
I couldn't figure out how to influence wixsharp in such a way that it would generated correctly though. |
The content of your batch file is invalid. This empty string after echo off
C:\Users\user\.dotnet\tools\wix.exe build -sw1026 -sw1076 -sw1079 -sw1149 -ext "WixToolset.UI.wixext" "C:\Users\user\source\repos\WinFormsApp2\WinFormsApp2\My Product.wxs" -o "C:\Users\user\source\repos\WinFormsApp2\WinFormsApp2\My Product.msi" I think you might have a problem with the WixToolset.UI.wixext not being installed in your environment. You can check it by executing the following code that most likely returns null in your case: WixTools.FindWixExtensionDll("WixToolset.UI.wixext"); WixSharp does install the extension if it's not found. And I suspect for some reason it fails. If t is the case then you can install the extension manually: wix.exe extension add -g WixToolset.UI.wixext But I am still puzzled as to why WixSharp fails when it executes the very same shell command to install the extension. I will still cover the rest of your points...
Not sure I read it the same way. The link you shared only says the In your case you had to remove this element because you removed the extension from the wixi.exe command (your first bullet point).
Correct. This is the sample that I prepared for you to demonstrate that you can build the project, start MSI and get CA execution but not pollute your system with the installation. Thus, in the sample, I abort the installation after the CA execution is over. Normally you would only need the create the project form VS project template without this trick. |
Hi Oleg,
Once again, thank you for the fast response. I'll try it out once I return
to the office in a couple of weeks.
King regards,
David
Op za 6 jul 2024 13:05 schreef Oleg Shilo ***@***.***>:
… Removal of -ext "" as it seems as if this causes the wxs to be interpreted
as extension instead of a wxs file. I can also add a pathname to an
extension dll, as long as it's not empty it seems
The content of your batch file is invalid. This empty string after ""
needs to be the name of the extension. And this is the primary cause of all
the problems. Everything else is just symptoms. I would like to understand
why, in your environment, the same project generates a different output
(batch file). This is how the correct batch file looks like:
echo offC:\Users\user\.dotnet\tools\wix.exe build -sw1026 -sw1076 -sw1079 -sw1149 -ext "WixToolset.UI.wixext" "C:\Users\user\source\repos\WinFormsApp2\WinFormsApp2\My Product.wxs" -o "C:\Users\user\source\repos\WinFormsApp2\WinFormsApp2\My Product.msi"
I think you might have a problem with the WixToolset.UI.wixext not being
installed in your environment. You can check it by executing the following
code that most likely returns null in your case:
WixTools.FindWixExtensionDll("WixToolset.UI.wixext");
WixSharp does install the extension if it's not found. And I suspect for
some reason it fails. If t is the case then you can install the extension
manually:
wix.exe extension add -g WixToolset.UI.wixext
But I am still puzzled as to why WixSharp fails when it executes the very
same shell command to install the extension.
------------------------------
I will still cover the rest of your points...
Removal of as that seems to be a Wix3 element
Not sure I read it the same way. The link you shared only says the UIRef
is available since WiX3 and in WiX4 you will need to ensure using WiX
extensions. Even more. The very next section
<https://wixtoolset.org/docs/fourthree/faqs/#converting-custom-wixui-dialog-sets>
specifically show WiX4 example with the use of UIRef element.
In your case you had to remove this element because you removed the
extension from the wixi.exe command (your first bullet point).
Change the CustomAction2 result to be ActionResult.Success as otherwise
the installer never finishes successfully
Correct. This is the sample that I prepared for you to demonstrate that
you can build the project, start MSI and get CA execution but not pollute
your system with the installation. Thus, in the sample, I abort the
installation after the CA execution is over.
Normally you would only need the create the project form VS project
template without this trick.
—
Reply to this email directly, view it on GitHub
<#1574 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AUQEKABELYRQYIX4QUMSC4LZK7FORAVCNFSM6AAAAABKG6DXWCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMJRG4ZTSMJQHA>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
- #1580 Shortcut "Target" produces unexpected results for many supported WiX environment constants - #1574: Cannot build .net 8 example project (NET-Core) - #1546: dotnet tool install --global wix - Need for all users - #1585: Dotnet tool should not be relied on for wixsharp. Added error logging on `dotnet` or `wix` not found. - Added error log for failure to find WiX extension. Triggered by #1574, #1589 - Improved the documentation for `AutoElements` and `Compiler.AutoGeneration` (triggered by #1578) - #7591: added WiX5 Custom BA sample (`<wixsharp>\Source\src\WixSharp.Samples\Wix# Samples\Bootstrapper\WiX5-Spike\WixToolset.WixBA`) - added missing SilentBA for `WixSharp.Core` - fixed problem with `SetShellSize` not setting the top level window size
I was able to test the suggestion you send today, here are my results:
I understand this works by installing extensions, but I am wondering if it's possible to also support using this extension from a packagereference in the csproj. When I add to my csproj, the dll is available in the nuget folder without having to install anything. Would it be possible to add support to locate the dll there? Or am I missing an important part in how this Wix tooling and extensions works? In principal WixSharp could add the dependencies as package to itself if they are needed for building? Stacktrace for point 2, in case you need it: |
You are right. I overlooked that I just made it public so it will be available for troubleshooting. Now, about the extension package. However, the is a simple way to redirect the extension probing algorithm to the location of your choice (e.g. nuget dir). Thus you can install the nuget package by any means and then set WixTools.WixExtensionsDir =@"%userprofile%\.nuget\packages".ExpandEnvVars(); WixSharp will find the extension in a new location. The solution I described will work for any cases, even including bringing extensions manually without nuget. Though I like your idea about checking nuget packages by default so I will also extend the probing approach to check both wixextensions and nuget folders always. |
…ion is not install. The error will be reported by the WiX compiler
Done. |
- #1574: Cannot build .net 8 example project - #1587 Support for pulling in dlls for runtime dependencies - VSTemplates update. Added warning message about `project.GUID`. Triggered by #1597 Contributed by @fredemmott - Added errorhandling to continue extecution if WiX extension is not install. The error will still be reported by the WiX compiler - Added `Project.AddCastomActionRefAssembliesOf` to add CA referenced assemblies programmatically.
Thank you for the fast response, I'll test the new release once I have the chance! |
This is an example of the customization options: WixTools.SignTool = @"tools\signtool.exe";
WixTools.MakeSfxCA = @"tools\WixToolset.Dtf.MakeSfxCA.exe";
WixTools.Heat = @"tools\heat.exe";
WixTools.DtfWindowsInstaller = @"tools\WixToolset.Dtf.WindowsInstaller.dll";
WixTools.WixToolsetMbaCore = @"tools\WixToolset.Mba.Core.dll";
WixTools.SfxCAx64 = @"tools\x64\SfxCA.dll";
WixTools.SfxCAx86 = @"tools\x86\SfxCA.dll";
WixTools.WixExtensionsDir = @"%userprofile%\.nuget\packages"; |
I'm trying to build an installer project with .net 8. I'm following https://github.com/oleg-shilo/wixsharp/blob/wix-v4-master/Source/src/NET-Core/Sample/. It doesn't compile however, the error that occurs is:
0>wix.exe: Error WIX0144 : The extension 'C:\MyInstaller\My Product.wxs' could not be loaded because of the following reason: Could not load file or assembly 'C:\MyInstaller\My Product.wxs'. Format of the executable (.exe) or library (.dll) is invalid.
Please advice how to fix this. I'm trying to get it compiled with .net 8 to use it with AOT custom actions, but I'm already stuck with simply compiling it.
Thanks in advance.
My csproj:
My program.cs:
The text was updated successfully, but these errors were encountered: