Develop Reference

loading multiple.net assemblies with same AssemblyVersion from a plugin

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.

DLLNotFoundException under Unity whilst using FUBI

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.

Compile IronPython with Mono

When I try to install IronPython on Debian with Mono (3.12), I get the following error:
socket.cs(1900,63): error CS0117: `System.Net.Sockets.SocketOptionName' does not contain a definition for `IPv6Only'
How can I solve this problem? According to the IronPython website, everything should compile without errors.
In the Mono mailing list there is already such a bug, but there is no answer to this bug. Therefore I thought that maybe this forum is a better place for this question.

I'm no expert on either IronPython or Mono, but out of curiosity I just tried this.
For whatever reason, the IPV6Only value in the SocketOptionName enum appears to be missing in the Mono implementation. The error message you're getting is from the code in IronPython.Module/Socket.cs attempting to reference this. It turns out that this is already recognised in the codebase as a feature that not all platforms have, so there's an easy workaround:
The Common.proj project file in the Solutions/ directory in your git checkout defines a number of possible ReferencedPlatform values. The default value is V4. Just below there in the XML, find a block starting:
<PropertyGroup Condition="'$(ReferencedPlatform)' == 'V4'">
Nested in there is a Features element with a list of the features that apply, and if you find and delete FEATURE_IPV6 at the end of the list, then you should find that the project will build using make. I briefly tried firing up the ipy.exe that is generated and it seems to work.
Obviously this isn't a very good solution. Probably the best thing would be to file a bug report with the IronPython project. I guess that Mono on Linux is probably a fairly low priority for the guys who are working to maintain it.

Correct, up to mono 4.0 throws Protocol option not supported when setting IPv6Only false.
This is probably resolved here: https://github.com/mono/mono/blob/mono-4.2.0-branch/mono/metadata/socket-io.c#L536
But do note the compile flag IPV6_V6ONLY

MySql.Data reference in my own .dll only functions on development computer, not on end user's computers

I have a question as a novice programmer regarding a MySql.data reference I added from the MySql connector net, to my code. The program that I compile would be made into a .dll that runs from within another application. The application is a stock trading program, and my code is a strategy that makes evaluations of price data and executes buy and sell orders, etc.
Just when I thought my strategy was fully developed I've run into a new snag I'd love to have someone's help with in solving.
I'm asking stackoverflow because the support forum mods of the trading application removed this question from their forums, probably because it was outsie their supportable boundaries.
I've been adding extra .NET references to my strategy, like windows forms and system.management, etc so that it would be able to check the computer's hard drive 'serial number' to make sure that the strategy is licensed on that computer. Everything has been working ok so far, and I was able to get the strategy to run on other computers by exporting it as a .dll
The latest and final addition I made was to add a reference to MySql.Data.MySqlClient (which is a .dll that had to be downloaded and installed separately and isn't part of .NET) so that it could check the computer's hardware ID against an online database to see if it's on the whitelist. I got that working perfectly on the development computer, and as soon as I tried to get it running on my other computer, this error message came up in the output window:
NT Error on calling 'OnStartUp' method for strategy 'MyStrategy/7f5e28c481644cb5a7754d0b7a0be47f': Could not load file or assembly 'MySql.Data, Version=6.1.6.0, Culture=neutral, PublicKeyToken=c5687fc88969c44d' or one of its dependencies. The system cannot find the file specified.
I don't fully know what is happening, but it seems that in the past all external .dll from microsoft .NET that I referenced in my code were carried over and functioned perfectly on other computers, and while my code runs with the MySql.Data reference, once any MySql commands are run the program terminates and says that error message about a missing file. (But if I comment out those lines of code it runs fine, just without the licensing checks I need to have)
One last thing I can mention for more information, as I'm new to this area of development and don't know if it matters, is that I installed the most recent MySQL connection net to the laptop which is a later version than the 6.1.6.0 that I have on the development computer.
The strategy runs exactly as intended on the computer it was developed on though.
My main question has two parts to it then:
1) Is there a way to embed or merge the MySql.Data .dll so that it can be a part of my .dll?
2) Will every end user of this software need to have MySql connection net installed on their computer, and the exact same version as whatever it was developed in (noob question)
Any answers, guesses and speculation are welcomed and appreciated.

Just check if your programs output directory contains the MySql.Data dll file.
If not Try to copy the MySql.Data dll file to the output directory of your program.
it should solve your problem.
The problem happens because may be you are referencing the MySql.Data dll from any other directory rather then copying it to the local project directory. or may be it is not copying into your projects output directory.
So when you run the program to another machine it is unable to find the MySql.Data dll file in specified directory and says
MyStrategy/7f5e28c481644cb5a7754d0b7a0be47f': Could not load file or
assembly 'MySql.Data, Version=6.1.6.0, Culture=neutral,
PublicKeyToken=c5687fc88969c44d' or one of its dependencies. The
system cannot find the file specified

Assembly references won't resolve properly on our build server

