I have a need to create a C++ non-dotnet DLL that will be called and used by a VB.net application. I am trying to determine the type of DLL to create. The DLL will contain some classes, variables, and functions that I will be writing. I understand that there are three types of a DLL that can be created: 1) Regular DLL - Statically Linked to MFC, 2) Regular DLL - Dynamically Linked to MFC, and 3) DLL that uses the Standard Windows Libraries, non-MFC.
My question is, which would be the best to use, one that is linked to the MFC, or one that uses the standard windows libraries? Can someone make a suggestion and explain the differences between MFC and the standard libraries?
Thanks!
Gary
Microsoft Foundation Classes (MFC) are a relatively thin C++ wrapper around the Win32 API, with an emphasis on UI coding. You won't need to statically or dynamically link MFC to your DLL unless you are making use of MFC facilities such as its container classes or trying to display UI written with MFC in your C++ DLL. These are unlikely scenarios.
People have been calling unmanaged code from VB.NET since .NET began. There's a whole wiki available on the subject here at http://www.pinvoke.net/ and there's a useful walkthrough on CodeProject, http://www.codeproject.com/Articles/6243/Step-by-Step-Calling-C-DLLs-from-VC-and-VB-Part-2 as well. I recommend starting there.
It's a little more complex, but you can also write managed code in C++ by using C++/CLI that can be referenced just like any other managed code assembly instead of using platform invoke. You can use it to create VB-callable managed interfaces that call unmanaged, plain old C++ code. There's an introduction to C++/CLI on MSDN at http://msdn.microsoft.com/en-us/library/ms379617(v=vs.80).aspx and a quick example of using it as a shim for unmanaged C++ in this MSDN Blog entry: http://blogs.msdn.com/b/junfeng/archive/2006/05/20/599434.aspx
Related
I need to use a 3rd party code/dll in my .Net service. I did some research. But I can't find any direct answer for this. Mostly are recommending to port the code into VS C++ .net using a wrapper class. At the same time since there are VCL-headers used which has no replacements in VS C++. Can someone guide me on this please?
The VCL files in use are : Classes.hpp, Sockets.hpp and, ExtCtrls.hpp
Thanks in advance.
A DLL written in C++Builder works just fine in C# provided that the DLL exports flat C-style functions that use basic interop-safe data types and calling conventions that are portable across multiple compilers. Or the DLL implements a COM object (since COM has a standardized ABI). This is no different than writing any DLL that can be used in multiple languages including Delphi, VB, Java, Perl, PHP, etc.
You can't use VCL headers directly in the DLL's public interface, since VCL is not portable to non-Delphi/C++Builder compilers. But you can hide the VCL code behind an abstraction layer that is portable.
I recently added lua support in one of my c++ applications. The goal is that my application is the core and the users can access functions from my core using lua.
I have seen that it is possible to have syntax correction and auto completion like visual studio has. And that is exactly what I want to have, too.
How to I implement this feature? The lua file can be written inside a window of my application. Can I connect my c++ function pool with this lua scripting?
Any help on this would be greatly appreciated.
Fabian
Use Scintilla. It's crossplatform and is available as a library for different platforms and frameworks.
As an example, here are few links:
QScintilla for Qt4 and Qt5.
ScintillaNet for Windows Forms applications.
wxWindows has it already, and it's called wxStyledTextCtrl.
Sure, it is possible to use Scintilla even if you are not using any GUI editors and your application is pure code. It's just an external library, and can be either static (part of your binary after compilation) or dynamic (should be bundled with your application).
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
What is the difference between Managed C++ and C++/CLI?
What is CLI/C++ exactly? How does it differ to 'normal' c++?
I am in doubt of distinguishing between C++ and C++.NET.
Is that right C++ is unmanaged code and C++.NET is managed code?
I need to program for a project in C++. For better building the GUI, I would prefer to use C++.NET.
I also have another plain C++ library (unmanaged C++ DLL file), will it be possible to use it as a normal DLL library in the C++.NET project?
Is that right C++ is unmanaged code and C++.NET is managed code.
There's no such thing as "C++.NET". There's C++/CLI, which is basically C++ with Microsoft extensions that allow you to write code targeting the .NET framework. C++/CLI code compiles to CLR bytecode, and runs on a virtual machine just like C#. I'll assume you're actually talking about C++/CLI.
With respect to that, one can say standard C++ is unmanaged and C++/CLI is managed, but that's very much Microsoft terminology. You'll never see the term "unmanaged" used this way when talking about standard C++ unless in comparison with C++/CLI.
Both standard C++ and C++/CLI can be compiled by the same Visual C++ compiler. The former is the default on VC++ compilers, while a compiler switch is needed to make it compile in latter mode.
I need to program for a project in C++. For better building the GUI, I
would prefer to use C++.NET.
You can build GUI programs in C++ just as well as C++/CLI. It's just harder because there isn't a standard library in standard C++ for building GUI like the .NET framework has, but there are lots of projects out there like Qt and wxWidgets which provide a C++ GUI framework.
I also have another plain C++ library (unmanaged C++ dll), will it be
possible to use it as a normal dll library in the C++.NET project?
Yes. It might take some extra work to deal with the different standard C++ data types and .NET data types, but you can certainly make it work.
Managed C++ is a now deprecated Microsoft set of deviations from C++, including grammatical and syntactic extensions, keywords and attributes, to bring the C++ syntax and language to the .NET Framework. These extensions allowed C++ code to be targeted to the Common Language Runtime (CLR) in the form of managed code as well as continue to interoperate with native code. Managed C++ was not a complete standalone, or full-fledged programming language.
Managed C++
#using <mscorlib.dll>
using namespace System;
int main() {
Console::WriteLine("Hello, world!");
return 0;
}
Vanilla C++
#include <iostream>
using namespace std;
int main()
{
cout << "Hello, world!";
return 0;
}
Well... C++ .NET is kind of a misnomer.
You can program in C++ using visual studio .NET. Well that's what it was called along time ago. Now a days folks just call it Visual Studio, with the dot NET moniker. Well, at least the splash screen doesn't have a big ol .NET in the logo anymore.
It is kind of understood that using Visual Studio (VS), you can program in managed and unmanaged languages (Lots of choices there btw).
If you want to program in C++ using Visual Studio you have two choices:
Unmanaged or native C/C++. This is the old (or new I guess too) C++
that you have always known, and you program with unmanaged memory.
Managed C++. They call this C++/CLI. That is read C++ over CLI, not
C++ divided by CLI! This is C++ that has extra keywords, and a few
extra syntax elements than the native C++. This allows you to
utilize the .NET Foundation Class Library and do other fun things in
the .NET framework. This of course uses the garbage collector for
memory for managed types.
Personally my favorite language is C#, but if you need to interop between C++ and .NET than definitely use Managed C++. It is very easy to do, and I think is easier than that other P/Invoke stuff.
If you are going to some project, I would suggest you do your UI in C# and take advantage of all that it has to offer. Then have that reference a mixed mode managed library that contains your C++ code. I think that will be a lot easier for you.
The answer to your last question is yes, you can definitely use that in your app.
Here is how the dependencies would work:
[C# App/GUI] depends on [Managed C++ assembly] depends on [Native C++ Lib]
Yes, C++ is unmanaged code and C++/CLI is managed.
Yes, you can use your unmanaged C++ DLL in your C++/CLI project. But you have to write a wrapper for that. That means you have to define the unmanaged methods you want to access in your C++/CLI project.
Example:
using System.Runtime.InteropServices;
[DllImport("YourDLLName")]
public static extern void UnmanagedMethodName(string parameter1);
I currently have an old unmanaged C++ DLL using MFC. This DLL has a bunch of code which is multi-threaded and written back in 2003 using VC6. This code sadly doesn't work anymore.
I've been tasked with finding an alternative way of running this multi-threaded code so that it does function as intended. Someone before me had already rewritten it in C#, and I need to port that C# code over to VC++. I did some research and realized that I could save some time in the porting process by just porting the C# code to VC++ (using the .NET framework). But then I realized that my old MFC DLL cannot run this .NET code.
My idea is to write this multi-threaded code in a VC++ DLL (using the .NET framework) and using some form of interoperability to be able to call the functions from the old DLL to the new DLL.
I have looked into COM interoperability as well as wrapper classes. What is the best way of accomplishing this? Are there any tutorials that could help me with this task? (I've already done some extensive searching and there are a lot of tutorials using unmanaged C++ DLLs to C# DLLs, but not much that pertains to my situtation).
Just so you know, I cannot compile the old DLL with /clr as this DLL is hosted in an old Win32 application as well. Compiling with /clr causes the application to crash, or else this would have already been done.
TO CLARIFY: I'm curious as to why calling functions residing in a C# DLL from an unmanaged C++ DLL through a COM interop seems so simple compared to doing the exact same thing using a managed C++ DLL. I even have a proof-of-concept between C# and C++, but I can't for the life of me begin to understand performing the exact same task with C++. Does there happen to be just a simple tutorial for calling just one simple (let's say 'Add') function from unmanaged C++ to managed C++?
If you have a (managed) DLL, regardless of the language(s) it is written in, you need a process to run it in. If you have a native process that -- for whatever reason -- must not use the CLR, that you cannot directly use a managed DLL (any code that depends on the CLR in-process) from this process directly.
You would need a second helper process that runs the managed DLL and, for example, exposes a COM interface that the native process could call. (out of process COM server)
I have looked into COM interoperability as well as wrapper classes. What is the best way of accomplishing this?
Not sure what you mean with wrapper classes, but an out of process COM server for your managed DLL could do the trick. (Obviously, this is quite some overhand wrt. to managing the proper registration and startup/shutdown of the helper process.)
Breaking the problem up a bit (as far as I understand):
[oldish Win32 app (no! CLR)]
<- normal DLL interface -> [native/MFC DLL (no! CLR)]
<- via COM -> [stuff in a separate executable]
If this is what you are looking for, then this article (just a quick Google hit) may be helpful:
http://www.codeproject.com/KB/COM/BuildCOMServersInDotNet.aspx
For COM in general, I think any COM tutorial should cover what you are supposedly trying to do.
I am working with C++/CLI for C Library. I explored in the net about it. I got several links about it.
Mixed mode C++/CLI performance considerations - best practices
I am developing a C++/CLI DLL which will wrap a C static library.
There was one suggestion that I really wanted to discuss here is "One should not mix up managed and unmanaged C++ code in wrapper". I don't understand meaning of it.
The managed DLL will, of course, contain managed C++ code and unmanaged C++ code.
The purpose of the wrapper is to translate calls from the static library to managed code DLL.
Please clear my doubts - I wanted comments on this.
If you have a regular C++ library (non-CLI), you should avoid turning on the 'CLI' compilation option for that library, for performance reasons.
Instead it is good practice to create a library that just has your wrapper classes in it. This library will of course be C++/CLI, and will create an assembly that can be referenced by regular .Net libraries.
So that's probably what the advice would be talking about - create a wrapper library for your CLI wrappers
-- addendum for the updated question
A managed C++/CLI class should not contain unmanaged code because it /cannot/ contain many types of unmanaged code.
For example, a C++/CLI class cannot have any unmanaged member variables that are not references or pointers. This is because the .Net runtime garbage collector may decide to put the object somewhere else in memory at any time (this is the reason you need to pin memory etc.). If the GC decides to move your native C++ objects to some other place in memory, this will potentially invalidate any pointers you have to that object. This is obviously bad.
C++/CLI is a great language. If you use it, however, you should either decide to write pure .Net code, or you should use it as an interface between native C++ and .Net. Having mixed memory models in the same class just confuses things.