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.
Related
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.
I have old C++ Winrt dll project created from C++ WInrt Sample, before project templates were available.
How do i update it to Winrt Runtime Component Project Template, without starting from new project.
I have checked project settings cant find anything conclusive that make both projects differ, but The new style projects work better with Runtime components, specifically you dont get error saying versions of Winrt are different when you try to access Idl generated header files.
Cheers
As documented at Introduction to C++/WinRT: Visual Studio support for C++/WinRT, and the VSIX:
Alternatively, you can convert an existing project by adding the <CppWinRTEnabled>true</CppWinRTEnabled> property to its .vcxproj file.
<Project ...>
<PropertyGroup Label="Globals">
<CppWinRTEnabled>true</CppWinRTEnabled>
...
Once you've added that property, you'll get C++/WinRT MSBuild support for the project, including invoking the cppwinrt.exe tool.
I have a project that I am developing that uses a third party COM library as a reference and I would like to build this project on a Visual Studio Team Services build client. My first idea is to create a MSBuild task that checks to see if the COM library is installed on the local computer and if it is not, go ahead and install it, but this seems like a really messy way to do this. I have searched around but it seems as though all the answers date back years and I can't seem to make the few I have found work in a VS 2013 project. How have other people solved this problem? Is there a cleaner way?
For reference I have also tried this solution, which looks really clean, to no avail.
I would go one of these routes:
Generate interop dll with tlbimp, add it to your project and reference it directly:
In VS command prompt, execute tlbimp.exe <your_dll> to generate the interop dll. You can specify the name with /out option.
put this dll somewhere with your code
reference it by going to Add reference > Browse and click Browse... to add the dll
Generate the tlb from COM dll , add it to the project and reference the tlb:
Generate the tlb (e.g. using OLE/COM Object viewer) or extract it from the dll resources,
put this tlb somewhere with your code
reference it by going to Add reference > COM and click Browse... to add the tlb reference to project
As #HansPassant noted in comments, this solution still relies on registry, but you can register it with regtlb, regtlib or similar tool, as a prebuild step, which should be easier than installing the server (though if it is just a dll, you could use regsvr32 to register it instead of full install). However, this is still more complex than the approach with interop dll
I downloaded two DLLs (libgit2sharp.dll and git2.dll) from this site.
After that I successfully added Libgit2sharp.dll by add reference in my .NET Windows application. Now when I add git2.dll by add reference in my .NET Windows Application, it gives an error:
a reference to 'C:\User\nitesh\git2.dll' could not be added please make sure that the file is accessible and that it is a valid assembly or COM component
Can anyone please help me understand the problem?
I downloaded two DLLs (libgit2sharp.dll and git2.dll) from this site.
First off, this is not a distribution channel that the libgit2/libgit2sharp team has anything to do with.
Install as a NuGet package:
Official releases are available as a NuGet package if you prefer to download pre-built sources. See this post which explains how to install the NuGet Package Manager in Visual Studio.
This is the easiest way to make LibGit2Sharp available to your project.
Build from the source code:
You can download the source code and build the C# code into LibGit2Sharp.dll from https://github.com/libgit2/libgit2sharp, which includes the pre-built version of git2.dll which works for the particular version of the C# code.
Easiest way to build the assembly is by launching the build.libgit2sharp.cmd. This will create a Build folder into which you'll find the LibGit2Sharp.dll and a NativeBinaries folder with the native binaries.
Now when I add git2.dll by add reference in my .NET Windows Application, it gives an error
As for the error message, it sounds like you're trying to add the git2.dll to the project as though it were a CLR/.NET assembly. It is however built from C and isn't something VS is going to do anything useful with. You do not need to add it to your project.
It does need to be available for libgit2sharp to load. The following graph depicts the folder hierarchy that libgit2sharp expects
NativeBinaries+
|___amd64+
|___git2-{shortsha}.dll
|___git2-{shortsha}.pdb
|_____x86+
|___git2-{shortsha}.dll
|___git2-{shortsha}.pdb
Note: This folder structure will be dynamically created in your project output folder if you installed LibGit2Sharp as a NuGet package. However, if you built the project from the source code, you'll have to copy this folder structure as part of your project build process yourself.
I have downloaded a .exe file that when executed (in wine) it puts two dll's in the system32 folder and a dll in the "Common files/App-name/" folder.
In theory, the installing of this file creates a tab in Visual Studio that appears when referencing and it is a COM library.
I have tried to reference these dll's in my console project but I get a message of "Is not a valid .Net assembly".
Is there something I can do?
MonoDevelop does not have support for adding COM references directly. You will have to use tlbimp.exe to generate a wrapper dll, then reference that. This is essentially what VS does transparently when you reference a native COM dll.