I'm trying to use CComHeapPtr smart pointer with Embarcadero C++Builder 2010, but can't find the definition in any of the supplied headers. And I get this error.
[BCC32 Error] E2451 Undefined symbol 'CComHeapPtr'
It's not in atlbase.h (and atlalloc.h seems to be completely missing).
I intended to use this to give exception-safe freeing of the ItemIDList returned from IShellFolder::ParseDisplayName.
Is it present in this version, or does C++Builder just use an incredibly old version of ATL?
And, other than just rolling my own, is there a better alternative?
CComHeapPtr is not available in any version of ATL that has shipped with C++Builder.
C++Builder does support ATL, but older versions of it. Microsoft has stopped licensing ATL to third-parties, and the latest ATL relies on VC++-specific compiler extensions. C++Builder XE is the last version that ships with working ATL files. C++Builder XE2 onwards still support ATL but only if you have a copy of the ATL files from an earlier C++Builder version (XE2 has stub files that have #error statements to warn you if you try to use them). ActiveX is officially supported using Embarcadero's own DAX framework now, which is not ATL-compatible.
Related
Visual Studio 2012
VB.Net
.NET 4.0
Build Machine x64
Build Config AnyCPU
msado27.tlb
This project is not new and has been built 100s of times over the past 2 years. With in the past 3 weeks something has changed and a COM reference to the Microsoft ActiveX Data Objects 2.7 library is no longer able to registered. When I try to reselect it from the available COM entries it is visible and selectable.
Com reference list
After selecting you can see the yellow triangle
reference tree node with yellow triangle
Then viewing it thru the its properties you can then see there is no path being shown.
reference properties
When viewing thru the project properties -> references it display
project properties references
If I select a newer version such as 2.8, 6.0, or 6.1 they will register. However if I select an older 2.5 it acts the same way.
Any suggestions or theories on what may have happen or how to verify if the .dll in the GAC or Primary Interop Assembly actually has definitions and or implementation for version 2.7?
And by the way I do realize that this is an extremely old version, but this current .Net project has additional COM references/dependencies which rely on this particular version and I am unable to switch to a newer version at this time.
Well after a painful day and a lot of wasted time I decided to go the route of re-registering the types again using regasm which I didn't think really had a chance of fixing the problem. Low and behold that was the problem.
The fix for me...
Open the developer console for VS2012 as Administrator
Navigate to the GAC area for your adodb.dll #
%windir%/assembly/gac/adodb/7.0.3300.0__b03f5f7f11d50a3a
Then run the command "regasm adodb.dll" and you should receive the
"Types registered successfully" message
Return to VS2012 and all current references to
Note: Early on when reviewing the registry values for the type libraries found in the adodb.dll file I noticed that the version that would not register in VS (2.7, 2.6, and 2.5) did NOT have Primary Interop Assembly value for there keys as the newer versions did. After running regasm those value were added in for the older versions.
Shows primary interop assembly info for v2.7 after running regasm
I have a super-basic question about how calls to DLLS work in Windows - If there are 2 DLL versions installed on the same Windows system (say, MSXML 4.0 and 6.0) and they are both registered, assuming the 4.0 and 6.0 version dlls both support some same function call, how does Windows internally route the call? IE, is the convention to hand it to the newest version? Or the last registered version? or something else?
Related: Generally speaking, if you craft application code to explicitly use the 4.0 version, how does it achieve this, if a newer DLL implements the same call?
Thank you!
This isn't about calling conventions, which means something else entirely.
With ActiveX DLLs you create class instances by their ClassID or ProgID. These are normally looked up in the type library during development or at compile time, or hard-coded into the calling source code. There are version independent ProgIDs and version specific ProgIDs.
System.Data.SQLite (SDS) is apparently the most popular way to use SQLite from a .Net application.
I was wondering if
SDS requires shipping the SQLite DLL in addition, or if SDS includes
the SQLite source code, and
SDS can be statically compiled into a
VB.Net application of it can only be shipped as a DLL?
Thank you.
To expand on my comment, SDS is a .net wrapper for unmanaged code, so you will need to ship your release code with a copy of the DLL.
As Steve mentions, there are 32 and 64bit versions of the DLL, and as i discovered after much frustration, you must have the corresponding visual c++ runtime installed on the target machine, so if you deploy the 32bit version onto a 64bit machine, it will need the 32bit c++ runtime environment installed.
An alternative that i am currently looking into but havent had time to test is csharpe-sqlite, a pure .net implementation:
http://code.google.com/p/csharp-sqlite/
Coded in c# as the name suggests, but of course usable in any .net language including vb.net
Actually it's quite easy to compile System.Data.SQLite.dll to the does not require C++ runtime. For example if you download source code and follow the build procedures you'll find statically linked (no C/C++ runtime required) copy of System.Data.SQLite.dll in the following path:
<your-src-root>\bin\<2008 or 2010>\<Win32 or x64>\ReleaseStatic
For example if your source is in C:\Work\sqlite-netFx-source-1.0.80.0 then statically linked binary for Win32 and .NET 3.5 (VS 2008) will be located in:
C:\Work\sqlite-netFx-source-1.0.80.0\bin\2008\Win32\ReleaseStatic
Furthermore since System.Data.SQLite.dll is a mixed-mode assembly consisting of a managed .netmodule and native .obj file linked together using link.exe, it is possible to build your app as a .netmodule as well and link it together with SQLite into a single mixed mode assembly.
The resulting assembly will still be either Win32 or x64, however since almost all x64 machines will have no problem running Win32 code you can just settle on Win32 as long as:
Your app is an .exe or a .dll the is always loaded into a Win32 process, and
You don't use any of x64 specific advantages such as larger address space or using unmanaged code available only in x64
When I try to run the dll I compiled in Visual Studio 2010, I get the following message: This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded. I'm guessing this means that I am a too recent version of Visual Studio. Is there a way I can build the dll as an earlier version?
All assemblies in your final solution, be they dlls or exes, in different solutions or in the same one, must target the same version of the CLR. You can ensure they do by configuring targeting in your 2010 solution.
Most likely you're targeting 4.0 in your dll's project. Crank it back to 3.5 or earlier and see if that fixes the problem.
I currently have a VS6 unmanaged C library that I deliver as either a .lib or .dll. I want to upgrade to VS2010 but I still have users that are in VS6, VS2005, and VS2008.
Can a .lib or .dll built in VS2010 be used in VS6, VS2005, or VS2008?
Thanks!
It depends on the runtime used to build the libraries. I would typically run into this problem when upgrading solutions from VS2005 to VS2008. The default runtime libraries are different from edition to edition.
When you're building the .lib and .dll, those files are getting linked against those editions of the runtime. Problems will typically be found when you're debugging the program between different VS editions or running it on a non-developer machine when assemblies built with different runtimes attempt to pass information across boundaries. See http://msdn.microsoft.com/en-us/library/abx4dbyh.aspx for details.
I know this is an old post but if anyone else comes across it this may be useful, upgrading from vc6 to vs2010 is a nightmare, but there is an alternative. You can upgrade to VS2010 environment while still using vc6 compiler. the tool you need is Daffodil and can be found here http://daffodil.codeplex.com/
This was our solution because the VS2010 environment is way more productive.