Wpf: WPF and CLR Net Core as part of C++ and with all DLL for Net Core. How to?

[DigitalPilgrim]

I created test project where is used WPF Core as DLL with CLR (C++/CLI) Core DLL in console C++ application. It runs ok until I tested it in second pc. I realized, that I need installed VC Runtime and NET Core "runtime" on second PC.
As I searched on documentation, NET Core can be deployed as self-contained throught publish button. Problem is NET Core doesn't have that option and WPF Core as ClassLibrary doesn't produce anything except some nupkg. It is strange because I don't select option to publish it as nupkg.

Question is, can be C++ application which use WPF DLL and CLR Core DLL as self-contained? If yes, how? I mean, user doesn't need install any NET Core to run my app. I hope it is possible, because this is main advantage (NET Core) I think.

[vatsan-madhavan]

Can you achieve what you are trying to do in a non-WPF scenario? In other words, if you maintain all parameters of your environment constant and just remove WPF from the equation, are you able to achieve your intended end-result?

[DigitalPilgrim]

vatsan-madhavan I am quite don't understand a question.
In C++ I can compile my program as static (everything needed (all necessary DLL) will be compiled in to exe) and if I don't need WPF it works on second PC, if this was question about. Even If I don't compile as static, I am able distribute necessary DLL (they are not too much compared to NET Core) next to my exe and it should work on second PC.
This is working for pure C++. If you ask for C++ and C++/CLI without WPF, as I understand how Core work, I still need publish C++/CLI as self-contained, but there is no option for that.

[vatsan-madhavan]

If you ask for C++ and C++/CLI without WPF, as I understand how Core work, I still need publish C++/CLI as self-contained, but there is no option for that.

That.

If you are able to do something in C++/CLI .NET Core project, and the addition of WPF into the mix makes things worse, then we can try to troubleshoot it.

If C++/CLI .NET Core lacks some functionality, and the addition of WPF into the mix doesn't change the underlying behavior, then our best course of action would be to redirect you to an appropriate forum where you can file this issue against C++/CLI experience.

I was trying to assess which category your problem falls into.

If C++/CLI projects do not have a publish-wizard (with or without WPF), then you'd have to report it to the Visual Studio Developer Community. You can do this easily by clicking on the _Send Feedback_ button in Visual Studio.

[DigitalPilgrim]

