Develop Reference

How to resolve "sub-assemblies" in ASP.Net Core

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.

Could not load the nibName issue (xamarin)

We start to prepare project with generic solution for few apps using Xamarin studio (the idea is to let all our apps use same "Core" components).
We started from preparing general "Core" with base functionality. Also we add "subCore" - libraries with functionality specific to each platform (iOS, android, windows etc).
Currently setup such structure for Android and iOS.
During second step of implementation for macOS, we faced with few blocking points.
The problem appear when we try to configure (in way described above) structure for macOS platform.
I was able to create macOS class Library with components that should be reused in apps (for now this is just 1 class with xib file). But, when I want to use this package (with xib inside) in macOS target, got exception:
External Modification Warnings: Debugger attached to process.
Application Specific Information:
*** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: '-[NSNib
_initWithNibNamed:bundle:options:] could not load the nibName: MainViewController in bundle (null).' terminating with uncaught
exception of type NSException abort() called
After some investigating, found that Mac Build server is not converting xibs into nibs, so this nib file is just missing in package created by Xamarin.
Additional testing info, based on proposed solutions found in Xamarin forum:
rename, recreate, reposition of xib file in project - not resolve the issue
recreate project - not resolve the issue
check Build action in property is set to InterfaceDefinition (also check all other possible variants) - not resolve the issue
I found this post, with root cause exactly as I have:
Mac Build server is not converting xibs into nibs.
According to discussion on this post, issue should be fixed, but I still faced with this.
Can some one advice how to fix described problem?

To anyone who faced same issue, please install
xamarin.ios-10.13.0.27.pkg
and
xamarin.mac-3.7.0.27.pkg
This build include fix for described problem.
For more, visit this page.

Launching C# WPF from Java causes FileNotFoundExceptions

I have a existing Java Project which needs functionality from a SDK written in C#. It should open a WPF Window and send the information back to Java on close.
For a basic connection of those two worlds i created a Java Project ("DotNetCaller") calling native functions. These are implemented in a C++/CLI Project ("DotNetBridge") which calls the C# Project ("DotNetApplication").
I already can set Strings from Java in C# and callback from C# to Java.
But as soon as i add a WPF Window and try to launch it with:
Application app = new Application();
app.Run(new DotNetWindow());
in a STA Thread it crashes.
The DotNetApplication doesnt find mscorlib.resources, after i provide the DLL, PresentationFramework.resources is missing and if i provide that, the DotNetApplication.resource is missing (which i cant provide).
If i call the DotNetApplication alone or from the DotNetBridge the Window displays as expected.
Can anyone tell ma what i'm really missing here?
Thanks
Edit:
I looked at this example once more and tried to adapt it to my needs.
I have set the dll directory of the ResolveEventHandler to the .NET dir in "Referenced Assemblies"
C:\Program Files (x86)\Reference
Assemblies\Microsoft\Framework.NETFramework\v4.0
and added a Window in C#.
It failed aswell but with a new exception in the C++ part rather than C#.
The ResolveHandler gets called with an empty argument causing an uncatchable exception in mscorelib.
I added a check if the String is empty and this basic approach works fine now.
I'm still unsure if i have the correct approach for this, so feel free to contribute.

Your AppDomain::AssemblyResolve handler probably needs to be overhauled and based on your own understanding of what you want to do. There is some guidance here. The basic rule is that you return nullptr for requests that you can't handle.
But first you have to plan the locations in which you want to deploy (and/or debug) your assemblies. A simple layout would be to put all of the assemblies that your JNI DLL depends on in the same folder as the JNI DLL (with the exception of any that will be installed in the GAC). You can then use its location to satisfy resolution requests. But remember to return nullptr if no file containing a manifest for an assembly with the requested name is present there. (This is likely the case with your ".resources" requests. If there isn't one it's okay unless you know otherwise.)
I'd be a little surprised if an assembly in a Reference Assemblies folder wasn't also in the GAC—but it'd be up to the assembly provider. Reference Assemblies is for design and build tools (e.g. Visual Studio). (The old way was for each folder that had assemblies in it to be registered for each version of Visual Studio so the assemblies could be used for design and build.) If a dependency is not in the GAC, you can use the "Copy Local" property on the reference to make it available for debugging.
You might find the Assembly Binding Log Viewer useful while designing and troubleshooting. With it you can see all the folders and extensions that are tried before giving over to calling the AppDomain::AssemblyResolve handler chain. (Disable logging when you are done.)

WcfSvcHost throws LoaderException when attaching to IIS7 process, but everything seems to work?

