Has anyone else had this problem (.NET compiled no run under XP Embedded)

[jester]

Have been running under XP embedded for almost 2 years now; we use
minlogin and launch into a custom shell.

Last week I rebuilt our application (C++ MFC COM) with the new
Microsoft .Net compiler. I rebuilt the disk image with the new .NET
generated binaries.

There were several dll dependenceis that I resolved using depends.exe.

However, I am unable to resolved a low level error in map_pp.cpp which
prevents our application from running.

WHAT IS DIFFERENT WITH THE NEW .NET COMPILER???
Are there other files and components I need to add?
Has anyone else had this problem?

Three days of what should be a simple change -

help

 

[Sean Liming \(eMVP\)]

Jester,

Currently, XPe has support for .NET v1.0. Are you trying to compile for
v1.1?

Regards,

Sean Liming
www.a7eng.com
Author: Windows XP Embedded Advanced and Windows NT Embedded Step-By-Step

 

[Andy Allred [MS]]

I don't know about your particular error, but I do know that .Net Framework
has a hard dependency on Winlogon, although the component does not express a
dependency on Winlogon. Which means there is a bug in the netfx component
where there is a missing dependency on the Windows Standard Logon component.

Any errors you get with Minlogon should be tried against a Winlogon to see
if the error is resolved. If so, then you know that Minlogon+Netfx is the
problem here.

Andy

 

[jester]

Sean,

I am building with .NET v1.0.

I read on the news group that the .NET component that ships with
TargetDesigner does not work with minlogin so I manually installed the
..NET framework using dotnetfx.exe.

The .NET installation appears to complete fine but I am still having
the problem Assertion in map_pp.cpp in the RemoveKey function.

FBA output log looks fine

Have you created and deployed an XP embedded minlogin image with a
custom shell executable built with the new .NET compiler?

I've been working on this for days now:-(
Thanks for help
JP

 

[jester]

Andy,

Thanks for the response. I did do a WinLogin Build with .NET and
still have my problem.

Here is my question:

If we build our regular VC++ client/server application (*.dsw project
with MFC, ATL and COM) with the Visual Studio .NET compiler (which
creates a *.sln "solution" from our "project") we dependent on the
..NET framework?

In other words are we a .NET application just because we have built
with the new compiler?

If so, (please tell me if I am wrong) then we can't use the new Visual
Studio .NET compiled code with an XP Embedded minlogin build.

If this is the case is there a work around?

JP

 

[Tony]

If you compile with Visual Studio .NET, then yes, you are
dependent on the .NET Framework.

-----Original Message-----
Andy,

Thanks for the response. I did do a WinLogin Build with .NET and
still have my problem.

Here is my question:

If we build our regular VC++ client/server application (*.dsw project
with MFC, ATL and COM) with the Visual Studio .NET compiler (which
creates a *.sln "solution" from our "project") we dependent on the
..NET framework?

In other words are we a .NET application just because we have built
with the new compiler?

If so, (please tell me if I am wrong) then we can't use the new Visual
Studio .NET compiled code with an XP Embedded minlogin build.

If this is the case is there a work around?

JP



"Andy Allred [MS]" <[email protected]> wrote

I don't know about your particular error, but I do know that .Net Framework
has a hard dependency on Winlogon, although the component does not express a
dependency on Winlogon. Which means there is a bug in the netfx component
where there is a missing dependency on the Windows Standard Logon component.

Any errors you get with Minlogon should be tried against a Winlogon to see
if the error is resolved. If so, then you know that Minlogon+Netfx is the
problem here.

Andy

.

 

[Lasse]

Hi
In many cases Depends.exe is not good enough.
It shows only statically linked DLLs.
You need an utility that shows actually used DLLs.
This includes DLLs that are dynamically loaded by a running program.
ProcessExplorer from www.sysinternals.com does this.

Start your application on an XP pro system and use ProcessExplorer to get
a list of needed DLLs.

When I converted to .NET, everything I needed was a couple of DLLs
from VisualStudio .NET

 

[jester]

Issue resolved.

First, I had a suspicion this was a DAO problem. The same assertion
gets thrown if DAO is not on the target system.

However, the ONLY difference between the two builds was one was done
with the .NET compiler and one was done with the VC++.

Now, thanks to Andy's great article on remote debugging (it was VERY
easy to set up!) The assertion confirmed inability to connect to DAO
engine.

SO I manually installed DAO, still same error.

So I happened to notice a DAO component DAO Jet Engine Support that
was NOT included in my TD project. AGAIN, THIS COMPONENT WAS NOT
NECESSARY PRIOR TO BUILDING WITH THE NEW COMPILER.

I added this coponent and viola all better.

A long time to resolve this.

Also, it does not appear that I am depended on the .NET framework.
Would be good to get some clarification form MS here on this.

JP