Archive for the ‘EVEMon’ Category

Using EVEMon Data with LINQPad

Saturday, July 31st, 2010

LINQPad is an awesome aide to .NET Developers. Written by Joseph Albahari of LinqBridge and the C# In a Nutshell series fame. LINQPad allows the developer to write, compile and run C# or VB.NET Expressions, Statements of Programs outside of Visual Studio.

Everything I am going to show you in this post can be done with Visual Studio simply by wrapping the text in a new console application, and adding references to the DLLs. However I strongly encourage you to download LINQPad and give it a go.

In the event you are using 64-bit windows and are still using LINQPad 2 you will need to download the x86 version of LINQPad 2, as all of the EVEMon assemblies are compiled for x86. If you have LINQPad 4 you don’t need to worry about.

Assuming you have EVEMon installed, the first step is to load the EVEMon.Common.dll assembly into LINQPad:

  1. Go ahead and fire up LINQPad ensure you have a new query window open
  2. Press F4 (Query -> Query Properties).
  3. Click the “Browse…” button at the bottom of the properties window.
  4. Navigate to the EVEMon install directory.
  5. Select “EVEMon.Common.dll”

While you have “Query Properties” open go to the “Additional Namespace Import” tab and add the following two lines:


EVEMon.Common was designed to work as part of a long running process, namely the EVEMon application sitting in your system tray from when you turn your computer on until you turn it off, as such we need load the static data from the data files.


Now we get to do some LINQ,

var allItems = from item in StaticItems.AllItems
	       where item.Family == ItemFamily.Ship
	       select new
	           CPU = item.Properties[DBConstants.CPUOutputPropertyID].Value.Value,
	           PG = item.Properties[DBConstants.PGOutputPropertyID].Value.Value,

I could start to explain the above line by line, but there are lots of really good LINQ articles on the Internet, including one by Joseph Albahari. We will just say that the above pulls all of the ships out of EVEMon’s Items data file and selects the Name, Race, CPU, PowerGrid and Description property for each one.

Now we see my favorite aspect of LINQPad, the .Dump() extension method, simply running the following command:


Will output the data we have just queried as a nice HTML Table:

That is all I have for you for now, I am working on a project that uses this data outside of EVEMon, keep an eye on Twitter where I will hopefully be providing a link for testing in the not too far distant future.

Tracing A Method Signature

Friday, July 16th, 2010

Over the past three weeks I have discovered that many performance problems with Windows Forms applications are down to certain events being fired very rapidly, usually these are down to layout operations being triggered by updates to controls.

Without the use of RedGate Software’s excellent performance profiler I have been forced back into the habit of temporarily peppering the code I suspect of being a problem with trace messages.

For a while I was quite disorganised using trace messages such as “Entered SoAndSoMethod”, “OnSomeEvent Triggered”, etc. Over time I have settled into using the declaring class and method name to identify which method was being called.

Thinking about it today I decided this was still too much work (yeah, I am that lazy), I wondered if System.Reflection could help me:

public static void Trace()
    var stackTrace = new StackTrace();
    var frame = stackTrace.GetFrame(1);
    var method = frame.GetMethod();
    var parameters = FormatParameters(method.GetParameters());
    var declaringType = method.DeclaringType.ToString().Replace("EVEMon.", String.Empty);
    Trace("{0}.{1}({2})", declaringType, method.Name, parameters);
private static string FormatParameters(ParameterInfo[] parameters)
    var paramDetail = new StringBuilder();
    foreach (var param in parameters)
        if (paramDetail.Length != 0)
            paramDetail.Append(", ");
        paramDetail.AppendFormat("{0} {1}", param.GetType().Name, param.Name);
    return paramDetail.ToString();

This means that with liberal application of:


Will output the following to the trace:

0d 0h 00m 03s > CharacterMonitor.OnLoad(ParameterInfo e)
0d 0h 00m 03s > CharacterMonitor.multiPanel_SelectionChange(ParameterInfo sender, ParameterInfo e)
0d 0h 00m 03s > CharacterMonitor.multiPanel_SelectionChange(ParameterInfo sender, ParameterInfo e)

Hopefully that will save a few seconds here and there. It is a shame that reflection can’t get the actual values of the parameters from the frame, as that would be even more useful.

Preventing the PictureBox control from locking files

Sunday, February 28th, 2010

One of our more regular contributors to EVEMon posted on our forums showing that the application was incapable of updating cached files (specifically images), after a bit testing I discovered the following Exception was being thrown when trying to overwrite the file in question:

