Im trying to use the libgit2sharp library. My only code is
Repository repository = new Repository(#"C:\Path\To\Repo");
and when i run it i get an error saying Unable to load DLL 'git2': The specified module could not be found. So, I manually went and grabbed the git2.dll from libgit2sharp and moved it into the directory. When running the same program after that I get another error: An attempt was made to load a program with an incorrect format.
While researching this I found this post and the solution that seemed to work for the poster there didnt work for me. That post was also made a year ago and a supposed fix was made for it, Im using the latest branch of libgit2sharp (ive tried older repositories no change)
Any ideas?
The recommended option would be to install the latest LibGit2Sharp NuGet package which will take care of installing everything in the correct location.
However, if you prefer to handle this by hand, the GitHub repository includes both x86 and amd64 version of the git2.dll. Performing a checkout of the master or vNext branch should retrieve them.
Beware that every version of LibGit2Sharp works against a specific version of the libgit2 binary. Each LibGit2Sharp branch contains a libgit2 submodule which points at the libgit2 commit being wrapped.
In order for it to perfectly work, the LibGit2Sharp assembly expects the git2.dll binary to be located into a specific tree structure.
LibGit2Sharp.dll
|__NativeBinaries
|__x86
| |_git2.dll
|
|__amd64
|_git2.dll
Related
I've been struggling with a problem in Unity and I would appreciate it if anyone can help me.
I'm using a package called DarkRift, which is used for networking and connecting clients with a server (provided by DarkRift). In order to work with the DarkRift server, I need to write plugins. A plugin is basically a visual studio project, compiled to .dll file, then that file is copied to a certain directory on the server-side.
I've been working with DarkRift for some time now and have done so much with it. It was working perfectly! However, I needed to work with Firestore package from Google.
Hence, I created another plugin, installed Firestore (and every package needed), wrote some simple code using one of Firestore's functions, compiled the project, copied .dll to the server, then ran the server. The problem is whenever I run the server (.exe file), I get an error that says: "Could not load file or assembly 'Google.Cloud.Firestore, Version=1.0.0.0, ...' or one of its dependencies."
I get this error when I use any of Firestore's functions. However, if I just include the package (using Google.Cloud.Firestore;) without using any of its functions, I don't get any error. I googled this problem and looked everywhere and could not solve it.
Thanks!
Firestore is distributed as a Nuget package, which indeed has dependencies.
Have you also copied all those dependencies to the server?
It might also be a framework incompatibility.
To get more details about this kind of problem, you can register a logging event handler on AppDomain.AssemblyResolve, which fires when assembly resolution fails.
You can also use tools like dnSpy to dig into the problematic assembly - it shows you all sorts of metadata and it can decompile the CIL, which is invaluable for debugging strange behavior in third party code.
Assembly loading is kind of slow in .Net, so it only loads them when needed.
Hence the resolution does not fail when no code references the assembly.
So, I'm having trouble adding a git project to my net Core solution, and after spending hours trying to figure this out and being uncapable of finding a solution online, I decided to ask here.
I have a forked github repo (link) in which I modified some files to suit my needs, but I simply can't seem to get it to work with my current project.
The problem I'm having is that normally, when I want a package for a .NET project, I usually simply go to nuget and fetch the necessary dependencies. This is usually very simple and straight forward. But now that I have these modified files, I'm unsure on how to proceed.
I have tried adding it as a submodule, but after I built the project, I got an exception saying that the dll could not be found.
Then I've tried adding the dll itself as a reference, but the ImGui.dll depends on a C dll which couldn't be found then (nor added to the project).
Finally, I've tried adding the csproj as a project of my solution, but that didn't work either
Do you know what am I doing wrong here? Am I missing a key piece or is it just something obvious I'm not seeing? It can't be this hard to get it to work
From the look of it, that repository produces a DLL (output type Class Library). So modify it to your liking, and use the sample program build (ImGui.NET.SampleProgram) to test your changes. Once you're happy, build the DLL project (ImGui.NET) and use the resulting DLL as a Reference in your own app.
In Visual Studio:
Solution Explorer>YourApp>References>Right Click>Add Reference...>Locate your DLL
This means you should also keep track of your modifications to the ImGui.NET project itself, since you may/will be required to maintain this in the future.
Hope this gets you started -- update your question with more specific issues once you're underway.
Edit:
Like #CoolBots mentions, I probably misread your question. Seems like the build depends on cimgui.dll, which you can hotlink from the ImGui repo along with your custom DLL. In fact, the demo app is using cimgui.dll, cimgui.dylib and cimgui.so. Regardless of linking method, you want the files to copy into your build folder. I don't believe subfolder /bin is necessary.
You can find all the cimgui dependencies for various operating systems in the ~/ImGui.NET/deps/cimgui folder.
The demo also utilizes NuGet packages Velrid and Velrid.StartupUtilities.
Depending on your own codebase, you may or may not require these NuGet packages along with the aforementioned class library.
I'm in dll hell.
I'm building a plugin for a huge, ancient and very powerful software suite called ANSYS. They have a plugin framework. I had hoped that they would magically handle everything for me via AssemblyContexts or AppDomains or some other clever dotnet device that I don't understand. They do not.
The result is that I've created an application that depends on GRPC.core 1.16.0 via nuget. I wrote a little application that drives my plugin with a winform host. It loads and works perfectly, finding my library in ~/myproject/bin/debug/grpc.core.1.1.16.dll that exists right beside the class-library that is my plugin, no problem.
When I run my plugin in the ANSYS process space, which happens to also depend on grpc 1.0.0.0, the linker finds C:\Program FIles\ANSYS\...\WIN64\grpc.core.dll. No Good.
One odd thing about the Nuget GRPC package is that it adds a reference with a "reference version" of 1.0.0.0, where most other nuget packages have their reference version match the nuget package version. If i manually change the reference version the compiler wont find the library.
<Reference Include="Grpc.Core, Version=1.0.0.0, Culture=neutral, PublicKeyToken=d754f35622e28bad">
<HintPath>..\packages\Grpc.Core.1.16.1\lib\net45\Grpc.Core.dll</HintPath>
</Reference>
edit: the key is in the above line. The Nuget published Grpc.core artifact is at AssemblyInformationVersion=1.16.1.0, AssemblyFileVersion=1.16.1.0, AssemblyVersion=1.0.0.0. I logged this as a request against GRPC. More Below.
Thus I need to tell the runtime linking facilities not to use grpc.core...dll found in ANSYS's own binary directoryWhats more, there is exactly one dll (and its dependents) that I wish to load from my parent processes context: and that's ANSYS API dlls themselves, which are probably already in the GAC. In my project I've included this as a non-nuget reference with "build action: do not copy" selected.
So my questions:
is there something simple and easy I can do at runtime to tell the runtime-linker "when somebody loads a type from an assembly you think should be grpc.core, do not load 1.0.0.0, find 1.16.0.0 exactly"?
the runtime was already matching the needed library by "strong
name". The problem is that the 1.16.0 is a misnomer. That version
string was informational, but the assembly itself was version
1.0.0.0. Fusion was loading the library I wanted by exact match already.
is there something smarter I can do with appdomains or contexts or another C# device to explictly enter some kind of nested scope? Could I go so far as to log this as a bug in ANSYS's API?
I've tried digging into this myself, but I'm not a dotnet expert and finding out whether I'm looking at a nuget package configuration option --which isn't relevant to me, or an old-fashioned dotnet runtime option, has been very tricky.
update 1:
I've tried using AppDomain.CreateDomain, and it does indeed solve my problem, but it also requires me to provide a marshalling strategy for the already-loaded API objects. In other words, if you're programming against a plugin framework that has an api similar to:
public void DoMyPluginsFunctionality(ApiProvidedInputContext context){
var myPlugin = AppDomain.Create(
strongName: "MyCompany.MyPlugin.; Version=1.2.3.4 ...",
baseDirectory: "C:\\Program Files\\MyPlugin\\bin"
)
//success! MyCompany.MyPlugin loads the version of GRPC I want!
myPlugin.unWrapAsDynamicProxy().doFunctionality(context)
//error: No marshalling strategy and/or not serializable and/or swizzling errors
}
Then the runtime will require you to marshall (serialize) the context variable, because .net will not let you share memory across AppDomain boundaries.
So my new question:
- given I cant use AppDomains myself
- given that Grpc.core is always published as AssemblyVersion=1.0.0.0
What are my options?
Stop using newer features of GRPC.core and live in fear of my parent processes dependencies
use a strategy similar to shading. Is there something like shading in the .net world?
Edit the published binary's version metadata. Can I dynamically edit a published binaries version?
rebuild GRPC myself with the version string updated --effectively a private fork of GRPC.
update 2:
The GRPC build system seems like its quite large and well maintained, so I'm hoping I can simply build it and change a vcproj file to include an updated version string.
Unfortunately it also seems quite complex, and I haven't quite got the targeting/cross-compiling (x64 targeting x86) worked out.
I'm currently working on my Bachelor-Thesis, which revolves around extending the functions of a Kinectv2 in an Unity-environment.
However, I have little-to-no experience with Unity and C# and whilst setting up the FUBI library (which will be a core of my Thesis), I ran into this problem right away:
Upon starting the Unity project (provided by FUBI), I get a
DLLNotFoundException: FUBI.64.dll
followed by a plethora of errors from failing calls on said library.
The confusing part, to me: Back in university we decided to use FUBI, because we managed to install it, outofthebox, with zero issues within a few minutes. But now, at my home tower (Windows 10 and Unity 5.3.5, just like the machine at the university), this error persists.
The Unity project and all required DLL's are provided in a single download from the FUBI-website itself, which implies that the error shouldn't lay in the project, the provided DLL's or any weird dependancys.
The only thing one has to do (according to FUBI's readme) besides unpacking the zip containing the project is:
IMPORTANT: After installing the Kinect SDK, please execute the "CopyFaceTrackRedist.bat" located in the FubiUnity base folder or manually copy the "Kinect20.Face.dll" and "NuiDatabase" from the Kinect Developer Toolkit to that folder.
Which I've done via the bat, executed flawlessy and had both mentioned files/folders copied into the project directory.
Whilst trying to fix this, I started manually moving the Fubi64.dll to various locations within the Unity project, but the only result was Unity mentioning it found multiple instances of said dll, would only use one, and then throw the exception nontheless.
I've started to think it may be a dependency thing, but downloading and using the dependencywalker gave me little to no useable results.
(I mean, it's showing some errors, but afaik those are related to DW not being updated and unable to work with some forward-dependency-shenanigans or something, according to some other thread on stackflow I've read.)
Any help, or even pointers at what to try next, would be appreciated.
Spending days chasing after the issue, I finally found one entry in dependencywalker that made sense and after manually installing MPFLAT.dll into windows\system32, Unity was able to load the dll just fine. I would assume it's some dll related to mediaviewer or associated tools, since those don't come natively with Win10, I didn't specifically install any yet and it is well possible the other mentioned tower had something installed that brought the DLL along.
To leverage R from my .Net website, i'm using R.Net (1.5.13).
To some extend this is working fine for me, but when i'm trying to reference an external R package (the package: tm) i'm running into deep trouble.
The following C# code:
REngine engine = null;
REngine.SetEnvironmentVariables();
engine = REngine.GetINstance();
engine.Initialize();
engine.Evaluate(".libPaths('C:/Users/Laptop/Documents/R/win-library/3.1')");
engine.Evaluate("library(tm)");
is resulting in: package or namespace load failed form 'tm'
From RStudio the command library(tm) works without any exceptions.
I tried the following steps to solve this problem:
a reinstall of R
updating packages from R studio
adding 'C:/Users/Laptop/Documents/R/win-library/3.1' to R_LIBS, R_LIBS_USER and R_LIBS_SITE
But nothing seems to help so far.
Can someone help me with this nasty problem?
Some information from sessionInfo():
R version: 3.1.0 (2014-04-10)
Platform: x86_64_w64_mingw32/x64 (64-bit)
other attached packages:
[1] tm_0.5-10
The last two issues logged at the codeplex site, here and here, relate to this problem: running R.NET from an IIS web app is a known long-standing issue. Thankfully, recently skyguy94 has done the best diagnosis and explanation of the issue to date, and as I understand proposes a workaround. You should give it a try.
Future versions of R.NET will likely offer an easier way to, er, accomodate IIS, but this is subject to the time of already busy volunteers. Meanwhile, I'll update the home page to flag the vexed issues running under IIS.
There might be other base package/s that may be failing after the package shown in the error.
In my case matrixStats was failing but in the background stats was failing to load, and that was failing because it was trying to find core R dlls inside the stats library.
I fixed the issue from another post: http://author-entry17.rssing.com/chan-9456546/all_p43.html
You have to copy over the dlls from the architecture folder into the package path as a work around.
ie copy dlls in C:\Program Files\R\R-3.1.0\bin\i386 or C:\Program Files\R\R-3.1.0\bin\x64
to
R\R-3.3.1\library\stats\libs\x64 or R\R-3.3.1\library\stats\libs\i386
as a work around.