Archived
This forum has been archived. Please start a new discussion on GitHub.
Missing error messages in ICE v3.4.1.
Note: together, these bugs accounted for 4 of the 8 days of my learning curve (I've only encounterd ICE 8 days ago). If you fixed them, it would dramatically shorten the learning curve for practically every single person that attempts to use iceboxnet.exe with .NET.
Bug report #1:
With iceboxnet.exe, if you attempt to load a x32 assembly into it, it gives a generic "could not load assembly error". I spent 24 hours attempting to find the solution, which was to compile for "All CPU".
You need to add more error handling so that it gives a plain english reason for why the assembly didn't load. To determine whether an assembly is compiled for "x32" or "All CPU", see assemblies - How to determine if a .NET assembly was built for x86 or x64? - Stack Overflow which refers to a call to System.Assembly.
Bug report #2:
With iceboxnet.exe, if you attempt to load a .NET 4.0 assembly, it gives the generic error "could not load assembly", unless you configure iceboxnet.exe to run under .NET 4.0 by adding the following file "iceboxnet.exe.config" to the same directory as "iceboxnet.exe":
<?xml version=”1.0”?>
<configuration>
<startup>
<supportedRuntime version=”v4.0” />
</startup>
</configuration>
iceboxnet.exe needs to check the .NET version, and if its newer than itself, explain exactly why the error occurred.
I think you could also solve bugs #1 and #2 by implementing a ResolveEventHandler?
My guess is that every single person that uses .NET will be tripped up by one of these errors, and will be 100% stuck until either stumble across the solution by accident, or post to the forums. The reason is that iceboxnet.exe is inherently designed for servers, so everyone will be compiling under .NET 4.0 as they don't have to worry about client compatibility.
Bug report #1:
With iceboxnet.exe, if you attempt to load a x32 assembly into it, it gives a generic "could not load assembly error". I spent 24 hours attempting to find the solution, which was to compile for "All CPU".
You need to add more error handling so that it gives a plain english reason for why the assembly didn't load. To determine whether an assembly is compiled for "x32" or "All CPU", see assemblies - How to determine if a .NET assembly was built for x86 or x64? - Stack Overflow which refers to a call to System.Assembly.
Bug report #2:
With iceboxnet.exe, if you attempt to load a .NET 4.0 assembly, it gives the generic error "could not load assembly", unless you configure iceboxnet.exe to run under .NET 4.0 by adding the following file "iceboxnet.exe.config" to the same directory as "iceboxnet.exe":
<?xml version=”1.0”?>
<configuration>
<startup>
<supportedRuntime version=”v4.0” />
</startup>
</configuration>
iceboxnet.exe needs to check the .NET version, and if its newer than itself, explain exactly why the error occurred.
I think you could also solve bugs #1 and #2 by implementing a ResolveEventHandler?
My guess is that every single person that uses .NET will be tripped up by one of these errors, and will be 100% stuck until either stumble across the solution by accident, or post to the forums. The reason is that iceboxnet.exe is inherently designed for servers, so everyone will be compiling under .NET 4.0 as they don't have to worry about client compatibility.
0