Deploying .NET Application to WinXPE

[Derek]

I have developed a .NET application intended to be run on a WinXPE
computer, however whenever I run the app, I get the following error:

-
..NET Framework Initialization Error

To run this application, you first must install one of the following
versions of the .Net Framework:
v1.1.4322
v1.0.3705
Contact your application publisher...
-

Now, it's prompting for both versions of the .NET framework because I
tried to compile it so that it would run on v1.1 and v1.0, to see if
that helped.

Does anybody know how I might install v1.1.4322 onto WinXPE? I've had a
look through some past newsgroup postings, and did not see a question
like this.

Thanks for the help.

DC

 

[KM]

Derek,

The best thing you could do is to build a new image for your device and include there the .Net 1.1 component (if SP1 - QFE, SP2 has
the latest).

If you don't have a way of building and/or deploying images on your device, I'd recommend you contacting the device manufacturer.

If this is not an option for you, you are left with only way to either install .Net manually at run time (if all the installer
dependencies are in the image too), or figure out all the .Net Framework files and registry entries that need to be integrated in to
your image.

KM

 

[Derek]

But that's the thing... I _have_ included the .Net 1.1 component, and
it still doesn't work.

Any other suggestions?

DC

 

[Derek]

Here's some further information....

My XPe is SP2. I've confirmed that. I tried installing the QFE, but
since I'm running SP2 that didn't work properly.

Any help is appreciated.

DC

 

[KM]

Derek,

On SP2 you don't need that QFE since the .Net 1.1 Framework component in SP2 Repository is the exact same component from QFE
(v1.1.4322 build).