I have been implementing RSA security for a project I am working on.
I'm using the SecurID4Net files found on the web to get this rolling, which by default are targeted to the .Net 2.0 framework, ANY CPU.
I created a derived SqlMembershipProvider which references the SecurID4Net.Interfaces project, targeting .Net 4.0, any CPU.
My class lib "Services" references the SqlMembershipProvider, also targeting Any CPU.
My web app "Services.Web" references the "Services" lib, .Net 4.0, Any CPU.
I'm not using the client profile for any assembly targeting .Net 4. Every reference I have described here has Copy Local set to True.
I have my local IIS default web site set up to my output folder for the web project, so I can Ctrl-Shift-B and browse my IIS folder. When my client app signs in for the first time (possibly 2 or 3 times), it works fine, but after that sign ins fail. Additionally, when attaching to the IIS7 process (Services.Web), I would get the following error:
System.Reflection.ReflectionTypeLoadException: Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.
at System.Reflection.RuntimeModule.GetTypes(RuntimeModule module)
at System.Reflection.Assembly.GetTypes()
at Microsoft.Tools.SvcHost.ServiceHostHelper.LoadServiceAssembly(String svcAssemblyPath)
The DLL it is having problems loading is the SqlMembershipProvider I created.
So, I changed the SecurID4Net.Interfaces project to target .Net 4.0, and recompiled. It seems to work consistently now (still testing this part), but CTRL-ALT-P to attach to the IIS process still results in the WcfSvcHost error popping up before I can actually attach to the process... everything else seems to be working.
I'm running my VS as admin so I can attach to an IIS process;
All references described are set to Copy Local = true;
All assemblies are targeting .Net 4.0 Full Profile;
All assemblies are reachable, not blocked by the copy operation to the server where this is hosted;
To my knowledge no syntax issues with the web.config.
Anyone have any ideas why this error keeps popping up? Why would this error pop up when everything seems to be working?

I think I found the answer almost immediately. After inspecting each AssemblyInfo.cs file in the chain of projects, I found this in my SqlMembershipProvider assembly:
[assembly: AssemblyCulture("EN-us")]
I removed the value so it's an empty string.
I had a very similar issue in another project I worked on a few months ago where the web site had this filled in, and the web site worked on the very first load, but every load thereafter failed with a very cryptic error which, after drilling down, found that it could not load the assembly, giving a FileNotFoundException.
I don't know why this tiny, simple attribute would cause so many headaches...
EDIT: I'm 99% certain this was it. When I attach to my IIS process I no longer get a WcfSvcHost error.

ASP.NET: Multiple assembly versions, same web application

Hopefully you ASP.NET pros out there can answer this question. I have a single web application that contains a website and a web service - both have several assembly references in common (data access layer, utilities, etc) - however, recent changes made to the web service will require different versions of the common assemblies, versions that the website won't work with (in case you're wondering, the website is some legacy 1.x .NET code that explodes when using the newer version assemblies.)
Can anyone think of a way to allow my web service to reference one version and have my website reference another? I can obviously have only one version with the same name within the bin folder.
Thanks!
(P.S. - It just dawned on me that I could probably compile and reference the common assemblies with a different name, and place those in the web app's bin folder - but that sounds really fugly...)

Or you could separate the webservice into a new application independant of the website.

You can use the runtime part of the web.config to specify the dll to use (We have done it for SQLLite before):
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<qualifyAssembly partialName="System.Data.SQLite" fullName="System.Data.SQLite, Version=1.0.60.0, Culture=neutral, PublicKeyToken=db937bc2d44ff139" />
</assemblyBinding>
</runtime>

I have a single web application that contains a website and a web service
That's your main problem there, you've released a partially functioning Application that relies on two different library code bases...
Even if you were to duplicate and re-reference your common assembly with a different name, you're still boned (pardon the phrase) re: Namespaces of all your classes inside that assembly.
I think you're best bet, would be to Pull the webservice out of your Web Application temporarily, and host them as two seperate app's until you can get your Common Lib's versioning issues sorted out.

I don't think compiling the newer set into an assmebly with a different name would work - .NET would still see the same namespace - so at best you'd have "Ambiguous Reference" or "Type x is already declared in dll y" errors, or at worst the framework would load the one relevant to the part of the app that was called first (website => 1.1, webservice => 2.0) and ignore the other one.
Your best bet would be to refactor the application in to two - web site and web service.
We've been doing this over the last couple of years with one of our clients - they have a huge site built on ASP.NET 1.1, but recent stand alone projects for them have started to move to 2.0 (3.5 under the hood, but obviously that's still hosted under 2.0) - we've basically had to port the common code to a new set of libraries built against 3.5, taking advantage of the new language features as we go, and we've moved those sections to new web sites (in IIS) as they are completed.
It's not ideal, yes we're then left with two copies of the codebase (1.1 and 2.0) and any fixes generally have to be rolled out in two places, but it seemed the best way to start moving them on.