We Keep Coding

How to handle new releases of third-party .Net assemblies without recompiling?

I have some projects that rely on external .Net assemblies to operate. These are installed externally from my program so I do not have direct control over what version is being used. Furthermore, updates are expected to be installed as a matter of course.
For example, in one case I am accessing a hardware device that provides a .Net interface to control it. When the user initially installs the device, they install the driver that is included. This driver when I wrote the program may have been 3.0.4.0. The latest version might be 3.1.8.0.
My program fails to load the assembly when this happens complaining that the manifest definition is incorrect. A specific exception message is show below.
Another example is a labeling program. They provide a .Net interface to allow my program to print labels through their system. Installing an updated version of the program is fatal.
Here is the specific exception message:
Could not load file or assembly 'SDK.NET.Interface, Version=17.1.0.0,
Culture=neutral, PublicKeyToken=865eaf3445b2ea56' or one of its
dependencies. The located assembly's manifest definition does not match
the assembly reference.
If I install this version of the application on my computer, then reference the updated version of the assembly and compile, I’m good to go . . . for now.
But, it’s only a matter of time before I will have the issue again.
I’ve tried setting the Specific Version property of the referenced assemblies to False but that didn’t affect the problem.
What is the proper way to address the issue?

You are able to "Plug and Play" as long as method signatures don't change.
If those change, then you'll need to fix your base code.
Look at Microsoft's documentation on Redirecting Assembly Versions:
http://msdn.microsoft.com/en-us/library/7wd6ex19%28VS.71%29.aspx
Another option is If these libraries are somehow controlled by you or your company, you might have some wiggle room with reflection by loading them up by their base type/interface and using common methods... but you'll need to have access to the base types.
This is also a duplicate question:
Upgrade a reference dll in a C# project without recompiling the project
Upgrading dependent DLL without recompiling the whole application

Using ApplicationData in Windows WPF vs UWP

