lunedì 26 marzo 2012 14:09
I have a solution in Visual Studio 2010 that includes C++
and C# projects. Both use the old version of msado15.dll. My target operating system is Windows 7 SP1, and yes, I’m having problems with _Recordset getting converted to
_Recordset_Depreciated when the projects compile.
The solution for the C++ projects was to copy the old
version of msado15.dll to my development directory tree, then use #import with
no_registry to pull the old version into the project. This works.
I’m having a problem with the C# projects. When I try to add
a Reference to the old version of msado15.dll in my development directory tree,
the project ignores what I told it to do, and gets the msado15.dll from the
registry. Of course, this compiles to _Recordset_Depreciated. Anything calling
a method returning _RecordSet won’t compile when the return type is
I tried hand-editing the project file to remove the COM
reference and provides the absolute path the old version of msado15.dll. In
this case, the project ignores what the csproj file says, and maps to the msado15.dll
in the following directory:
C:\Program Files\Microsoft Visual Studio 10.0\Visual Studio
Tools for Office\PIA\Common\adodb.dll
Same problem at compile time with _Recordset_Depreciated.
Unregistering msado15.dll from the registry doesn’t seem to
be an option, as it has other dependencies that would first have to be
I’m told that Microsoft is going to fix this mistake in the next
service pack for Windows 7, so I don’t really want to write a lot of
work-around code that will have to be pulled out after SP2 arrives.
Any suggestions on how to get a Visual Studio 2010 C#
project to actually reference the dll I’m asking it to reference?
Tutte le risposte
lunedì 26 marzo 2012 16:44Moderatore
When you're working with COM components VS is going to use the COm component registered on the machine. You won't be able to use the legacy COM component. To work around this issue you'll have to generate the PIA manually.
1) Run TlbImp.exe against the legacy DLL to generate the PIA assembly
2) Remove the COM component from your project references
3) Add the generated PIA assembly as a project reference.
Note that the generated component is still going to use the version independent ProgID so if the ultimate problem lies in using the newer COM component at runtime then TlbImp won't help you either. The only option you have at that point is to manully create the PIA. It can be a lot of work defining the interfaces, types but it isn't difficult. It is covered here: http://msdn.microsoft.com/en-us/library/xwzy44e4(v=vs.80).aspx. As a shortcut you could actually use TlbImp to generate the PIA and then use a disassembly tool like Reflector or JustDecompile to get the source code, copy it and make the necessary change to use a version-specific ProgId.
Michael Taylor - 3/26/2012
lunedì 26 marzo 2012 17:05
Many thanks for the reply. In the C++ project, my post-build step calls tlbimp, which generates the reference I pull into the C# project. I added /tlbreference:mypath\msado15.dll to the tlbimp call. The call to the method in the C++ project is now returning _Recordset, not _Recordset_Depreciated.
In my C# project under references, I still have ADODB (which is how the references appears when I add msado15.dll), which I need to declare the return type at compile time: "ADODB.Recordset". The fact that this is coming another msado15.dll no longer seems to matter.
- Contrassegnato come risposta Randy42Developer42 lunedì 26 marzo 2012 17:05