XP Embedded, Framework 2.0 and DirectX 9

[Guest]

Hi

I've got an annoying problem when trying to run my own application on an XP
Embedded PC with .Net Framework 2 and DirectX 9. Might be long-winded, so
please bear with me.... (and i'm no expert, just beginning the whole .Net
business)

On my local development PC, I'm running Windows XP Pro SP2, Visual C#
Express, DirectX 9 SDK and the .Net Frameworks 2.

My application uses DirectInput to interface with a joystick and contains a
form with a couple of buttons. When this is compiled and run on the local PC,
everything works perfectly as expected. However, when i transfer this to the
Embedded PC, i immediately get an error saying "application encountered a
problem and needs to close" then the application closes and asks me if i want
to send an error report.

Checking the error report info, i get the following:

EventType : clr20r3
P3 : 44edbc51
P9 : system.io.filenotfoundexception

Could this problem arise due to the way exceptions are handled in my
application (i can provide source if needed) or could it be anything to do
with the following...

I run FileMon to see what's happening with what files and i find that right
before the "CLOSE" request, a number of files are "NOT FOUND" - these are

- WINDOWS\Microsoft
..Net\Framework\v2.0.50727\config\security.config.cch.XXX.XXXXXX (XXX's change
after every execution of the program)
- WINDOWS\Microsoft
..Net\Framework\v2.0.50727\config\enterprisesec.config.cch.XXX.XXXXXX (XXX's
are same as above)

and finally
- Documents and Settings\<Current User>\Application Data\Microsoft\CLR
Security Config\v2.0.50727.42\security.config.cch.XXX.XXXXXX (XXX's again
same as above)

Now the "CLOSE" request is sent, presumably because the application has
crashed. Anyways, i'll continue. In my source code, if i remove all traces of
DirectX (all code commented out and all namespaces commented out) and i
re-compile, the program will run on both my local PC and on the embedded PC
without any errors.

I originally thought it was something to do with the way DirectX was
installed on the XP Embedded image but the above tells me that its a .Net
Framework error. Aaarrrggghhhh

Bizarre and i don't know why. Please can someone help me (if you understand
the above that is...)??? I wish i knew more about what i'm doing.

Thanks in advance

Kev

 

[JS]

I don't know if this is related to your problem, but
one problem I've had with .NET 2.0 is that it uses
reparse points (or junctions) in the file system.
For example:

Directory of C:\WINDOWS\assembly\GAC_32\System.EnterpriseServices

08/10/2006 11:44 AM <DIR> .
08/10/2006 11:44 AM <DIR> ..
08/10/2006 11:44 AM <JUNCTION> 2.0.0.0__b03f5f7f11d50a3a


These types of folders may not get deployed to your device properly.
(The junction may become an empty folder.)

The solution is to either recreate the junction,
or to copy the missing file(s) directly to your device.
SysInternals has a free tool called Junction which will identify any
junctions on your system.

 

[Guest]

Hi

Thanks for the quick reply, i shall try that tomorrow. Not sure it'll be the
fix for my application but i'll try it.

When i transfer the application to the embedded device, i just copy the
executable file across using flash media. Do you know if i should properly
deploy the application through the Publish feature or is the current method
of just copying and pasting fine? Just thinking that other files needed could
move across with the Published setup file...

Thanks again for your help

Roll on other suggestions.

Kev

 

[Guest]

Well, i think i may have fixed my problem. I "Published" the application and
ran the setup file on the Embedded PC and at the start of the install i was
presented with a message saying "Microsoft.DirectX.DirectInput assembly not
found in the Global Assembly Cache" (or words to that effect).

In the applications properties from within Visual C# Express, i included the
Microsoft.DirectX and Microsoft.DirectX.DirectInput libraries in the
Application Files list under the Publish submenu.

I re-published the application and executed it on the Embedded PC. It now
runs with no problems...

I think my lack of knowledge of the .Net Framework has taken its toll

Kev