I have been working on a library which can perform various email actions with either EWS or MS Graph.
I had great success implementing EWS because of the limited amount of dependencies required for the EWS API. However when I implemented MS Graph into the library the amount of external dependencies grew ALOT, I went from (estimated) 2-3 external dependencies to 15-17.
(By external dependencies I am refering to dependencies which does not come standard with .Net framework 4.8)
All these depedencies are installed with the nuget package manager.
While I only had EWS implemented I had no issues to get ILMerge to merge the final DLL with the external dependencies, but as soon as I implemented Graph ILMerge would no longer work.
This is a problem as the library was originally developed for use in an application called Kofax TotalAgility (KTA), but this application would only store the single DLL as a blob in its internal database. This meant that when KTA read the dll for classes and methods (KTA gives an overview of available methods to be executed along with input and return parameters) the application would fail telling me that it could not resolve "Azure.Identity.dll".
After SO MUCH STRUGGELING to get ILMerge to work, but with no luck, I yielded and tried another approach.
I decided to develop an ASP.net Core application which would expose the methods in the DLL as a REST service, this in theory was an okay solution as KTA has excellent REST service support.
This new REST service worked on the premise that controllers would have post mappings for each method, and the controller would call my library.
Having the library external would be preferred as I might need it as standalone later.
Now having developed the REST API I created some Unit tests to test the different endpoints, to make sure everything worked as it should.
These told me that the EWS implementation still works as intended, but the Graph implentation throws an error: System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.Identity.Client, Version=4.39.0.0, Culture=neutral, PublicKeyToken=0a613f4dd989e8ae'. The system cannot find the file specified. File name: 'Microsoft.Identity.Client, Version=4.39.0.0, Culture=neutral, PublicKeyToken=0a613f4dd989e8ae'
I held my hopes high as the missing dependency was no longer the "Azure.Identity.dll", hoping that copying the missing DLLs to the IIS Application folder (next to the executable) would fix the issue, this however did not help anything.
I have since not been able to find any other solution.
I have thought about an internal assembly resolver which would be a C# event run everytime a dependency should be resolved. I would subscribe to this event in the class contructor, so that it would be ready whenever a method was called.
This probably would fix the issue in ASP.net Core, but it would not be fixed in KTA. If KTA should load classes and methods then the library is never "instantiated", I have tried doing the assembly resolve solution using a static constructor, but this does not help.
To sum up here is a list of things I have tried:
AssemblyResolver in a static contructor
RegAsm all the depedencies needed
Putting all depedencies next to the executable
Uploading all the dependencies to KTA Store
Merging all dependencies using ILMerge and ILMergeGUI
Embedding interop types (long shot, but I am desperate)
Trying to merge only dependencies that could not be resolved
Copying gacutil from my development machine to the target machine to use that instead of RegAsm (also a long shot)
Loading depedencies directly as an embedded resource
The optimal solution I am looking for is a library that is free of external dependencies.
But I can settle for a solution to my dependency problem in ASP.net.
I hope you can help.
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.
I have a question that has been bothering me for awhile. I ran across this problem a few years back when I was dealing with writing a generic logging wrapper around some hosted provider instances using log4net.
The idea was simple enough, I wanted to write a logging and metrics that hid all the implementation in a separate visual studio project so when you wanted to add any telemetry support to another application you could just include the project, new up an instance of the logger and start logging using generic calls. If you ever switched providers or tweak logging settings, it wouldn't require any changes to the host applications.
This creates a strong decoupling point, where the main application used an interface in a logging class library, but would know nothing about the packages or providers that the logging class library was using to do the real work.
When I did this and tried out using Loggly's nuget package and log4net, I found that the calling application had to have a ref to the nuget package or else the dependent assembly would not be copied to the build directory. At the time I just wrote this off as something odd that they Loggly engineers were doing. But I have since encountered the same behavior in some, but not all other packages. (DogstatsD doesn't have a problem, Raygun does, etc..)
I have noticed that some nuget packages in assemblies are automatically copied into the parent output directory, but when I look for the setting that controls this, I cannot find it.
I have written dozens of class libraries over the years, and I have never had a problem with 'chained dependency assemblies (a refs b, b refs c, etc.) resolving when I build. It only seems to be some nuget packages that are a problem.
How do I force nuget packages referenced by a class library project to copy into the build directory without an explicit reference in the application?
Ok, I figured this one out.
This is a problem only for the Log4Net & Loggly wrapper assembly combo in particular because it is referenced entirely at runtime. Log4net loads up its required log appenders at runtime, and because .net doesn't see a ref to the assembly at build time, it assumes that it isn't being used and omits copying the required assembly to the bin directory. The solution when you know this is simple, just write an empty dummy method in the referenced library that you can call in the main application. This will cause .net to include the assembly in the build.
While this problem is specific to the Log4net library, it could occur anywhere that you are using an assembly that is only used with runtime reflection.
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 have a WCF plugin service that loads plugins via MEF and runs them.
Each plugin is a directory with multiple dll's that implements a specific interface.
I load all the plugins in the same AppDomain using MEF (DirectoryCatalog) and run them in a generic way (using reflection).
Now lets assume I have two plugins with dll dependencies:
Plugin1
----> Entities 1.0.0.1
Plugin2
----> Entities 1.0.0.2
I've added some new entities in 1.0.0.2.
When I run the plugin's I get a sporadic error that the new entities doesn't exist in the dll.
I guess that the error occurs since I'm running the code in the same AppDomain and the first Entities.dll that loads is the one that will serve all my plugins.
So, how can I run each plugin with isolation, without creating a new appdomain?
Is there any way I can tell MEF to load all plugin dependencies somehow?
I've read about a couple of solutions on the web:
Create a new appdomain for each plugin - I don't want to go there.
Use the <dependentAssembly> - This didn't work when I first tried it and I don't want my plugin server to get updated on each assembly dependency version change. Plus, I want to be able to run plugins with different assembly versions.
Sign the assemblies with a snk - I didn't try this yet and I'm not sure this solution will work. How will the framework know that he needs to load a different assembly? How is this different from assemblies with different versions? Will I need to configure my service somehow in order to make this work?
Does anybody have any better idea for me?
What's the recommended way to run isolated plugins?
You need to sign your assemblies And make sure the assembly version is different on each one. See the answer from the following: C# Load different versions of assembly to the same project
The CLR does support loading multiple versions of strongly named assemblies into the same AppDomain. This only works though if your assemblies are strongly named and each one has a different version than the other.
I been searching this for a long time but haven't seen an answer.
I'm referencing two dlls, which are a C++ library API for .NET, in a wcf service library, it works fine when invoking the wrapped method from wcftestclient. But when self hosting the library in a websercice it says"can't find assembly xxx.dll (it's one of the c++ API dll) or one of its dependency". But I can see the dll it says missing is auto copied to the bin/debug folder for the host webserive project. Also, I can host the library in a simple console project in which calling the wrapper method has no problem at all.
I hope this is a simple config setting that i'm missing to specify in the web config file, anyone has any suggestion? Thanks.
I spent almost three days on this problem and now it's resolved. In case this can help someone else who might have the same situation here is why.
The two c++ library .net api dlls are late binding so it won't look for its dependency until runtime. I even tried to registry the whole external library package in GAC and it didn't help; this was because one of two .net api dlls is a weak assembly hence CLR won't even bother looking for it in GAC. What I did was create a static constructor for the service and within the static constructor load the late binding assembly into AppDomain. I am using Assembly.LoadFrom(string filePath) method (other methods are available on Assembly class to do this). Now I can host the service on IIS and consume it in any client. So if clr is complaining it can't find an assembly but you can see it in the bin/debug folder, it's probably a late bind assembly which needs to be pre-loaded into the AppDomain; the good thing about AppDomain is you only need to load the assembly once and it will never unload an individual assembly.