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.
Related
I'm at the end of my rope trying to figure out why my working DLL cannot load a NuGet package that it could always load before (like for a whole year). My system has 70 NET 6 projects and half a dozen of them use the same NuGet package to read XML files. Recently (a few months ago) I upgraded everything to NET 6, and even after that upgrade, everything worked fine.
But now, one of my C# class libraries generates an exception in a constructor because it can't find the NuGet package that sits right beside it in the filesystem app folder where everything is loaded from. The error message was:
.ctor Could not load file or assembly xxx blah blah. The system could not find the file specified.
For what it is worth, here is a trace of the build options in the batch file that I have been using for months.
Deleting hscore\hscore\bin Deleting hscore\hscore\obj Deleting
hscore\hscore\packages "C:\Program Files\Microsoft Visual
Studio\2022\Community\MSBuild\Current\Bin\msbuild.exe" -nologo -m
-V:minimal -t:clean;restore;publish /p:Platform=AnyCPU /p:PlatformTarget=AnyCPU /p:Configuration=Debug
/p:TargetFramework=net6.0-windows7.0 /p:RuntimeIdentifier=win-x64
/p:SelfContained=false /p:PublishProtcol=FileSystem
/p:DeleteExistingFiles=true /p:PublishDir=c:\dev\holding\core.plt
-nowarn:MSB3305 c:\dev\products\hscore\hscore\hscore.csproj
Determining projects to restore... Restored
c:\dev\products\hscore\hscore\hscore.csproj (in 874 ms).
hscore -> c:\dev\products\hscore\hscore\bin\Debug\net6.0-windows7.0\win-x64\hscore.dll
hscore -> c:\dev\holding\core.plt\
I have done the following to debug it, without success:
deleted the bin/obj folders of the failing class library
checked the target framework of all projects (= net6.0-windows7.0)
checked the runtime identifier of all projects (= win-x64)
checked the build configuration (Debug, AnyCPU)
removed and re-added the NuGet package (with a specific version)
the Nuget package depends on NET Standard, compatible with NET 6
and I use the same version in other NET 6 programs that are working fine
restored and rebuilt the DLL
published it to the destination folder where it is run from
checked that the expected Nuget package is there (it was)
and yet it still fails to find the Nuget package
I tried to trace DLL loads of the process with the SysInternals Process Monitor, but I am not good enough to do that (if it is even possible). I can filter events to see the parent app process load, but the failing DLL is called by the parent process and I don't know how to see the search paths it is using to find the Nuget package.
I want to believe that the problem is a version mismatch between NET 5 and NET 6 and the version of the Nuget package sitting in the folder, because I once had a problem like that. For example, if I had a NET Framework version of the Nuget package, it would not be "found" by a NET 5 DLL that wanted to load it. (I am NOT saying that is my problem, because I have no NET Framework projects anymore.)
The most recent thing I have been working on is the build system and options. I can build the whole system with batch files or with parallel builds (when the system is working). I use the same msbuild options in both cases, and the batch method has been reliable and shows no build errors, no publish errors, all the correct build options, and no warnings or errors whatsoever.
The Nuget package pulls in 10 or 20 dependencies, but that is all automatic, and the package works with other console programs and apps that are working fine. So, I don't think there is anything wrong with Nuget package. All the working apps use the same Nuget package from the same runtime folder. I don't know why this one DLL is having a problem. AND I have not changed anything in the failing DLL class library for months (and it has been working fine).
Does anyone have suggestions on what else I might try to debug the problem and get the system working again? Thank you.
UPDATE - New version and build, but still a runtime failure.
Just to be sure, I upgraded the Nuget package that could not be found to the latest version and replaced all references in my 70 projects to the new version. Then I rebuilt the system (no warnings, no errors). But that did not make a difference. Now the new version cannot be found.
All unit tests of the code in question work flawlessly in VStudio, presumably because VS loads the Nuget package properly. I am mystified and would appreciate thoughts on how to proceed. Thank you.
UPDATE 2 - installed 'dotnet-trace' and traced DLL loads
I found a page that described how to dotnet tool install --global dotnet-trace and then captured a trace of my app trying to find the elusive Nuget package that is sitting right beside the requesting DLL. Although I could my app loading various app DLLs (and tons of system DLLs) with found pathnames, the trace showed nothing useful about the Nuget package.
The trace entries show the system searching in stages FindInLoadContext, then ApplicationAssemblies, then AppDomainAssemblyResolveEvent. After that, the system throws an exception because it can't find the Nuget package.
I would have thought the system FindInLoadContext would find it in the same folder as the executing and requesting assemblies, but it seems not so.
Ideas? I'm lost. And everything used to work fine.
UPDATE 3 - A small console app calls the DLL and it finds the Nuget package
The problem scenario in this question is: WindowsFormsApp -> loads MyCore.dll and calls new MyCore.MyObject(), which in the constructor tries to read some XML files using MyUtils.dll, which tries to reference the mystery Nuget package for reading XML files. MyUtils.dll cannot find the package, no matter what I do.
I wrote a small console program to load MyUtils.dll and called the exact same MyUtils.ReadMyXmlFiles API to read the files. The console app (actually, the system assembly loader) correctly found the Nuget package and read the XML files properly. This all occurred in the same folder that contains the Forms app and the Nuget package.
The only difference now is that the WindowsForms app calls an intermediate DLL that calls a constructor that references MyUtils.dll.
Could the intermediate DLL + constructor call be changing the Assembly Load Context (FindInLoadContext search rules) for the Nuget package load operation? Very strange.
The overall problem was that my Windows Forms app failed during boot (in the Form_Load event) because a Nuget package could not be found to read some XML configuration files.
Four assemblies were involved in the problem. Assembly1 (the app) called Assembly2 (.. new Assembly2Object()), whose constructor called an Assembly3 method (utilities.ReadXMLFile) which called Assembly4 (NugetPackage.XMLReader).
You can see that only Assembly4 references the Nugetpackage which could not be found. Normally, there should be no reason for Assemblies 1 or 2 to know about the existence of the NugetXmlReader used by Assembly3. But, the exceptions and assembly load traces of dotnet-trace and procmon clearly showed that Assembly3 (utilities.ReadXmlFile) could not find the NugetPackage at runtime, even though the right package was in the folder beside the executing assemblies (1->3).
The "solution" for my case was to add a Nuget package dependency to
Assembly1 (the WinFormsApp). As soon as I did that, Assembly3 (utilities.ReadXmlFile) could find Assembly4 (Nugetpackage).
My working theory is that during a WinForms boot sequence (including the Form_Shown event), the AssemblyLoadContext from Assembly1 is used to look up all assemblies in any call chain (like Assembly2 calling Assembly3 calling NugetPackage4).
Because the load context of Assembly1 has no reference to NugetPackage, and because the .deps.json file for Assembly1 is present (the doc says it is used to form the load context), Assembly3 - using the assembly load context for Assembly1 - could not find the NugetPackage.
When I added a dependency to Assembly4 (Nugetpackage) to Assembly1, then the assembly load context from Assembly1 was used by the System AssemblyLoader FindInLoadContext phase to search for (and find) the NugetPackage4 wanted by (the referencing assembly) Assembly3.
I used to think that each assembly in a calling chain would have its own assembly load context used by AssemblyLoad/FindInLoadContext. But I think that no longer. At least for my case of a Windows Forms app booting up, the assembly load context from the top-level app is being used to look up Nuget packages far down the calling chain.
It's worth repeating that my little test console apps always found the Nuget package without adding the package as a dependency to the top-level console program. I wrote console programs to test the calling chain from the bottom up: Test1) console calls Nuget directly - found; Test2) console (w/o Nuget dependency) calls Assembly3 - Nuget found; (Test3) console (w/o Nuget dependency) calls Assembly2 - Nuget found.
Then I wrote a skeleton WindowsFormsTestApp to call Assembly2 (just like the console program did) - Nuget NOT found. When I added a Nuget dependency to the WindowsFormsTestApp - Nuget was found by Assembly3.
The final step was to add a Nuget package dependency to the WinFormsApp that started this whole mess. Presto! Assembly3 found the Nuget package immediately.
My (unproven) belief is that somewhere along the line of upgrades from NET 5 - NET 6 (several SDK versions of each one), the assembly load context rules changed somehow. I could be wrong, but I lean toward this belief because my code from App->Assembly2->Assembly3->Nuget did not change during several months of successful operation. And just a couple of weeks ago after another NET 6 SDK upgrade, things broke.
Hopefully, this record might help someone someday. It seems completely unintuitive to me to add a Nuget package dependency to the top-level Forms app to help Assembly3 find a Nuget package sitting in the same folder as all the other assemblies.
After all this, I am coming around to the idea that the top-level app must/should include dependencies on anything the app ever calls, including packages used by dependent assemblies. (Although I am still puzzled as to why the code worked for months before without the Nuget package dependency.)
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 installed LibGit2Sharp via NuGet into a VS add-on I'm (re-)writing (Visual Studio 2015). The code compiles fine, but it barfs when I try to allocate the Repository:
using (var repo = new Repository(#"C:\Path\MyProject"))
The thing is, it used to work. I was testing it out, and the code ran fine. Then--bam--I ran it again and it stopped working. The specific error:
{"Unable to load DLL 'git2-785d8c4': The specified module could not be found. (Exception from HRESULT: 0x8007007E)"}
From what I understand about NuGet--which isn't a lot--it's supposed to set all that up so I don't have to worry about it. So I uninstalled it and re-installed it.
The weird thing about LibGit2Sharp is the old version shows up first (v0.22.0) and "version 1" shows up second (v1.0.160). I installed 0.22.0 the first time, so I tried the second one (v1.0.160) the next time. But v1.0.160 didn't work at all (none of the code compiled, errors galore). So I uninstalled v1.0.160 and installed v0.22.0 again. Now it all compiles again, but I get the error above.
Does anyone know what's going on?
For others who might come into this thread in the future:
Put 'git2-785d8c4.dll' in the same directory where your output exe is, then it will work.
you can find it in ..\LibGit2Sharp\bin\Debug(Release)\lib\win32\x86
Is it possible that the .NET framework version your project targets has changed? Are you able to target .NET framework version 4.5 (rather than 4.51 or any other higher version, such as 4.6) and try again?
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.
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