System.IO.IOException: The process cannot access the file 'path\filename' because it is being used by another process.
   at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
   at System.IO.File.InternalCopy(String sourceFileName, String destFileName, Boolean overwrite)
   at System.IO.File.Copy(String sourceFileName, String destFileName, Boolean overwrite)
   at EVEMon.Common.FileHelper.OverwriteOrWarnTheUser(String srcFileName, String destFileName) in EVEMon.Common\FileHelper.cs:line 108
   at EVEMon.Common.FileHelper.OverwriteOrWarnTheUser(String destFileName, Func`2 writeContentFunc) in EVEMon.Common\FileHelper.cs:line 82
   at EVEMon.Common.Controls.CharacterPortrait.SavePortraitToCache(Image newImage) in EVEMon.Common\Controls\CharacterPortrait.cs:line 248

After a bit of searching around I discovered a post on StackOverflow identifying that System.Drawing.Bitmap(string filename) would lock the filename until the Bitmap was disposed of. The post presented a solution but no code, A bit of further searching confirmed my expectation that Image.FromFile(string filename) was subject to the same locking behaviour:

The file remains locked until the Image is disposed.

A bit more searching identified another post on StackOverflow which gave me the basic syntax and structure for the code I was going to need to implement this in EVEMon. The final code looks like this:

MemoryStream stream = new MemoryStream();
byte[] imageBytes = File.ReadAllBytes(cacheFileName);
stream.Write(imageBytes, 0, imageBytes.Length);
stream.Position = 0;
var image = Image.FromStream(stream);
return image;

It appears that GDI+ will lock any image that is loaded into a control in WinForms and WPF, several comments on StackOverflow and suggested that even disposing of the control and the FileStream was not a reliable way of being able to write to the file so the above method is seems to be be the best solution all round.

Debugging “Just My Code”

Saturday, December 5th, 2009

Within EVEMon we have started making heavy use of LINQBridge which uses Visual Studio 2008′s Multi-Targeting capabilities to allow a .NET 2.0 applications to use the compiler functionality of C# 3.0. This reduces our need to push EVEMon towards .NET 3.5, and simplifies our dependency stack for the end user (.NET 2.0 is pre-installed on Vista and above, .NET 3.5 is pre-installed in Windows 7 and above).

One of the annoyances I have run into is every time there is a problem with a LINQ statement the debugger will stop in the LINQBridge project rather than EVEMon’s code; this usually tells you nothing useful forcing you to dig into the exception to find the stack trace to find out which line caused the exception.

I found a natty attribute in DebuggerNonUserCode that allows you to tell the debugger to treat a class as Non-User Code:


So far, I have not found a disadvantage in doing this. I am being conservative with my use in case I find some glaring problem, however LINQBridge has proven a stable project, and quite frankly I would much rather be looking at my own broken code when something goes wrong, rather than LINQBridges working code.

Fixing EVEMon’s Crashy C++ DLLs

Saturday, April 18th, 2009

I have been working on EVEMon for about two months now, taking on the responsibility of committing changes to the trunk, fixing bugs and adding new features. As a project I have been involved for several years submitting bug fixes and little features, it was down to my experiences with EVEMon that I decided to implement Subversion and Trac at work.

Unfortunately the first time it came to me to be responsible for a release, it seemed to go terribly wrong. The updated installer worked fine, and it seemed initially there were no problems with the updated code base. However BattleClinic shortly went a little mad with bug reports similar to this one:

EVEMon Version:
.NET Runtime Version: 2.0.50727.1434
Operating System: Microsoft Windows NT 6.0.6001 Service Pack 1
Executable Path: “C:\Program Files\EVEMon\EVEMon.exe”

System.IO.FileLoadException: Could not load file or assembly ‘lgLCDNETWrapper, Version=, Culture=neutral, PublicKeyToken=null’ or one of its dependencies. The application has failed to start because its side-by-side configuration is incorrect. Please see the application event log for more detail. (Exception from HRESULT: 0x800736B1)
File name: ‘lgLCDNETWrapper, Version=, Culture=neutral, PublicKeyToken=null’ —> System.Runtime.InteropServices.COMException (0x800736B1): The application has failed to start because its side-by-side configuration is incorrect. Please see the application event log for more detail. (Exception from HRESULT: 0x800736B1)
at EVEMon.LogitechG15.Lcdisplay.Dispose(Boolean bDisposing)
at EVEMon.LogitechG15.Lcdisplay.Finalize() in D:\EVEMon\EveMon.LogitechG15\Lcdisplay.cs:line 70

For those who are not familiar the above is the crash report generated by EVEMon when a .NET exception is unhandled. lgLCDNETWrapper is the C++ library EVEMon uses to communicate with the Logitech G15. A similar error was generated for EVEMons other C++ component the window relocator.

Tonto Auri quickly spotted that the problem was something to do with the re-compiled C++ DLLs and switching the new DLLs with those from an older package resolved the problems. Whilst this was a fix, I wasn’t willing to just revert the changes and give up on the changes we had made to the G15 library, additionally I was concerned that we had not made changes to the window relocation code and that was causing at least one person a problem.

Quite a bit of searching about with Google and Stack Overflow resulting in finding these two little gems of information:

These two posts basically gave me the tools and the knowledge to fix EVEMon’s problems.

First I made the sudden (and “facepalm”) realization that EVEMon deployed the Visual Studio 2005 Redistributable; we had moved to Visual Studio 2008 SP1 about a month before the release of 1.2.7. I confirmed this with the Dependency Walker utility, by walking lgLCDNETWrapper.dll I was able to confirm that version 9.0.21022.8 of the Microsoft CRT Library (Microsoft.VC90.CRT) would be required.

The next trick was figuring out which re-distributables to deploy with EVEMon to ensure the end user would have all the dependencies required to use all of the features; frustratingly it seems that Microsoft only bundles the latest version of the re-distributables with Visual Studio 2008 and that was version 9.0.30729.1 which was not going to cut it.

Enter Nuonsofts excellent article providing a step by step guide on adding the required compiler flags to ensure the latest version of the CRT was bound. I did find a nice GUI resource editor that was capable of getting the manifests out in XN Resource Editor which made the process a little faster.

A little bit of hacking later the updated Visual Studio 2008 SP1 CRT DLLs and manifest file were deployed to the Microsoft.VC90.CRT folder within the EVEMon program files directory as the VC80 CRT libraries were in the past and the two C++ projects were setup to bind to the latest version with the _BIND_TO_CURRENT_CRT_VERSION=1 preprocessor definition.

A bit more poking arround with XN Resource Editor and Dependency Walker showed we were now in a far better position to have a working copy of EVEMon in the hands of our end users.