Using Registration-free WinRT it is possible to load WinRT components inside Win32 application.
What's the process to load WinRT component from inside Win32 dll? I tried the steps mentioned as part of Win32, but winmd files are not generating the corresponding header files.
Main usage scenario is dll can be loaded any application, like electron node addon or c# app etc.,
Without any changes to application, dll by itself should be able to consume WinRT component!
Did you add a reference to the WinMD file in the vcxproj and then installed the C++/WinRT NuGet package? This should make it generate the corresponding header files that your DLL project can then consume.
Following is the solution:
Was able to fix this in weird manner i.e. not a standard way to solve this.
Our use case was to use FFmpegInteropX inside win32 dll, so that we can use ffmpeg as a source reader and use the underlying hardware decode support. Mechanism is discussed detailly in the following link:
https://github.com/ffmpeginteropx/FFmpegInteropX/discussions/275#discussioncomment-3091100
Following changes were done to use WinRT component inside a Win32 dll:
Copied the WinRT generated files from the application to Win32 dll project
Before invoking any of the api from the generated runtime class, did LoadLibrary of the specific WinRT component into the dll
Now the make the necessary WinRT component call as it was done in standard win32 application
All modules were working as expected.
Above solution was copied from:
https://learn.microsoft.com/en-us/answers/questions/924996/how-to-consume-winrt-component-inside-win32-dll-pr.html
It's not a straight forward solution, also not sure if MS has any plans to add support for WinRT component inside dll project, if such support comes up then this may not be needed.
Related
I'm trying to call the GetDoubleClickTime Win32 API function using C++ from a new project created with the "Windows Runtime Component (WinUI 3)" Visual Studio template.
To do so, I'm adding #include <Windows.h> to the pch.h file and then simply call the mentioned function. However, I'm getting the following compiler error afterwards: error C3861: 'GetDoubleClickTime': identifier not found.
According to the template description, this project should create a library that is both usable in Desktop and UWP apps. I'm aware that the GetDoubleClickTime function cannot be called from UWP. But it has to work for Desktop apps.
How can I make this work?
Apparently it creates a sandboxed UWP project behind the scenes. Please refer to this GitHub issue and see #sylveon's comments at the very bottom of the conversation for a potential fix/workaorund.
You can edit the vcxproj's global PropertyGroup and add these two directives right now to force the UWP project to use the desktop API set, and link the desktop CRT (removing the need to carry around the VCRT forwarders, which are honestly a terrible hack)
<_NoWinAPIFamilyApp>true</_NoWinAPIFamilyApp>
<_VC_Target_Library_Platform>Desktop</_VC_Target_Library_Platform>
Alternatively, it seems that merely setting <AppContainerApplication>false</AppContainerApplication> works as well.
I have created a DLL that are using VCL components in its code. The DLL is hiding all C++ code behind a C API.
Using the DLL works fine in a console application.
However, when trying to use it in a regular VCL forms application, I get errors when any code is trying to view VCL frames or forms, e.g.
I suspect this has todo with linking in the VCL into the DLL.
Question is, do one have to prepare the creation of a DLL using VCL components in some way to avoid this problem? I think it has todo with HINSTANCE somehow?
The reason for creating the DLL in the first place, is to be able to provide a pure C API, so that the code can be used with other compilers, e.g. Visual studio. I would use a package otherwise.
I'm trying to reference a VB.NET DLL in a Xamarin.Forms (Portable) application. During the course of my research, I found the following post that might allow this: Xamarin.Android and VB.Net Libraries
I've tried to use the "Embed" work-around mentioned in the link, but the Xamarin.Forms project would fail to build because it can't load the Microsoft.VisualBasic assembly, version 8.0.0.0.
I've also found the following link as well during my research that should allow at least some VB.NET usage in a Xamarin application: https://developer.xamarin.com/guides/cross-platform/application_fundamentals/pcl/portable_visual_basic_net/xamarin-forms/
At the bottom of the site, there is a "Limitations of VB.NET in Xamarin.Forms" section. With the last item: "Xamarin does not support the Visual Basic.NET language," does that simply mean that you can't use a VB.NET dll in any Xamarin.Forms (portable) project that happens to also reference Xamarin.Forms.Core, Xamarin.Forms.Platform, and Xamarin.Forms.Xaml?
Thanks for any insight!
A DLL doesn't contain it's dependencies. If your DLL relies on Microsoft.VisualBasic, you will need to load the DLL that contains that assembly as well.
So either remove the Microsoft.VisualBasic assembly reference from the VB DLL, or include it as a reference in your Xamarin project (which may or may not be possible, I am not sure.)
Say, that we have .NET application App along with additional assembly ClassLibrary, which, in turn, uses native DLL called Library. All these are in single solution, so I may set up the dependencies etc.
The catch is, that I want the Library to be automatically "attached" to ClassLibrary, such that when my App references it, Visual Studio will automatically copy the Library to target bin folder.
Usually I did that by using pre-build or post-build events and adding custom scripts. But hey, all these are in the same solution. Is there simpler way to keep such native-dll-reference for .NET assembly?
You have to add the native library to your project. If the native library is in the Solution (not in the project) than it is there only for your reference. You have to add the native library to the Project because the project file describe the build behaviour.
Than add native assembly to the ClassLibrary project and then in properties set: Copy To Output Directory to Copy if newer or Copy always.
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.