Description
I am trying to create a project that will create a DLL file (.COM managed DLL) using VS2010. This DLL will be loaded in VB. Also, I will be using STL in my dll.
Already Tried
1 - Created Visual C++ -> win32 -> Win32 project -> Next -> selected DLL -> ticked export Symbols -> Finish. Will this be a managed .COM DLL? How do I check? Will this DLL be working on 64-bit operating system as 64 bit dll or as x86 dll?
2 - Created Visual C++ -> MFC-> MFC DLL -> Regular DLL using shared MFC DLL
Will this be a managed .COM DLL? How do I check? Will this DLL be working on 64-bit operating system as 64 bit dll or as x86 dll?
Also, There are other two options Regular DLL With MFC statically linked and MFC extension DLL. I don't prefer the first one because it makes it harder to upgrade my dll in the future, And I don't know what the second one does?
Are there any other options I can use to create DLL?
If possible, you should eliminate the requirement to use STL and COM and just create a managed assembly. A managed assembly can be consumed by managed code and can publish events for use by managed code. In Visual Studio, this would be a CLR -> Class Library project.
If you must use STL and COM alongside managed code, then you'll need to create a mixed mode DLL. That's not simple to do, and I don't recommend that route if you have limited experience.
Alternatively, if you can eliminate the requirement for managed code, then you can create a native-only DLL that implements COM interfaces. COM interfaces can be consumed by native or managed code, but they require registration before use and a managed wrapper for use from managed code.
Related
In Visual Studio (C#), ticking 'Register for COM interop' updates the Windows environment such that my Visual Studio project, its dependent Visual Studio projects (in same solution) & dependent DLL files are all available for another COM-consuming application on the same machine. This COM-consuming application works with no issue.
If I want the same COM objects to be available to a consuming application on another machine, what must I do?
I assume I still build with the same flag set (so that the DLL files have COM content)? I assume I must register the COM DLL file (e.g. regasm) - Unfortunately this doesn't work - do I register every DLL file that I am constructing & every DLL file library they reference?
Please make no assumptions about my COM knowledge.
You don't quite provide enough information to answer with certainty, but there are enough hints to guess at what you are doing.
When your client app asks for the COM object, the .NET runtime is invoked and it locates the COM-exposing assembly DLL from the information stored by RegAsm (specifically by the /codebase parameter). But after that, it's all .NET assembly loading rules - including the loading of dependencies.
If your COM assembly has dependencies, the dependent assemblies must be locatable from the client process. It doesn't matter whether the dependencies are in the same folder as the COM DLL - the one loading those dependencies is the process, not your COM DLL. The .NET runtime uses a process called Fusion to decide where to look for .NET assemblies.
You have two practical choices:
Put the COM DLL, its dependencies and the client EXE all in the same folder. This works if there is only one client, and you control the client (so, don't do this if the client is IIS, for example). It's the simplest solution.
Give all the .NET components a strong name and deploy them to the GAC1. You still have to run RegAsm; but don't use the /codebase argument.
It is also possible to customize the Fusion rules by giving the client app a manifest with the proper entries, but that's too much of a hassle. The other options are more practical.
If this doesn't describe your problem, then I would use a combination of SysInternals' (now Microsoft's) Process Monitor and the .NET fusion log functionality to look into where the process is seeking the different DLLs.
1Technically you don't have to put the main COM DLL in the GAC, but it makes no sense to use /codebase for the COM DLL when you have to deal with GAC anyway. At that point you might as well put them all in the GAC
I have a somewhat odd problem that I don't seem to be able to get to the bottom of. We have a mostly unmanaged C++ application that's been around for a while and thus has been built using lots of different versions of Visual Studio, with it being updated to the current version of Visual Studio on a regular basis.
I've now run into the following issue:
In VS2010 I've added two new projects to the existing solution. Both new projects are DLLs, one built in plain unmanaged C++, the built using a mix of C++ and C++/CLI and is thus built with CLR support (/clr). The second C++/CLI DLL should be used by several other components of the system
Using Properties -> Common Properties -> Framework and References, I add the two new DLLs as a dependency to a third DLL. The third DLL is doesn't know anything about .NET and is implemented in pure native, unmanaged C++. The new DLLs show up correctly in the dependency settings and the new references work in the sense that the build order of the solution is affected (correct), but for some reason, only the import library for the plain native C++ DLL is added to the linker command line for DLL that references both libraries. The second, mixed library generates an import library, but VS2010 doesn't add the import library to the linker command line which predictably results in several unresolved external symbols.
The one setting that appears to trigger this behaviour is building the DLL with Common Language runtime support as all the other settings of the libraries are identical.
I currently have a workaround for this issue - I simply add the import library as a manual dependency - but I was wondering if someone else has encountered this problem and if there is a way to get make this feature work as expected without the workaround?
I have a communication library built on top of Qt and Google Protocol Buffers. It's currently being built with MinGW/GCC on Windows. My goal is to use the same library in C# on .NET, with the help of a thin wrapper on top using C++/CLI (bridging the unmanaged code with managed code).
I tried using the MinGW produced DLL directly in my C++/CLI project, but I keep getting linker errors (cant remember the error codes right now, but something about missing tokens and functions/signatures).
First question is: Should I be able to use the MinGW-produced DLL with the Visual Studio compiler/linker? Or do I need to compile the library again, using only VS compiler for all projects?
If I should be able to use the MinGW-produced DLL directly, how do I reference it in Visual Studio 2010? In project settings it seems to look for *.lib files, but I can't find any .lib files in the output of MinGW/GCC. It does produce *.a files, but it seems like Visual Studio don't handle this kind of file..
I should also mention that both Qt and protobuf are also compiled with MinGW. But I can of course recompile all the parts in VS 2010 if necessary.. Would have been nice to save the recompile time though, since our buildserver already has a working setup using MinGW.
The easiest way to use it would be by recompiling it with Visual Studio. This is when I am assuming C++ types and classes used in the interface you intend to use.
In case you have a C interface to this library you could dynamically load the library via LoadLibrary and use GetProcAddress to access those functions.
However it depends completly on the way how you intend to use the library.
I'm having some troubles debugging a solution which contains both a native ANSI C DLL project and a managed C#/WPF application project.
I call the functions exported by the DLL using the LoadLibrary/GetProcAddress Win32 API functions (DllImport attribute is not applicable for my program as the DLL is selected by the user). Both projects are built using the Debug configuration. The native DLL is copied to the bin/Debug directory of the C# program. When I debug the C# project, I can't step into the native code.
Is there a way to step into the native code?
It works when I debug the DLL project using the C# program, but then I can't step into the managed code...
I'm using Visual Studio 2010 Professional and Visual Studio 2010 Ultimate.
lg,
Dominik
In your C# Project: Project + Properties, Debug tab, tick "Enabled unmanaged code debugging". Single stepping from managed code into unmanaged code isn't going to work. You need to set a breakpoint on the DLL function you want to debug.
In the past we experienced some problems using a DLL library created with Visual Studio 2005 in our Visual Studio 6.0 application (VS2005 DLL was C++ unmanaged, of course). In your opinion can we fall in the same kind of problem if the library is static (*.lib) and not dynamic?
It seems like the problem area would be the runtime libraries -- if the VS2005 DLL is using the DLL versions of the runtime libraries, then you would need both sets of runtimes installed when the application is installed. If your VS2005 DLL is statically linked to the VS2005 runtime, then it should be OK.
Microsoft recommends that unmanaged DLLs must be compiled with the same CRT / STL as the main application. And the main application and the DLL should be using dynamic linking with the CRT.
If the DLL implements a pure C-interface or a COM-interface, then it should be possible use DLLs from another version of Visual Studio. But if the DLL doesn't use static linking of the CRT, then it will require that the CRT-dlls are available.
It depends on what kind of problems of course. There are some conflicts that are more likely to occur in DLLs and some that are more likely to occur in static libs. If you are building against the same version of the Microsoft SDK it will minimize the problems.