We are using logging (log4net) but nothing was logged. But I added some logging points and found out that it is the dynamic loading of an external dll that fails.
ERROR!! Assemblyladdningsfel! Exception has been thrown by the target of an invocation.
ERROR!! Exception has been thrown by the target of an invocation.ERROR!! The type initializer for'MyExternalDll' threw an exception.
Don't know why yet, but probably due to some stupid 2008 security control.
If I copy the entire folder to a Win7 machine (64bit) and install it in the
exact same way, it works like it should.
1. Install it on the Win 7 machine
2. Install it on Win 2008
3. Delete the files from Win 7
4. Copy the files as installed from Win 2008 to Win 7.
5. See if it runs.
If it doesn't compare files.
Daniel Jansson wrote:
Any ideas at all on how to resolve this?
Presuming the install works then it means it is an environment problem.
First change the user that the service runs under to you. Try to run it.
If that doesn't work then open permissions up completely on the install dir. If that doesn't fix it then restore then and continue.
Next step is to determine if it is a start up problem or a code problem. You might be able to determine this by adding a log line as the very first line of the Startup (Service method itself). If that gets into the log then you know that some other process is falling. You can debut that by putting a try/catch in Startup, which you should have anyways and log it. This doesn't work if you start threads and you will need to add more logging for exceptions in threads (which you should also be doing any ways.)
If the first log line doesn't show up then it becomes more difficult because it means that the service class is attempting to pull in a dll and initialization for that fails. Resolving that is done by creating a proxy in the Service which uses dynamic loading of everything else. Basically clone all the real functionality in the Service class, remove the functionality from the service class, then use dynamic loading to load and execute the second class with appropriate exception handling and logging for that.
Of course the above assumes that logging itself isn't the problem.
I am looking for a C# Class which talks to a Biometric device which is connected to the PC and then captures the finger print image. A generic solution which is not dependent on any third part software is what I am looking at.
A little about the solution I am working on its win forms application which displays the captured finger print image and also stores the same as an image.
.NET Framework does not provide any built-in API to work with Biometric devices. The only way to do this is using the API provided by the Biometric device vendor. Check if you vendor has an API library that is .NET compatible and start using it.
I have been scouring the net looking for updated information on interfacing a C# applilcation to a MIDI control interface (M-Audio Xponent). The best I could come up with is PureMidi, Midi-dot-net, and MIDI out setter here on codeplex. Unfortunately, I need the raw information, and need to strip out hundreds of lines of code to make it work. I can get the input and output devices fine, but I need to send simple MidiOutshortmsg and MidiOutLongMsg (sysex), and recieve MidiInshortMsgs. None of the examples really touch on long messages, and all color the short into actual deciphered note info that I don't want. The examples are much too complex for my needs. I need something very simple without 10 support files full of nonsence to sift through and strip down. Most everything is also for vc2005 or before, and are in dreadful need up update to VC2010/2012. The Midi toolkit is useless to me. It won't compile,and I can't determine why. I've spent the last week looking, and the 3 examples provided are the best usefull examples I've found to date, but are much too complex as stated. Please help, I'm beyond frustrated. All I need are simple examples to send and recieve raw hex data. I can parse it from there.
Thanks for any assistance you can provide.
midiOutShortMsg is quite simple, midiOutLongMsg is more complex due to the way that the MIDIHDR structure is used.
Receiving SysEx can be tricky as you will need to add and control the receive buffers.
I can help you with this but I don't think I'll have time until around this time tomorrow unfortunately. If you haven't marked this as solved by then I'll dig out some code to assist.
In the meantime, for output you're going to need these functions:
midiOutProc (this will be a delegate in C#)
and these structs
You will find all the definitions for these on MSDN. They are shown in C++. You will need to create PInvoke versions (to call into Winmm.dll) of these in C#. Search your system for MMSystem.h as there are many things in there (such as the values for constants used etc) that will be handy.
Edit: 20 hrs and no other answers, give me 8 to get some sleep (UK) and I'll post some working code and pointers. Do you have a link to the MIDI implementation chart for the device you're trying to communicate with?
Dave, Thanks! Yes! I do have the MIDI command chart for the Xponent, but I will be making this mostly generic. I don't actually have to recieve sysex, but that would be an added benefit.
I only really need to send a single sysex message to put the unit into advanced mode, and another message to put it back to normal.
I've also been looking at an autohotkey example of Midiin and Midiout that supposedly has sysex, but I have yet to see anything in it refering to MidiOutLongMsg. I appriciate your assistance and willingness to assist. Thanks again!
With MIDI In, the procedure is similar. The problem is you have to prepare a MIDIHDR buffer of x size (x is up to you), add it using midiInAddBuffer and that will be returned to you through a MIM_LONGDATA message in a MidiInProc callback - dwParam1 (you will need to cast the IntPtr to int) contains the MIDIHDR (dwParam2 contains the timestamp which you probably don't need). To get a callback, you will need to set CALLBACK_FUNCTION in the dwFlags when using midiInOpen and also call midiInStart.
Checking the dwBytesRecorded (you will need to add a property to expose it) will tell you how much data there actually is in the buffer. The real data can be copied out of the buffer using Marshal.Copy. Don't forget to unprepare the buffer, free the GCHandle and the data pointer! If it is full and the last byte isn't EOX, you will need to quickly add another buffer to get the rest of the sysex data (you can add more than one buffer)!
Once you have all the data and freed everything you can stop and close the input when you're done - one issue though. You may have prepared and added a buffer(s) but received no sysex into it so it's just sitting there. To deal with these you will need to call midiInReset, get the buffers via the callback, unprepare them (and free the GCHandle and data pointer) before calling midiInClose. There is a midiInStop function, this doesn't return unused buffers. I personally call midiInReset, get the buffers in the callback (freeing and unpreparing them) and then call midiInStop to ensure compatibility with all device drivers just in case.
If you get stuck I will happily knock you up some smple code. Based on what I've already given you and this[^] you should be OK though.
Short messages are a doddle. Open, Start, receive MIM_DATA in the callback and extract the bytes from dwParam1, and once you're done Stop (or Reset then Stop) and Close.
Edit: Just checked, calling midiInClose on a MIDI In that still has buffers will not close the device. Instead the function result will be MIDIERR_STILLPLAYING.
I'm not sure I'm that smart, but with a bit more research on the web, I may figure it out. TBO, I need to re-learn C# programming every time I have a project like this to work on. When complete, I'll probably not touch programming in C# until I get another project I want to tackle maby 6-12 months from now. I tend to do most of my programming in AutoHotkey, unless I want something a bit beefier. It's definatly easier to step through studio code than ahk code, as you can't set breakpoins and step into AHK code.
Haven't forgotten this Jeff! I figured that this was worth making into a full blown article so I'm putting in more effort than I would otherwise - fun stuff though
I'll keep you updated - hopefully it'll finish up with a library that will make it a doddle to use all the low level MIDI API and Stream API directly from C# with no effort. It shouldn't take long now, it's nearly finished.
That would be so awesome Dave! There needs to be something better and more updated available like that for the population. I'm sure someone besides myself will benefit from your efforts! Thanks for doing so, and I look forward to the article.
Well work has put a delay on this. Got a huge project on with a deadline of only two weeks so throwing in 12 hour plus days I'm not going to get time to do anything with this until that's over unfortunately.
In the meantime, this is what I have completed so far. All the MIDI In and MIDI Out is working including SysEx
Not everything is commented and handle locking needs some more attention to ensure thread safety. There is no inclusion of the MIDI Stream API yet.
Check out the GeneralInstructions.txt file in the root folder. That should be enough to get you underway.