Can you give a bit more info about the testing you do?
Specifically, can you run HelloWorld app (C#, VB.Net, etc.) on your image with no problems?
How complex is the application you are trying to launch? (what framework system libraries are used?)

 

[Derek]

Yes, the HW app runs fine.

As for my app, I'd say it's pretty complicated. It's using the
Interop.QuartzTypeLib DLL to play MPG files. Now, I've deployed the DLL
along with the application, so I was assuming this wouldn't be a
problem. Is there some way to test that this DLL works with XPe fine?
Other recommendations?

Again though, the error I'm getting seems to indicate it simply cannot
find the .Net Framework. Is there some compilation flag or something I
can check?

Thanks for the help.

DC

 

[KM]

Derek,

Yes, the HW app runs fine.

This is good.

As for my app, I'd say it's pretty complicated. It's using the
Interop.QuartzTypeLib DLL to play MPG files. Now, I've deployed the DLL
along with the application, so I was assuming this wouldn't be a problem.

Yup. That is basically just a .Net interop wrapper (RCW) for the quartz.dll (ActiveMovie COM control library).

Is there some way to test that this DLL works with XPe fine?
Other recommendations?

Well.. if it is a missing dependency issue, you can try XPProEmulation image (www.xpefiles.com) that includes virtually all the
sfotware components from XPe database.

Another thing you can do - use FileMon and Regmon to see what's missing from your image when you start your applications.
Or, statr the application on XP Pro machine under a VS debugger and see what libraries are getting loaded and from where (hopefully,
the same .Net v1.1 is installed there). Then make sure all the libraries are in your image in the same locations.

Again though, the error I'm getting seems to indicate it simply cannot
find the .Net Framework. Is there some compilation flag or something I can check?

It could be a referenced library problem. So, did you get the Interop.QuartzTypeLib.vxxx.dll in your exact application/working
folder on the image?

Verify that at run time the quartz.dll got properly registered. In post FBA image see if you got the
[HKCR\TypeLib\{56A868B0-0AD4-11CE-B03A-0020AF0BA770}] typelib key.

After all, make sure you add the DirectShow stack - Core - (or, better, the entire DirectX stack).
And verify that there is no issues with your display driver on the image.

Also, you should test you app on a different (not your Dev!) XP Pro machine. Basically you should know what files you need to
properly deploy the application.

 

[Derek]

App has been tested on non-dev machine, and other than XP Pro, it
doesn't seem to require anything else.

My next step was to try the XP Pro Emul image. While that's been an
excrutiatingly long process, I finally have an image built (summary:
downloaded slx, tried to build, "stop error", determined I needed to
upgrade config, upgraded config [LONGG!!!], re-built image, and
now....). Now with the new XP Pro Emul image, FBA just runs over and
over, reboots, runs again. I let it do this for something like 12 hrs
today, in the hopes that maybe it was configuring a few select
components individually or something (this didn't seem overly odd since
my initial 200MB image did this once or twice before booting, and this
XP Pro emul image is 650+MB).

So, I really want to test my app on the xp pro emul image, SP2, but I
can't get it past FBA. Recommendations?

DC

 

[KM]

Derek,

Sorry for the hassle with XPProEmulation image. I so got used to it that it usually takes just a few hours for me to have it running
on a new machine.
I have upgraded my "local" version of XPProEmulation and it was indeed pretty long process (a few hours).
One of the most important system requirement to be able to work nicely with XPProEmulation image is enough RAM. Initially I
developed the project with just 512Mb RAM and it became much less pain when I upgraded my dev machine to 1G of RAM.

Anyway, you probably have not set up properly the targe device partition settings. Easiest way to know what settings you should use
there is to analyze the current FBALog.txt file (you will have to interrupt the long FBA process on the target device).
http://msdn.microsoft.com/embedded/community/community/tips/xp/reboots/default.aspx

XPProEmulation does not include EWF (and should not) so it shouldn't be the cause for the FBA repeat reboots.

Also, just FYI, it usually take ~30 minutes for the XPProEmulation image to pass the FBA phase on a target device with
PIII/800MHz,512M RAM,20G HDD.

KM

 

[Derek]

Target device is 800MHz, 128MB RAM, 4GB HDD (just for testing,
originally has >100GB HDD)

EWF: The XPProE image includes the EWF Management Console, but not the
EWF API, which I imagine is the component that actually instantiates
EWF, correct? So this should be fine.

FBALog.txt: I don't have any "invalid path" errors in there, so my
target device settings should be fine. Also, there is only a single
partition, so that must be C:, no?

1GB RAM: I'm mainly developing on a 1.6GHz 512MB laptop. 1GB RAM is a
desired upgrade, just don't have the budget right now, and even if I
did, I'd probably just grab a PSP to bide the long wait times.
haha...

DC

 

[KM]

Derek,

Target device is 800MHz, 128MB RAM, 4GB HDD (just for testing,
originally has >100GB HDD)

128M RAM? Well.. This might not be enough for the XPProEmulation. Think about XP Pro and that would be almost the same specs.

EWF: The XPProE image includes the EWF Management Console, but not the
EWF API, which I imagine is the component that actually instantiates
EWF, correct? So this should be fine.

No, EWF API is not required. It is just a wrapper dll to pass command to the EWF driver through a user mode API.
Note that EWF API was not there in SP1 database but there was a QFE to add it.

Having EWF Management Console included is hurtless if there is no EWF driver added.

FBALog.txt: I don't have any "invalid path" errors in there, so my
target device settings should be fine. Also, there is only a single
partition, so that must be C:, no?

Right, just C:. So, how long FBA is running on the device with XPProEmulation image?
Do you see any "crash" or fatal errors during FBA? I'd guess that 128M is absolutely not enough for the image so that must be the
cause.

1GB RAM: I'm mainly developing on a 1.6GHz 512MB laptop. 1GB RAM is a
desired upgrade, just don't have the budget right now, and even if I
did, I'd probably just grab a PSP to bide the long wait times.
haha...

The reason for 1G is that SQL Server (which is likely running locally on the same machine of yours, right?) will cache the most part
of the Mantis DB and that will help dramatically to improve the build and dependency check performance in TD.
So if you decide to stick with XPe, you would gain a lot in your work if you upgrade your PC