We code in C# using VS2008 SP1. We have a server that runs Team System Server 2008 which we use for source control, tasks etc. The server is also our build machine for Team Build. This has been working just fine for a long time. Untill now. We get these error messages when trying to build one of our projects that has a reference to one external assembly (this happens both via Team Build, and when logging on physically and doing a regular build via Visual Studio):
C:\WINDOWS\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets
: warning MSB3246: Resolved file has a
bad image, no metadata, or is
otherwise inaccessible. Could not load
file or assembly 'C:\Program
Files\Syncfusion\Essential
Studio\7.1.0.21\Assemblies\3.5\Syncfusion.XlsIO.Base.dll'
or one of its dependencies. The module
was expected to contain an assembly
manifest.
C:\Program
Files\MSBuild\Microsoft\VisualStudio\v9.0\ReportingServices\Microsoft.ReportingServices.targets(24,2):
error MSB4062: The
"Microsoft.Reporting.RdlCompile" task
could not be loaded from the assembly
Microsoft.ReportViewer.Common,
Version=9.0.0.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a. Could
not load file or assembly
'Microsoft.ReportViewer.Common,
Version=9.0.0.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a' or
one of its dependencies. The module
was expected to contain an assembly
manifest. Confirm that the
declaration is correct, and that the
assembly and all its dependencies are
available.
The referenced component
'Syncfusion.XlsIO.Base' could not be
found.
These errors are for one project with one problematic assembly reference. When I try to build the entire solution there are of course many more errors because of this one. And there are two other projects that has the same problem with other assembly references. I have a list of the referenced assemblies that VS can't seem to resolve:
Microsoft.ReportViewer.Common
Microsoft.ReportViewer.WinForms
Syncfusion.Compression.Base
Syncfusion.Core
Syncfusion.XlsIO.Base
The Syncfusion assemblies are from a 3rd-party component package. The other two are related to the Microsoft ReportViewer component.
The references has been added via the Add Reference window, in the .NET tab, so I don't think there is anything suspicious about that. In the properties window for the assembly reference, there is no value in Culture, Description, Path, Runtime Version or Strong Name. Version says 0.0.0.0 and Resolved is False. I guess it is pretty obvious that VS cant resolve the reference. My question is why??? I've scratched my head a lot over this one. This only occurs on the server, the solution builds just fine on both my machine, and my coworkers machine. The assembly reference properties are fine on our machines.
I have tried uninstalling the 3rd-party component (on the server of course), and then reinstalling it again. Didn't help. I tried to repair the VS2008 installation. Didn't help. Tried to retrieve an earlier version from source control (that I know has buildt on the server before), and I got the same error messages. I have checked file permissions, and everything appears to be in order. I am running out of ideas...
How do I solve this?
Update 16.02.2009:
I have tried to compare ildasm output of the dll on my pc and on the server (see the comment I wrote about that), and there is one small difference in a line that to me appears to be a comment. I must admit that I don't understand why there is a difference at all, so maybe someone could explain that to me?
I also tried running a virus scan on the server. Didn't help. Tried to remove the reference and then readd it by browsing to the dll on disk. Didn't work.
Update 17.03.2009:
I've found the solution! The culprit was the TruPrevent module of Panda Antivirus. After disabling the module, everything works! =)
I discovered this with the help of fuslogvw.exe and the log it generated. Googled the result, and stumbled upon this blog entry.. Hope this can help somebody else to.

Almost certainly the problem is environmental - not source related.
Some ideas ...
(i) Try disabling your anti-virus/anti-malware tools - I've seen cases where these tools (particularly Trend Micro Antivirus, for some reason) can keep a DLL file locked after (during?) scanning, interfering with compilers.
(ii) Check your PATH environment variable. Even in these modern days, the PATH variable is used to resolve some things - if this is messed up (too long, maximum length is 2048 characters IIRC) then things can be odd.
(iii) You've checked File permissions - have you checked permissions in the registry? For example, SyncFusion installs its license key in both the User and Machine hives - if the build server can't read one or the other, could cause issues.
Good luck!

It could also be that the referenced assemblies are in the GAC on the dev machine, but not on the build machine. Get it out of the GAC, into your source repository, and reference it by path.

We've had the same problem, turns out the C drive was full (only had 28MB).
Freeing space resolved the issue, even though the build happens on D.

Do you see any differences between ildasm of this file
'C:\Program Files\Syncfusion\Essential Studio\7.1.0.21\Assemblies\3.5\Syncfusion.XlsIO.Base.dll'
on your machine versus on the server?

My suspicion is that the user that the build process is under does not have access to the folder that your 3rd party control is in. Since this functions properly on your machines, it is almost certainly user/permission specific.

Your 3rd party dll may depend on unmanaged dlls. Often it's because a specific version of the VC++ Runtime Dlls are missing.
Open the Dll with the Dependency Walker http://www.dependencywalker.com/ on your server and check for missing references.

Not sure if this'll help in your case, but I did have something similar before where a dll apparently got unregistered somehow, and running regsvr32 on the dll did the trick.