ILMerge

Download details: ILMerge: "ILMerge is a utility for merging multiple .NET assemblies into a single .NET assembly. It works on executables and DLLs alike and comes with several options for controlling the processing and format of the output. See the accompanying documentation for details."

LibCheck

Download details: LibCheck: "This tool allows you to compare two versions of an assembly, and determine the differences. The tool reports the differences as a combination of 'removed' and 'added' APIs."

AutoStitch

AutoStitch

Autostitch :: a new dimension in automatic image stitching

Direct3D and math functions not working properly

I was working with some 3D geometry in C#. I found that before I created the DirectX device, all my calculations would work fine. The same calculations will not work, after creation of the DirectX device. It just did not make sense that (322460.391181 - 322460.195319) would be equal to 0.19586199999321 before creation of the directX device and after creation would be equal to 0.19586199522. A big change when it came to the kind of calculations I was doing. The eureka moment, when I realized that the after value was close to what I would get if I cast the original value to a float. Armed with that knowledge I googled to see if it was a bug. And the answer, no its not a bug, its an expected behavior. For more info, read the following info, which I got from Tom Miller's MSDN blog: Tom Miller's Blog : Direct3D and the FPU..: "Direct3D and the FPU.. I had an email this morning about Managed Direct3D 'breaking' the math functions in the CLR. The person who wrote discovered that this method: public void AssertMath() { double dMin = 0.54797677334988781; double dMax = 4.61816551621179; double dScale = 1/(dMax - dMin); double dNewMax = 1/dScale dMin; System.Diagnostics.Debug.Assert( dMax == dNewMax); } Behaved differently depending on whether or not a Direct3D device had been created. It worked before the device was created, and failed afterwords. Naturally, he assumed this was a bug, and was concerned. Since i've had to answer questions similar to this multiple times now, well that pretty much assures it needs it's own blog entry. The short of it is this is caused by the floating point unit (FPU). When a Direct3D device is created, the runtime will change the FPU to suit its needs (by default switch to single precision, the default for the CLR is double precision). This is done because it has better performance than double precision (naturally). Now, the code above works before the device is created because the CLR is running in double precision. Then you create a Direct3D device, the FPU is switched to single precision, and there are no longer enough digits of precision to accurately calculate the above code. Thus the 'failure'. Luckily, you can avoid all of this by simply telling Direct3D not to mess with the FPU at all. When creating the device you should use the CreateFlags.FpuPreserve flag to keep the CLR's double precision, and have your code functioning as you expect it."

iter.dk

Morten on GIS and .NET

Main interests are OGC standards, GPS and SOAP Webservices.

All projects are based on Microsoft’s .NET technologies.

PocketGpsLib - .NET Mapping Engine

PocketGpsLib - .NET Mapping Engine

The PocketGPSLib for your Pocket PC, makes it easy to implement a GPS receiver in your .NET Compact Framework applications. Written 100% in C#.

Supports RMC, GGA, GSA, GLL and GSV NMEA sentences. The library runs in it's own thread and is asyncronous / event based for easy implementation. Features full support for sending RTCM messages to the GPS device, making Differential GPS possible. PocketGpsLib is released under the GNU General Public License.

For more info and download visit http://gps.iter.dk

SharpMap engine - .NET Mapping Engine

SharpMap engine - .NET Mapping Engine

SharpMap is a simple-to-use map renderer that renders GIS vector, raster and WMS data for use in web and desktop applications.

The engine is written in C# and based on the .NET 2.0 framework. SharpMap is released under the GNU General Public License.

For more info and download visit http://sharpmap.iter.dk

GC, Dispose and Finalization

Excellent post on the GC, Dispose and Finalization http://www.bluebytesoftware.com/blog/PermaLink.aspx?guid=88e62cdf-5919-4ac7-bc33-20c06ae539ae

To Null or Not Null (Chris Lyon's Blog)

Another excellent post by Chris Lyons about the GC http://blogs.msdn.com/clyon/archive/2004/12/01/273144.aspx To Null or Not Null: GC Myth: setting an object's reference to null will force the GC to collect it right away.

GC Truth: setting an object's reference to null will sometimes allow the GC to collect it sooner.

As much as you may want to, you can't guarantee the GC will collect what you want, when you want it to. The best you can do is give it hints. The GC typically does collections when an allocation fails, not necessarily as soon as you're done with an object.

Consider the following method. What is the earliest point the GC could collect the Object that obj references?

void Foo() { Object obj = new Object(); Console.WriteLine(obj.ToString()); for (int i=0; i<10; i++) { Console.WriteLine(i); } obj = null; }

The answer depends on whether you've compiled it in Debug or Release mode. In Debug, the JIT extends all references' lifetimes to the end of their scope. This is so you don't have to worry about the GC cleaning up a variable you're trying to inspect!

In Release mode, the Object is actually first eligible for collection after the call to ToString(). The JIT is usually smart enough to realize that obj = null can be optimized away. That leaves obj.ToString() as the last reference to the object. So after the call to ToString(), the obj is no longer used and is removed as a GC Root. That leaves the Object in memory orphaned (no references pointing to it), making it eligible for collection. When the GC actually goes about collecting it, is another matter.

So when does setting a reference to null allow the object in memory to be reclaimed sooner?

Consider instance variables. Imagine a class that contains a large array of a managed type. There could be times where you no longer need that array, but you want the object to hang around. This is a good case for the Dispose pattern:

class BigObject : IDisposable { int[,] array = new int[1024,1024]; public void Dispose() { array = null; } }

Now the GC will clean up the array when it does its next collection, and you can keep that BigObject around for whatever reason, and not worry about it taking up so much memory.

Dispose Do's and Dont's from Chris Lyon's blog

from http://blogs.msdn.com/clyon/archive/2004/09/23/233464.aspx

• Dispose should contain code to release any unmanaged resources associated with the object's instance. For example, any handles should be released, database connections closed, etc. This simulates deterministic finalization by letting the developer do the resource cleanup when he/she is done with the object. You may want to use an IsDisposed bool and check it inside Dispose.
• Dispose should be safely callable multiple times. In my example above, if some user of your class called Dispose twice, we would crash with an unhandled InvalidOperationException trying to “double free” the GCHandle.
• If you inherit from an IDisposable object, call the base class' Dispose method. Unlike finalizers, which the GC calls, Dispose is only called by user code (sometimes automatically in C#, as I covered previously). This means any unmanaged resources held by your object's parent, must also be disposed of.
• Suppress finalization in Dispose. There has been some debate about whether GC.SuppressFinalization(this) should go before or after the cleanup code. Some argue after, in case something goes wrong before you've finished cleaning up. Others argue before, otherwise you may open up a race condition between your finalizer and your Dispose method. You should consider both strategies depending on your object's implementation.
• Don't throw exceptions in Dispose. Nothing should go wrong with your object calling Dispose. Mainly for reasons stated above.
• Throw ObjectDisposedException if a caller tries to use a released resource. You may be in a situation where you've disposed of your object because you no longer need the unmanaged resource, but you still need to have the object hanging around. If this is the case, any methods that would normally access the resource should throw an ObjectDisposedException, while other (possibly useful) methods should not.
• Don't call Dispose from one thread, while still using the object on another. Try to make the thread that created the object be the one that disposes of it. This is more general good multithreaded programming advice, then Dispose specific.
• Whenever possible, follow the Dispose Pattern. That link, one more time: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/cpconfinalizedispose.asp.