I want to use WPF in an app. I want to write it in C++. Does the application have to be managed? I know that I can mix managed with unmanaged. I'm wondering if I can have the whole application be unmanaged.
You can easily develop 99% of your WPF application in unmanaged code, but making it 100% unmanaged is quite difficult.
WPF classes don't have a Guid attribute, so they won't work with COM. So constructing WPF objects such as Button and Window with 100% unmanaged code requires one of the unmanaged CLR APIs. The Hosting API is probably the easiest, but it is still quite a bit of work.
If you are willing to accept 99% unmanaged code, just compile your application with the /clr option and use IJW to instantiate WPF objects and call methods like Application.LoadComponent.
Also note that WPF binding to unmanaged objects requires that those objects fully support COM including IDispatch.
As you already know, you can mix managed and unmanaged via interop; however, WPF runs on the CLR.
Here is an article on the Web where some folks speculate about a future unmanaged version:
http://neilmosafi.blogspot.com/2008/07/unmanaged-version-of-wpf-coming.html
Here is an additional reference on WPF/native interop, should you choose to go that route:
http://msdn.microsoft.com/en-us/library/ms742522.aspx
Related
I have to use a DLL in my project that is a .NET assembly. I have to use C++ for this project. I'm a relative beginner to programming, so my knowledge doesn't extend too far. I was told COM Interop is one way to get the DLL to work in my project (the other being C++/CLI). The problem is I have ZERO idea how to begin, as I've never done anything like this before, and the Microsoft documentation on the matter isn't really helping.
If anyone can even point me in the right direction, that would be much obliged.
Here are some good resources to get you started:
Introduction to COM
COM from Scratch (Covers using COM from C++)
MSDN's section on COM
That being said, you'll also need to make sure that your .NET project is setup to expose the classes via COM. Make sure to turn on Register For COM Interop in your project settings, and flag appropriate types with [ComVisible(true)] (Unless you make the entire assembly ComVisible, in which case you would flag types you don't want to expose with [ComVisible(false)])
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 have an ATL COM service which I can connect to via my Windows Forms Application .NET4 application, written for the most part in managed c++.
I can successfully retrieve a pointer to the interface (via CoCreateInstance()), but run into issues when attempting to implement an event sink. I wish to create an unmanaged c++ class in the application which implements an interface defined by the COM server, and receive events from the ConnectionPoint. What I've got so far:
Realising this isn't possible using a managed (ref class) c++ class, I'm using a normal unmanaged class.
Not being able to use any ATL macros, I need to implement the IUnknown abstract functions (AddRef, Release, QueryInterface etc) in the sink class.
I can retrieve the IConnectionPoint pointer for the interface, but the call to Advise() returns E_NOTIMPL. This leads me to believe that i've missed implementing some ATL base functionality somewhere, but I'm not sure where to start.
As an aside, i've found very little resources on the net about using COM in a managed c++ project. The closest i've come to is this article. Does anybody have any good reading on this subject? It's mangling my brain at the moment.
In your managed C++ application add a reference to the COM server using "Add reference" option, this will create a managed wrapper (assembly) for your COM component which you will be able to consume in your "managed c++ code". The events in your COM component should be available as .NET events which can be handled using regular event handling in managed C++.
From your description it seems that you are trying to consume the COM component in your managed C++ application using unmanaged code, which is making things complicated. Mixing managed and unmanaged code should have clear boundaries and jumping too much in and out of these boundaries will make things complex and will lead to other serious issues. Hence I suggest you to consume the COM component using "managed code" (c++) only bu creating the managed wrapper for the COM component.
Can I have managed code within native code?
There are quite a few ways to do this.
You can code in C++/CLI, the managed C++ compiler provided by Microsoft. You can mix managed and native code as you wish (security restrictions may apply).
You can go the COM route, and it's natively supported on the .NET side. Harder to program on the native side though, especially all the interop. You can start here: http://msdn.microsoft.com/en-us/magazine/cc163494.aspx.
The 3rd way is to "host" the .net runtime engine directly into your app and use it to load managed assemblies and then execute parts from them. This may be overkill for you, but it generates a 100% native image and doesn't rely on COM interop. You can start here: http://msdn.microsoft.com/en-us/library/dd380850.aspx.
Some classic Windows/C++ applications can't easily be moved to managed C++.net, due to use of external libraries. Is it feasible to use newer GUI libraries like winforms (or even WPF) with such applications, 'dropping in' new controls to replace stale-looking MFC?
Or is it not really worth it, and would take a lot of time?
I've found that C++/CLI is very capable. Are you actually running into problems? It should be able to compile your MFC project directly.
But mixing WinForms and MFC within the same thread could be difficult as they both want to run their own message loop. As Ray Burns has suggested, WPF may be more cooperative with MFC.
Because of IJW it's quite easy to use WinForms or WPF from unmanaged code. More lilkely, though, you'll want to write the new components in managed code and just embed them in your unmanaged application. That means that for all the new stuff you won't have to deal with memory management, etc.
WPF is much more powerful and nicer to use than WinForms, so I would definitely bypass WinForms if you haven't been using it already.
One consideration is you'll want to take advantage of the data binding power of WPF. To do this you'll need to expose your unmanaged data as COM classes or copy the data into managed code. An easy way to do this is to write managed wrapper classes in C++ that access the unmanaged data. Another easy way is to directly access the business object layer (or database) from managed code. It depends on exactly what your current data layer looks like.
A better approach would be to create a new .NET project (C# is your friend) for your UI, and reference your C++ DLLS from there. You're not going to have an easy time mixing managed and unmanaged code in a single project.
See How do I call unmanaged C/C++ code from a C# ASP.NET webpage. It talks about a web page specifically, but the code is identical for a winForms or WPF app.
It's not really worth it, and it would take a huge amount of time.
It's possible to have unmanaged C++ code host the CLR, and to have the managed code run the UI.
But, it's definitely not a trivial task.
An easier approach would be to rewrite the unmanaged code a bit to be invokable via P/Invoke or COM interop, and have a managed app (with winforms) call the unmanaged code.