I am developing a COM object for Windows Embedded Compact 7 on an iMX28 Armv5 board.
I have built the OSDesign through Platform Builder and generated the SDK. When creating the ATL Smart Device COM project against my SDK, when I select to create it as an executable it doesn't create the Proxy / Stub DLL that is usually created if I were building it as a Win32 executable.
I have tried manually copying / editing an xxxPS.DLL project to the solution and adding the i.c, i_p.c, .def and dlldata.c as explained in Building Proxy/Stub dll in VS 2008 but all without success.
Any ideas how I can get my COM EXE to generate the Proxy / stub dll?
Related
I have three VS2015 projects (DLL, C++ App & C# App)
I created the DLL and targeted v4.5 Framework
I created the C++ Application and targeted the v4.5 framwork and then was able to add reference without an issue.
I create the C# Application and targeted the v4.5 framework and then the Add reference fails with check your assembly or COM message.
Both applications have the DLL project added to the solution.
What else can I check as to why my C# process can't add reference?
Thanks,
Mark
I got around it using PInvode and the C# project didn't need to Add Reference afterall. I had to manually edit out the Precompiled header stuff to force that NotUsing. Thanks for the quick response... just had a quick turn around for my boss. Handed a working Cipher DLL for use with both C++ and C# in his project.
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
I have downloaded a .exe file that when executed (in wine) it puts two dll's in the system32 folder and a dll in the "Common files/App-name/" folder.
In theory, the installing of this file creates a tab in Visual Studio that appears when referencing and it is a COM library.
I have tried to reference these dll's in my console project but I get a message of "Is not a valid .Net assembly".
Is there something I can do?
MonoDevelop does not have support for adding COM references directly. You will have to use tlbimp.exe to generate a wrapper dll, then reference that. This is essentially what VS does transparently when you reference a native COM dll.
I have one problem in vb6. I created a .tlb file in VB.net 2005 by adding Com class to project. I built the project, I got .tlb file and .dll files while building project, i selected "Register for Com interop" from project properties and built. It registered autometically and I can use created .tlb file in that PC in Vb6 working fine. if I deploy application to another PC and run I am getting "Error 429 ActiveX Component Can't create object" run time error. What I need to do? Please help me as soon as possible. I can't deploy the application to client due to above error.
one possible solution is to install .net frame work on client pc i never want to install .net framework any other solution will be most appreciatable.
If you've created a DLL in a .NET language (such as VB.NET), the target computer must have the .NET Framework installed in order to use the DLL.
This a hard and fast requirement, irrelevant of how you're utilizing the DLL, whether from a VB 6 application through COM interop or otherwise. It is also a hurdle you'll have to jump over first, before you worry about things like registering COM components, as Uday's answer suggests.
If you don't want a dependency on .NET, you need to use another environment to create the ActiveX DLL; either C++ or VB 6 are possible choices.
One option may be that, while deployment, you need to register that .tlb file in System Registry using regsvr32 command in command-prompt. Generally static libraries does not work until they are registered with System Registry.
You might have seen many programs register components during installation like 'Registering Type Components' or 'Registering COM Components' (for those who do networking especially). Those components are nothing but native COM dlls and tlbs.
so when creating deployment project, add some scripting login to register thode dlls and tlb to System registry using:
regsvr32 <path to tlb/dll>
you have to recursivey call this command for every dll/tlb you want to register with system. For example, if you have 4 dlls and 2 tlbs then you have to call it 6 times providing the path of dll and tlb one at a time.
I have a C++/CLI assembly that wraps a native 32-bit dll.
The assembly is used both from .Net and COM (office).
Now I have a customer that runs 64-bit office.
Is it possible to create a C++/CLI assembly that uses a native 32-bit dll and exports a 64-bit com interface?
No, you can't mix code with different bitness in one process on Windows. You need to force 32-bit code into a separate process or convert that DLL.
The latter can likely be achieved by using COM+ (or DCOM which is mostly the same). This is what we usually do with native C++ code. I'm not sure about how easy it is with C++/CLI assemblies.
In a manner of speaking, yes.
Continue to compile the C++/CLI code as 32-bit so it can use the native library using C++ interop.
Then you will have to configure it to load as an out-of-process COM server when acting as an Office 64 plugin. With native COM code, midl automatically generates the 64-bit proxy. There should be some similar capability to create a proxy when registering .NET classes marked COMVisible.
The 64-bit COM interface will be contained in the auto-generated 64-bit proxy DLL, so this doesn't violate the rule that the bitness of all modules in a process must be the same.