IMPLEMENT_SERIAL on .NET vs Vcp6

[John Olbert]

I am reposting this under a new Subject that may be more discriptive. It was
posted originally on 5/22 but no replies were received. This problem is
significant. It is preventing us from moving a large project to .NET.

Any help would be appreciated.

Original post--

I have a situation where a Dll is not loading properly (the IMPLEMENT_SERIAL
macro is not being hit) in the Release build. It works fine in the Debug
build. Any suggestions would be appreciated.

Both the Release and Debug build without errors and the App (with this Dll)
runs fine in the Debug version but in the Release a breakpoint is never hit
on the IMPLEMENT_SERIAL of the class in the Dll. Also the class is not in
the list of classes when the code tries to load the document and create the
class dynamically.

--John Olbert
@jol...@snet.net

[John Olbert]

Thanks very much for replying.

I tried the fix by changing the macros in the Dll that is not being loaded.
Unfortunately it did not resolve the problem. Specifically the
IMPLEMENT_SERIAL code (now IMPLEMENT_SERIAL_FIXED) is not being hit in the
Released version. The actual problem shows up when the function pasted below
is called. It cannot find any of the classes defined in the Dll.

I changed all the macros (IMPLEMENT_SERIAL,DECLARE_SERIAL) in the Dll but I
did not change them in the Exe that loads the Dll because there is roughly
3000 files (roughly 2000 classes) in the main Exe. I figured that only the
classes in the Dll were involved but I could be wrong but the magnitude of
the change would be very large for the Exe.

In addition to the following code not finding the classes in the Dll another
symptom is that the debugger shows a question mark in the breakpoint set at
the IMPLEMENT_SERIAL code in classes in the Dll. The tooltip help indicates
that the code is not loaded.

Again any help would be appreciated.

--John

code that does not find the classes in the Dll--

CRuntimeClass* PASCAL CRuntimeClass::FromName(LPCSTR lpszClassName)

{

CRuntimeClass* pClass;

// search app specific classes

AFX_MODULE_STATE* pModuleState = AfxGetModuleState();

AfxLockGlobals(CRIT_RUNTIMECLASSLIST);

for (pClass = pModuleState->m_classList; pClass != NULL;

pClass = pClass->m_pNextClass)

{

if (lstrcmpA(lpszClassName, pClass->m_lpszClassName) == 0)

{

AfxUnlockGlobals(CRIT_RUNTIMECLASSLIST);

return pClass;

}

}

AfxUnlockGlobals(CRIT_RUNTIMECLASSLIST);

#ifdef _AFXDLL

// search classes in shared DLLs

AfxLockGlobals(CRIT_DYNLINKLIST);

for (CDynLinkLibrary* pDLL = pModuleState->m_libraryList; pDLL != NULL;

pDLL = pDLL->m_pNextDLL)

{

for (pClass = pDLL->m_classList; pClass != NULL;

pClass = pClass->m_pNextClass)

{

if (lstrcmpA(lpszClassName, pClass->m_lpszClassName) == 0)

{

AfxUnlockGlobals(CRIT_DYNLINKLIST);

return pClass;

}

}

}

AfxUnlockGlobals(CRIT_DYNLINKLIST);

#endif

return NULL; // not found

}

"Anson Tsao [MSFT]" <ans...@online.microsoft.com> wrote in message
news:OFatGTrBCHA.1664@tkmsftngp02...
> John,
>
> This is a known bug, it is fixed for the next VC release. In the mean
time,
> I've enclosed a "fixed" version of the macros that you can use.
>
> --
> Anson Tsao
> Visual C++ libraries team
>
> Of course, this posting wouldn't be complete without a nice, juicy
> disclaimer from our lawyers: This posting is provided "AS IS" with no
> warranties, and confers no rights. You assume all risk for your use. ©
2002
> Microsoft Corporation. All rights reserved.
>
>
>
>
> "John Olbert" <jol...@snet.net> wrote in message
> news:O5XNHXnBCHA.1576@tkmsftngp04...

[John Olbert]

I am reposting this item since it has been a while without a reply.

We did try the macro fix indicated below but it did not resolve the problem.

Again, this is a serious problem for us since we cannot ship the product
under .NET since the Release version will not run. The IMPLEMENT_SERIAL code
is not being hit in the Dll classes in question. Unless we can resolve this
problem we will have to cancel our switch to .NET. Any additional
suggestions would be greatly appreciated.

--John Olbert
jol...@snet.net

original post--

[Werner Slabon]

Today, I met the same problem.
After I solved the problem, I read several solution in
vc.mfc.
But here is my solution:

Change the original code of the IMPLEMENT_SERIAL macro to
this:

#define IMPLEMENT_SERIAL(class_name, base_class_name,
wSchema) \
CObject* PASCAL class_name::CreateObject() \
{ return new class_name; } \
extern AFX_COMDAT AFX_CLASSINIT
_init_##class_name; \
_IMPLEMENT_RUNTIMECLASS(class_name,
base_class_name, wSchema, \
class_name::CreateObject,
&_init_##class_name) \
AFX_COMDAT AFX_CLASSINIT _init_##class_name(RUNTIME_CLASS
(class_name)); \
CArchive& AFXAPI operator>>(CArchive& ar,
class_name* &pOb) \
{ pOb = (class_name*) ar.ReadObject
(RUNTIME_CLASS(class_name)); \
return ar; } \

If nessessary change all other IMPLEMENT_SERIAL macros in
the same way !

In my applications this worked for debug & release version.
But don't forget, to copy and restore the original afx.h
before installation of the service pack (which will
officially correct the problem).

Werner

>> > posted orÍ{ wÀ Z 4 G4xAG +f ìì iginally on 5/22 but

>.
>