The following procedure shows how to configure an ActiveX/COM DLL that uses MSXML 5.0 and which is in turn referenced by a Visual Basic EXE application. Here is a diagram of how this application design looks:
Project1.exe (a Visual Basic Standard EXE) calls DllTest.dll (ActiveX/COM DLL) which depends upon and uses MSXML 5.0 assembly
In this scenario, to achieve side-by-side installation under Windows XP you need to:
To create a manifest for your component DLL
Note If you want, you can create these files yourself from scratch, using either Visual Basic or Visual C++. For more information about how to create these files using Visual Basic, see Using Visual Basic to Create Sample DLL and EXE files.
If you are using Visual C++, a good place to look is the .rgs file, which looks like this:
HKCR { DllTest.FusionTest.1 = s'FusionTest Class
' {CLSID = s '{CDC6C7A2-C16B-4D84-8E46-EBEDBCCC50BF}'
}DllTest.FusionTest
= s 'FusionTest Class
' { CLSID = s '{CDC6C7A2-C16B-4D84-8E46-EBEDBCCC50BF}' CurVer = s 'DllTest.FusionTest.1' } NoRemove CLSID { ForceRemove {CDC6C7A2-C16B-4D84-8E46-EBEDBCCC50BF} = s 'FusionTest Class' {ProgID = s 'DllTest.FusionTest.1'
VersionIndependentProgID = s 'DllTest.FusionTest' ForceRemove 'Programmable' InprocServer32 = s '%MODULE%' {val ThreadingModel = s 'Apartment'
}'TypeLib' = s '{4D2F7845-6A75-40EF-AD97-179C5088E507}'
} } }
If you are using Visual Basic, you might want to use the OLE Viewer tool to browse these properties for the object and its type library.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> <assemblyIdentity version="1.0.0.1" processorArchitecture="x86" name="DllTest.dll
" type="win32" /> <file name="DllTest.dll
"> <typelib tlbid="{4D2F7845-6A75-40EF-AD97-179C5088E507}
" version="1.0" helpdir=""/> <dependentAssembly> <assemblyIdentity type="win32" name="Microsoft.MSXML2" version="5.0.0.0
" processorArchitecture="X86" publicKeyToken="6bd6b9abf345378f
" language="*" /> </dependentAssembly> </file> </assembly>
name
attribute of the first <assemblyIdentity>
element, set the value to "DllTest.dll".name
attribute of the <file>
element, set the value to "DllTest.dll".tlbid
attribute of the <typelib>
element, set the value to the type library ID for the DLL.description
attribute of the <comClass>
element, set the value to the description for the DLL.clsid
attribute of the <comClass>
element, set the value to the CLSID for the DLL.threadingModel
attribute of the <comClass>
element, set the value to the threading model implemented for the DLL.tlbid
attribute of the <comClass>
element, set the value to the type library ID for the DLL.
Note If you have additional DLLs packaged in this assembly, you can add additional instances of the <file>
element, for example:
<file name="
Another.dll">
. . .
</file>
You will then need to repeat this step (and each of its substeps) for each <file>
element you add.
You should see a form with a Test DLL button centered on it.
You should see a message box that displays "<test/>". If you do, the application has been successfully tested.
If the application does not run correctly in this way, you will need to do further troubleshooting to determine the problem. For example, you might see this error:
"This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem."
If this occurs, check the manifest file for errors and validate it. You do not need to reinstall your application to perform this checking. For more information about tools for checking manifests, see the following section.
Note Modifying your component so that it becomes public (i.e., shared globally to other applications on the system) requires a number of additional steps and considerations. For more information, download and review the whitepaper referenced at the end of this article, How to Build and Service Isolated Applications and Side-by-Side Assemblies for Windows XP.