Troubleshooting
.NETZ issues (a) errors and warnings during packing and (b) a run-time message box (error message in command-line apps) if the packed application fails to start.
At pack time, .NETZ can issue errors and warnings if something goes wrong:
- The errors are issued when something critical happens, for example, an input file passed to .NETZ is missing, or a compilation error happens. Most the errors result from wrong input passed to .NETZ by the user and can be prevented by reading the on-line help. Other errors, such as compilation ones may reflect internal .NETZ problems (if any) and should be reported.
- The warnings issued by .NETZ are also very important. They usually show failure of pre-conditions that must hold for the .NET assemblies, so that they could be packed by .NETZ. .NETZ warnings are numbered for easy reference. This section lists all current .NETZ warnings, explaining the ones that can safely ignored, and the ones that are usually important to be ignored. Workarounds are provided when possible.
Append the -v option to your .NETZ command-line to get a stack trace of the error, or more information about an warning. For more information see: How to Report an Error.
Warning 1001 - Cannot process assembly metadata
The .NET runtime version used to compile a given EXE/DLL is not supported (version mismatch), or the file is not a .NET assembly. For workarounds in the case of wrong .NET version, see Handling New/Different .NET Versions.
^ top
Warning 1002 - Icon
The EXE icon resource of the EXE cannot be found. Most of the time this means that there is really no icon in the EXE and this warning can be safely ignored. It is usually reported for console EXEs. If the EXE has really an icon, but .NETZ cannot find it, then as a workaround you can specify an icon with the -i option:
^ top
Warning 1003 - Unhandled main assembly attribute
.NETZ handles some common EXE assembly attributes, but not all. Most of the time it makes no sense to copy and attribute of the original assembly (which is still preserved unchanged, and it is run as such), to the wrapper assembly. However, depending on the use case, some attributes of the original assembly may need to be repeated also to the wrapper assembly. If you see this warning, then decide if you really need to copy these attributes. Most of the time, you do not need to copy them, or do anything. If you really need to copy them, there are several ways to do so, as explained in EXE Assembly Attributes.
^ top
Warning 1004 - Cannot determine EXE's subsystem
.NETZ can handle Windows desktop console and GUI .NET applications. .NETZ can detect the EXE subsystem and properly generate an appropriate wrapper. If you try to pack other types of EXE with .NETZ, you will get this warning. If you see it, then the packed application is likely not to run, because this type of EXE is not supported by .NETZ.
To overwrite the .NETZ auto detect use the -c option for CUI, or the -w option for GUI subsystem. For example, if app.exe is a console application then use the -c option:
^ top
Warning 1005 - Cannot process assembly license information
See Licensed Components and Controls. If some error happens during processing the assembly license information, this warning is shown. It could also be related to Warning 1001. See also: Handling New / Different .NET Versions.
^ top
Warning 1006 - Assembly load test failed
.NETZ tests an assembly if it can be loaded dynamically at run-time, using the same method the .NETZ packed EXE uses at run-time. If the test fails, warning 1006 is reported. The warning means that assembly cannot be packed with .NETZ, even thought it could be a valid .NET assembly. Most of the time this is the case with .NET managed C++ assemblies. There are usually two types of errors that you may encounter, reported as part of this warning:
- System.BadImageFormatException - If you using a .NET managed C++ assembly then you can try to compile it using the /link /fixed:no option of cl.exe, but it could still fail with the next type of exception.
- System.IO.FileLoadException - The main reason for this exception is a .NET managed C++ assembly optimized for direct execution by the C++ linker. There is no workaround for this at the moment. Other causes can be that the System. Security. Policy. Evidence information supplied by the assembly is not enough to allow the run-time to load it. This type of error is less likely to happen with .NETZ packed binaries.
To get more details about an warning use the -v option.
See also: Known Limitations.
E01: Unhandled Application Exceptions
The following application fails when executed. In not packed with .NETz, the default system failure dialog box will show (it may look different).
using System;
using System.Windows.Forms;
class MyForm : Form {
public MyForm() {
throw new Exception();
}
}
class FailingApp {
public static void Main(string[] args) {
Application.Run(new MyForm());
}
}
If this application is packed with .NETZ and executed, an error dialog will show (for console EXEs similar information is printed in stdout). The part marked in red shows the application error part.
To avoid seeing such crash dialogs, put the code inside your Main into a try/catch block and you show custom crash dialog
.
class FailingApp {
public static void Main(string[] args) {
try {
Application.Run(new MyForm());
} catch(Exception ex)
{ MessageBox.Show(null, ex.Message, "Error"); }
catch
{ MessageBox.Show(null, "Application error!", "Error"); }
}
}
The .NETZ error dialog shows also information about the .NET run-time used to pack the application and the one used to run it. This can be important for the next problem.
E02: .NET Run-Time Version Mismatch
This screenshot reported by a user, shows an error that has resulted from packing a NET 1.1 application that uses a .NET 1.1 specific class System. Windows. Forms. FolderBrowserDialog, against the .NET 1.0 ( with a .NETZ version compiled for .NET 1.0).
For more information see Handling New / Different .NET Versions.
E03: Wrong Assumption Errors
The following code when executed for a single assembly EXE, returns the path of the EXE in asm.Location:
Assembly asm = Assembly.GetExecutingAssembly();
FileVersionInfo fileInfo =
FileVersionInfo.GetVersionInfo(asm.Location);
When packed with .NETZ, there is more than one assembly in the EXE and a packed asm.Location returns an empty string. This causes FileVersionInfo. GetVersionInfo to throw an exception, that is not thrown from the original EXE.
In this case, the application made the assumption that asm.Location returns always the EXE path, which is not true. If left unhandled, such code gives out at best case E01 errors (see above).
In this particular example, the following code does not make this assuption and is thus more resistent:
FileVersionInfo.GetVersionInfo(Application.ExecutablePath);
There is not magic way to solve such wrong assumption errors, but proper try/catch with error reporting helps to find them.
^ top
