I have a C# project which needs to use (DllImport) the specific version of some C libraries developed (let's call them CommonLib) here at my company. CommonLib is available company-wide via a private vcpkg registry hosted as a Git repository. Our C++ projects use vcpkg in manifest mode thus is really straightforward to pass them around and get the right CommonLib version when building.
Obviously that isn't true for C#.
How can I automatically get the right version of native dependencies for a C# project when building, the right way?
I found some articles explaining how to wrap native libraries into nuget packages but my problem is to actually get them automatically from the registry during the build. I also found out that nuget packages can be exported from vcpkg but unfortunately this is not possible in manifest mode.
Related
I built a class library as a NuGet package to be used in another C# project. When I built the class library, I followed a tutorial that suggested targeting .NET Standard 2.0.
I installed the package into the other project and it builds fine. However, I've noticed that the output folder contains several other 'System.' dlls (ie. System.AppContext.dll).
In the past, when I've built a class library for C++, I did not get the dependent dlls copied to the output folder. I had assumed that building a C# class library would act the same way. For C++, those dependent dlls are resolved at runtime by the C++ redistributable dlls. I thought the same would be true in that C# would resolve them through the installed framework.
So, I'm a bit confused as to why the extra dlls are present in the output folder. Is it because I targeted .NET Standard 2.0? Do I need to ship the extra dlls with my application?
I have a library called foo, which is written in C++/CX. I chose a Windows Runtime Component because I want it to be projected into C#, C++ and JavaScript. Also, I want to be able to distribute the library, and I don't want to require/allow the consumer to load my project, along with the source files, in the same solution as their project.
The instructions on MSDN only demonstrate how to include the Windows Runtime Component project in a solution with the consuming C# project. I know there is a way to only distribute the binary, but I don't know how.
This question has been asked a thousand times, but the answer always has the two projects in the same solution, is incomplete or a workaround.
I'm using Visual Studio 2013.4 on Windows 8.1.
One way to do it is to create a VSIX package of your component. See Walkthrough: Creating an SDK using C++ that shows exactly how to do this with a WinRT component consumed by a C# project.
I researched and found the answer... It is not documented well, it is not intuitive, but it's worth the trouble when you see how well a Windows Runtime Component works.
Compiling the C++/CX library:
Make sure you compile the library for all permutations of Debug and Release, in Win32, ARM, x86 and x64.
Instructions for consuming in C#:
Right-click on References in the Solution Explorer, and add a reference to the Microsoft Visual C++ Runtime Package v12.0. Then add a reference to the binary you created with the appropriate configuration for your project (i.e. Debug/ARM). This step is tricky, because the file filter prompts you for the .dll, but you need to set the filter to *.* and select the .winmd file. Then you unload the project, find the <Reference> tag for the library you just added. <Reference> will have a <HintPath> tag below it, and under <Reference> you will also need to add <IsWinMDFile>true</IsWinMDFile> and an <Implementation> tag pair loaded with the name of the .dll that was sitting in the same folder as the .winmd file.
For more detailed instructions and information, I highly recommend visiting Mike Taulty's Blog
So i'm kind of new to programming but i started using Xamarin and i tried to add NHunspell package from NuGet on Xamarin Studio, it downloads it and the .dlls appear in Resources and NHunspell appear in Packets, but it doesn't appear in References and so when i try "using NHunspell" it doesn't work.
I have tried running the "install" script with Power Shell but apparently nothing changed.
How do I add NHunspell to my project?
Not every .NET library is compatible with Xamarin. They generally have to be either built against the appropriate Xamarin Framework, or build using a compatible PCL Profile.
scan.xamarin.com can tell you if a given DLL is compatible or not.
As I answered you already per Email the problem with NHunspell is that it is in fact an wrapper to Hunspell. Hunspell is written in c or C++ so it compiles to a native Dll. At this time the build produces two native DLLs for Windows 32 Bit and 64Bit. It would be necessary to produce native DLLs for ARM / Android or Linux or ... to use it on these platforms. I will do this for X86/X64 Linux in the future. But at the moment I'm snowed under so there is no timeframe. If you or someone else is willing to contribute, you're welcome.
BTW. NHunspell has an resolver for the correct native DLL. If your project has the native DLLs in the output directory, it resolves X86 or x64 in windows. You can do this in Xamarin studio by adding the native DLLs in your project and configure "copy to output directory". But this works only in Windows.
The latest packages (without NuGet) are here:
http://download.crawler-lib.net/NHunspell/
I just am trying to replicate my distributed C# project structure to WIX setup projects. Now there is the following problem:
LIB: a C# library solution that builds AnyCPU .NET dlls from several C# projects
APP: the dlls from LIB are referenced (as file references) by this main application solution. Additionally there are platform dependent libs included in this application solution, therefore it is important to being able to create setups for the two specific target platforms x86 and x64.
Now I started to create a wixsetup project within the APP solution (which works fine). Then I proceeded with creating a wixlib within the LIB solution that references the LIB .NET dlls into the wixlib.
Now the problem:
The wixlib references the AnyCPU .NET dlls within a DirectoryRef which seems to be platform specificly tagged when creating the wixlib. Therefore I have to go back to the LIB solution, build the project with one platform target, copy the built files (via SVN externals mechanisms) to the APP solution, build this project with the exact same target platform as the wixlib was created with and repeat this procedure for creating the other platform.
It may seem that this is kind of complicated, but doable. Due to the fact that I omitted several other library solutions for which the same problem applies and the fact that all those libraries are used in multiple application solutions and - finally - everything has to run on our build server automatically as well, it is clear that this will not work.
I know of the following solution, though:
Double the .NET dll references within wixlib to assign them to different DirectoryRef INSTALLDIR and INSTALLDIR32 e. g. and to implement those different directory references in the wixsetup.
But this would complicate things as well and is not my preferred solution therefore - if there is an alternative.
If there is no smart alternative, just tell me and I will do things as described in the last paragraph.
I am using a third party dll file which is referenced within a visual studio project using C#. In previous experiences on other projects, I was able to load objects from different dlls using dllImport, then create objects as if the source code of the dll was included in my project. However, that method is not working with the 3rd part dll. The program works flawlessly on the computer I am programming it on, however, when I run it on a different computer, it cannot find the dll. Is there a method to include the dll compiling and avoid using dynamic linking?
The default setting of .NET Framework is to load native libraries from system paths, not current directory.
But you might learn from System.Data.SQLite project (open source), so as to pre-loading native libraries from current folder, and based on OS bitness,
http://system.data.sqlite.org/index.html/doc/trunk/www/downloads.wiki
Although generating a mixed mode assembly (native and managed bits are merged) sounds like a better solution, System.Data.SQLite users often are confused. Thus, I recommend the pre-loading approach.