Aha, it looks like Publish button missing from CLR projects (with or without WPF I don't have this button available). I'll post it in the VSDev.Community forum.

One thing, when I publish WPF ClassLibrary, it should create similar action like for application? In other words, it should create folder with all necessary dlls?

[vatsan-madhavan]

For C# projects, I'm able to bring up the UI for RID-specific publishing of libraries as well (including WPF libraries).

[DigitalPilgrim]

If I understand you, then I think WPF ClassLibrary doesn't publish anything. That means under publish folder is nothing except one npukg file. (I had self-contained option selected)

[weltkante]

Publishing for class libraries means producing a nuget package. Publishing a class library as "self contained" or "folder of necessary dlls" makes no sense because nobody will use these DLLs, a class library is only usable as part of an application and the application may have an entire different idea what dlls are necessary (for example an application might need newer versions of assemblies you referenced in the class library, so deploying your references of the class library would just cause conflicts; resolution of these dependencies/conflict is part of the nuget package system).

[DigitalPilgrim]

And then how can I use C++ application with WPF as GUI (dll) without installing a Core runtime? Then I can't see diference between Framework and Core.

[weltkante]

You need to publish the application as self contained, not the class library. The application knows what it is referencing and should include your class library.

For example you could publish your C++/WPF components as nuget package, reference them from a normal C# WPF application, and publish that as self contained.

That of course assumes publishing nuget packages from C++/CLI works. If it doesn't work then thats a feature request against Visual Studio, not WPF, like discussed above in the topic.

You have always the option to not use VS-based class library packaging and just referencing the output of your class library directly (e.g. direct project references), then publish the application as self-contained.

[DigitalPilgrim]

I am afraid, you are not understand the problem. Or maybe I don't understand you.
C++ will be the main application WPF as only GUI. (there is no way use WPF or CLR use as application only as DLL in this scenario) Imagine someone create WPF as GUI only for C++ application. How can someone publish ClassLibrary as application? Convert it to application and back, and then use published folder with all DLLs from application?
And pure C++ doesn't have publish button and I am not aware it should have (it is not part of .Net). If yes, I will post it in to the D.Community forum.

[weltkante]

Class library cannot be published as application because (by definition) its a class library and not an application. If it were an application you'd not select "class library".

The problem with what you are trying to do is that publishing self contained needs to know information about the whole application, nut just part of it. So it needs to be done on the application. There is no option provided for "self contained library" simply because it makes no sense.

If you cannot use a C# application as the entry point (it could be pretty small, just calling your C++ class library from its main method) then you have to wait for Visual Studio to provide a "self contained" packaging option for C++/CLI applications, as this is not something you can reproduce manually without a lot of in-depth knowledge. There is more to publishing self contained then just putting the right DLLs in the folder, there is nuget dependency resolution happening in the background and there also are a few XML/JSON files to be generated to describe the results of the dependency resolution, and maybe some other stuff.

If you want to read up about C++ based .NET Core applications you could look for "hosting .NET core" and you may get further information on how to do what you want to do manually without having a C++/CLI publish option, but you'll probably have to do be prepared to do more work yourself because things like dependency resolution won't work out of the box.

[DigitalPilgrim]

Class library cannot be...

I think you not know what is really difference between DLL and EXE is. They are same thing with functions, structs, classes etc.. only EXE have entry point (one function which is called when EXE is invoked). Simple said.

Did you know that, WPF application can be used as whole DLL without entry point? Yes it is possible because it works exactly as I wrote above. Instead entry point, application is called outside DLL from C++ with another DLL (C++/CLI) . When this WPF application DLL is called (and it doesn't have to be application) it still search for system DLLs and all necessary DLLs to run WPF properly. Instead exe it is DLL.
You can exchange WPF with another C# object. When C++ call it, it still search necessary DLLs.

Now, I hope, you get sense, to why ClassLibrary should have option to export as self-contained with all DLL necessary. I am sorry but I don't know describe it better, I am only self taught programmer.

And little addition to better understand what I wanted to say.
It not make sense to you, because you think in .Net world. But thanks to CLR, C++ can use .Net, but C++ is not part of .Net. C++ cannot and don't have Publish option and all things that .Net have. There is difference when c# application use c# dll and native application use c# dll. Therefore I want have option publish c# DLL as self-contained.

[weltkante]

You are still missing my point. Self contained class libraries is not something .NET Core offers. Speaking theoretically, if you were to publish two different such "self contained class libraries" they would very likely select different versions of DLLs (due to being different libraries with different references), meaning you cannot load them both into the same process. Class library projects are supposed to be combined by a top level application project which resolves the dependencies and any conflicts between versions. This application project is what you are looking for to determine the DLLs you need to deploy and generate the configuration files required for the .NET runtime.

As long as VS does not support C++/CLI self contained publishing then what you want to do simply can't be done "out of the box" by the press of a button, so you have to chose

• If you want to stay within whats available you have to build a managed application as entry point which then calls your C++/CLI code, so you can use the self-contained-publish infrastructure thats available for such applications
• If you want to do exactly what you described/planned you are on your own and have to look into hosting the .NET Core runtime because what you ask for simply doesn't exist yet, so you have to implement it. This also means you are on your own resolving the dependencies (i.e. determining which DLLs you need to deploy).

You can probably mix both approaches by taking the DLLs produced by a managed self contained application and trying to integrate them into a custom host, but you're still on your own doing that.

PS: I'm just trying to help by explaining how things are as I understand them, you don't have to "convince" me about anything. I'm very well aware of the technical details and possibilities, the difference is about whats available out of the box and officially supported vs. what is theoretically possible.

[vatsan-madhavan]

And then how can I use C++ application with WPF as GUI (dll) without installing a Core runtime? Then I can't see diference between Framework and Core.

If I'm reading the question correctly, you are asking how to build a WPF application in C++, and then deploy that application on another machine without also having to install a global copy of the .NET Core runtime on that target machine.

The only way to build a C++ based WPF application today is to invent something that the product (WPF or VS) doesn't enable out-of-the-box.

WPF doesn't support markup compilation for C++/CLI, and our recommendation is to use C++/CLI as a "helper" language only, for building libraries that can otherwise not be built in C# (or VB). This is also consistent with the recommendation from the C++ team themselves.

That said, I'm sure you can find ways to build a native C++ application, that can act as a front from a WPF based GUI. For e.g., a native C++ application can bootstrap .NET Core - this is described in greater detail at Write a custom .NET Core host. @weltkante already alluded to this. This is an advanced scenario and you can not rely on turnkey solutions once you start down this path - be prepared to (re)invent every piece of the machinery that's missing or unsatisfactory, and you risk ending up in an unsupported configuration.

--

From your questions, I'm often unclear when we are discussing C++ and when we are discussing C++/CLI. They are different languages with distinct implications, and maintaining this clarity is somewhat essential.

.NET Core related publishing (self-contained or otherwise) would be naturally absent in (native) C++ projects. If you choose to combine the two worlds, it would be up to the developer to build the bridge between them.

C++/CLI projects on .NET Core currently do not have _application templates_. So I'm not surprised that functionality closely related to applications (as against libraries) - like self-contained publishing - is absent at this time.

[vatsan-madhavan]

@DigitalPilgrim I believe we have done our best to answer your questions, and any additional questions that are C++ centric would probably receive better attention from the C++ team in the Visual Studio Developer Community - we are not best equipped to help with C++ features here.

Let us know if there is anything else we can help you with.

[DigitalPilgrim]

Thanks all for detailed answers.

I apologize if my previous post "sounds" negative, but my english is not very well.

---

If I'm reading the question correctly, you are asking how to build a WPF application in C++, and then deploy that application on another machine without also having to install a global copy of the .NET Core runtime on that target machine.

Yes, except the how to build. I only don't know how to deploy it without having to install a global copy of the .NET Core runtime on that target machine.

But from Your posts, as I understand, it will not be possible, because library cannot be self-contained (weltkante).

---

Maybe it will be more clear if I describe it in different way, what I did, and why I can't understand, why library cannot be self-contained.

I have C++ project A as main application and use project B as C++/CLI .Net Framework (dll) as bridge to project C as WPF application .Net Framework (dll) . That means, (project C) WPF is created as application, but converted in to class library (dll) (simple said) and used in project B.
Project A is exe, project B and C are dlls. Project B is used by project A and project B use project C. (keep in mind this projects A B C, I will used it in my post as examples)

I did same with .Net Core and it is working. (With installed .NET Core globaly)

---

Speaking theoretically, if you were to publish two different such "self contained class libraries" they would very likely select different versions of DLLs (due to being different libraries with different references), meaning you cannot load them both into the same process.

I understand what you wrote about publish library as self-contained doesn't make sense. But it start make sense when one of the library is used as "application" from different "world" (native C++ application). My idea was, not use self-contained for all libraries I used, but for one library which is used as main dll. For example, project B from project A. Only project B should be self-contained and project C will be only one dll inside published project B. This was my idea about publishing library as self-contained.

---

Class library projects are supposed to be combined by a top level application project which resolves the dependencies and any conflicts between versions. This application project is what you are looking for to determine the DLLs you need to deploy and generate the configuration files required for the .NET runtime.

This is exactly what I want for self-contained classLibrary. But instead exe it will be dll. This is the project B scenario used in native C++ project (project A). You can imagine project B as application but it will be classLibrary.

Once this classLibrary is published as self-contained, it is not problem put there native exe and it should run, I think.

From test with DependencyWalker it should. Only some CLR dlls are missing.
(I test publish WPF Core application (project C) and convert it back to the library, then I build project A and copy files in to published WPF application)

---

If you want to stay within whats available you have to build a managed application as entry point which then calls your C++/CLI code, so you can use the self-contained-publish infrastructure thats available for such applications

I tried this idea (I created WPF application which use CLR), unfortunately it not working, it throw undefined error. I guess, because CLR doesn't have publish possibility.

Publish has encountered an error.
Publish has encountered an error. We were unable to determine the cause of the error. Check the output log for more details. 

A diagnostic log has been written to the following location:
"C:\Users\xx\AppData\Local\Temp\tmp6172.tmp"

// tmp6172.tmp
System.AggregateException: One or more errors occurred. ---> System.Exception: Publish has encountered an error. We were unable to determine the cause of the error. Check the output log for more details. 
   --- End of inner exception stack trace ---
---> (Inner Exception #0) System.Exception: Publish has encountered an error. We were unable to determine the cause of the error. Check the output log for more details. <---

System.Exception: Publish has encountered an error. We were unable to determine the cause of the error. Check the output log for more details.