Semi-important Background
I am attempting to change a UWP project to a Windows desktop application so that I can make use of the full .NET Framework 4.5.2. My solution also contains a second project--a Windows Runtime Component--which operates the background tasks. These background tasks write to the ApplicationData so that the primary project with the GUI can use the information. I've made the primary project a Windows application rather than a UWP, but one issue remains:
The Issue
Any reference to ApplicationData.Current.LocalSettings.Values such as
ApplicationData.Current.LocalSettings.Values.Keys.Contains(myDataIndex)
results in the following error:
Error CS0012 The type 'IPropertySet' is defined in an assembly that is not referenced. You must add a reference to assembly
'Windows.Foundation.FoundationContract, Version=2.0.0.0, Culture=neutral, PublicKeyToken=null, ContentType=WindowsRuntime'. ProjectName C:\Users\MyUserName\Documents\Visual Studio 2015\Projects\ProjectName\ProjectName\MainWindow.xaml.cs
So, for some reason, VS is confused on what IPropertySet is.
I've Tried...
Unfortunately, there's nothing starting with Windows.Foundation in the list of namespaces under Assemblies->Framework in the Reference Manager.
Ok, so it's probably already in there somewhere, right...? I'll just try using the required namespace. However, my project cannot find this Windows.Foundation.FoundationContract because my project does not allow
using Windows.Foundation.FoundationContract
though it does find Windows.Foundation.Diagnostics and Windows.Foundation.Metadata.
When I tried this in the original UWP version of the project, it was able to find Metadata, Diagnostics, and Windows.Foundation.Collections. (Curiously enough, the IPropertySet interface my Windows app can't find is actually located in Windows.Foundation.Collections).
This leads me to think that Windows.Foundation.Collections is not available in the .NET Framework used by the Windows app, and only in the UWP .NET Core...? But if that's the case, why does VS still know about ApplicationData.Current.LocalSettings.Values if it couldn't be used? It seems as if I'm missing something else here.
Update
It looks like I just needed to import
C:\Program Files (x86)\Windows Kits\10\UnionMetadata\Windows.winmd
per this answer to fix the reference issues.
(Strangely, I also had to remove a reference to another Windows.winmd file that was at another path. I think that was somehow a result of my attempts to import other things.)
Real Question
Ok, I made it work, but it seems like I'm cheating by importing UWP library stuff. But surely there's a better way?
TL;DR
How am I supposed to use ApplicationData for cross-thread data-sharing in a WPF desktop application without other imports? (And how is it different than a UWP application?

Could not load file or assembly asp.net

There are some authentication changes recently in our company and we are supposed to change the authentication systems in all the applications. We have a dll (Auth.dll) that has this logic about the authenticaion. All our applications has these Auth.dll file and uses the same logic for authentication.
Our strategy for this is to just modify the dll to use new authentication logic. The method signatures remains same, since those are the methods we call from other places in all our applications.
We have an archive application (built on .Net framework 2.0) in our company which a few users still use.The problem for these archive applications is that we dont have the source code. So i am just trying to create a new dll and replace it on the production server on the location where old dll was hosted. Everything else stays the same.
I created the new dll using framework 2.0. I have unit tested it and works fine.
The issue i am getting is -
Could not load file or assembly 'Auth, Version=1.0.0.0, Culture=neutral, PublicKeyToken=ae1958e6e8b32d9c' or one of its dependencies. The system cannot find the file specified.
I checked the public key token on the new Auth.dll and it looks ok. The version also looks ok.
The Auth dll has the references to only 4 .Net framework 2.0 assemblies.
Any idea what may be wrong?
Thanks

You could easily get the source code for the dll by using something like http://ilspy.net/, this would then allow you to get the source code and recompile. I've always has a hard time tracking down these types of issues, but again if you use ILSPY you should be able to see all of the DLL's that the Auth.dll is referencing.
As an absolute last resort you could use some of the tools from sysinternals to see what is being accessed on the hard drive when this is being loaded to see if the reference dll simply isn't there. Hope this helps.

Did you register auth.dll in the gac, or put it in the archive applications bin folder?
Also if the archive application was referrencing the old auth.dll, then the signature of the new one will need to match the old one exactly, and by that I mean it's full qualified type name.
E.g.
Auth, Version=1.0.0.0, Culture=neutral, PublicKeyToken=ae1958e6e8b32d9c
Needs to be the same now as it was before.
Or you'll have to do as punkcoder suggested and rebuild the source with ILSpy or use ILDASM and change the reference and ILASM to put it back together.

Do you search in C:\Windows\assembly and find the assembly ?
Case no, you have to install or get the same version of your component.

Missing "ADODB" assembly with Mono?

I'm trying to port some ASP.Net code to mono. I am testing it using xsp2. I compile it with Visual Studio also before running it with xsp2.
Whenever I go to a practically blank page in my application I get
Parser Error Message: Assembly ADODB, Version=7.0.3300.0, Culture=neutral, PublicKeyToken=B03F5F7F11D50A3A not found
I have searched and not found any info anywhere about this. I know the web application makes use of Webparts and the SqlPersonalization thing which is not supported in Mono, but I'm going to basically a blank page with a master page and getting this strange error.
And I have ran Moma and it only complained about web parts and SqlPersonalization, neither of which are on the page I'm trying to view(or referenced in any way).
What could be the problem here? Has someone hit a problem like this before? Also I'm using the latest version of Mono on Windows

ADODB is the primary interop assembly for the old Microsoft ActiveX Data Objects (ADO, aka MDAC) COM-based database access layer. Looks like the ASP.NET code you're trying to port uses an older, non-.NET data access library for some reason. I suspect that library doesn't, and never will, exist on Mono.
One solution would be to port the code that uses ADO to ADO.NET, if that's possible.

Error when calling a .net dll from Com Visible dll using javascript

I am developing a windows 7 gadget.I am creating an activex object and loading the assembly.I am following the methodlogy mentioned here at codeproject (GadgetInterop). One of the tasks of the gadget is to interface with Facebook.
This is how I am referencing:
Javascript creates a GadgetBuilder object.
From here I load the my library. say "MyLibrary.dll".
When I call method say MyLibrary.GetCount(), (just return some integer) it works.
But when I call some facebook function inside the method say MyLibrary.GetFaceBookFeeds() it throws an error.I reference "facebook.dll" from CodePlex
If I test my code from a ASP.NET form it works perfectly. However, When I run it from my html page by trying to load it using javascript, I get the following error:
Could not load file or assembly 'facebook, Version=2.1.3654.38113, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.
I verified that the dll's are in the same folder as "MyLibrary.dll".
Why is this error coming?
How do I go about achieving my task? (I need to use calling a dll from javascript as we are doing a lot of other things in the dll).

You're not forced to use a reflection-based assembly loader for .net code in desktop gadgets, you can write the assembly to be com visible, using class ids, etc. This article provides an example of using .net to achieve what you're trying to do without the "adapter".
That being said, there are various problems with activex based desktop gadgets that you should be aware of:
When an ActiveX instance is created in the gadget, the assembly dll will be "locked open" by sidebar.exe and the file cannot be deleted, even after the gadget has been closed. Unfortunately the gadget uninstallation process doesn't account for this and an uninstallation of the gadget will result in sidebar.exe copping out of the file deletion when it fails to delete the assembly, leaving the assembly and any other remaining files that hadn't been deleted up to that point. There's also no error message displayed. The same is true of overwriting a gadget (with a new version, for instance) - sidebar.exe attempts to delete the folder completely before installing the new gadget package, resulting in a failed installation in most cases.
The registration of such an activex control can be very tricky. The registry script given in the CodeProject article you provided does not work on my Windows 7 x64, for instance. The only way to work around this is to use WMI to write to the registry.
In a similar fashion, unregistration of the ActiveX control is also an issue. When the user uninstalls the gadget, the registry entries are left behind. Not a problem for a lot of people I suppose, but imagine a gadget enthusiast who tries every gadget he finds suddenly discovering the many unused registry entries. You can get around this by removing the registry entries directly after instantiating the object (since it's cached by the sidebar process anyway) and re-registering it again next startup.
So really although you can do it without reflection, using reflection can be a better option because you can copy the adapter assembly to an alternative folder, use it to load the current assembly and then unload it when the gadget is closed or finished using it. This eliminates the first issue of not being able to uninstall the gadget because the hosting assembly is located in a different folder and the reflected assembly is unloaded when the gadget is closed anyway.
The reason facebook.dll isn't loading is because the loader you're using doesn't correctly resolve dependencies (it can't find the file because it doesn't know where to look). You're welcome to try our reflection-based assembly loader called PluginLoader and see if that works. We haven't had an official release for it yet but we were intending to make it widely available and recommended for use by all developers to try and eliminate the problems with ActiveX and Windows Desktop Gadgets. Because we haven't officially released it you'll have to install our gadget, Auction Sidebar Tool which will install the plugin loader ready for use with the following code:
var plLoader = new ActiveXObject("Sidebar.PluginLoader");
var myLibrary = plLoader.LoadAssembly(classToLoad,
System.Gadget.path+"\\path\\to\\MyLibrary.dll");
myLibrary.GetFaceBookFeeds();
Where class to load is the class you need to load in the format Namespace.Class (ie MyLibrary.MyClass). We specifically coded it to correctly resolve any dependencies so it should work for you just fine. If it does work for you, you're welcome to include it with your gadget. All you need is the PluginLoader.js and PluginLoader.dll files from the AuctionSidebarTool folder, but you'll need to edit the PluginLoader.js file to remove the parts that reference our assembly (line 110 onwards). If you include this in your project, it will check for an existing PluginLoader.dll and if it fails, it will copy it to the Windows Sidebar folder in local AppData, register it and provide the AddInLoader object with the methods LoadAssembly and UnloadAssembly. If you need any extra help just let me know in the comments.
Hope that helps. That's probably the longest answer I've written so far on SO :)