madebits.com
. N E T Z
.NETZ - Troubleshooting
<<<

  .netz
  usage
  download
  limitations
  compression
  readings
  support
  main






Software videos
Latest software videos!



Basics | Intermediate | Advanced | Troubleshooting

Troubleshooting

  Troubleshooting

.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.

  NETZ Warnings List

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:


netz app.exe -i app.ico

^ 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:


netz -c app.exe

^ 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.

^ top

Previous: << Advanced

Troubleshooting




Latest news by Google

madebits.com
home | legal | search | contact | top

©2005-2008