0

I have many .NET WinForm applications that use a particular .dll assembly. The company that puts out this particular product occasionally releases a new version. Since they offer strong-name assemblies, I need to download the new version of their .dll, but also go through every one of my applications and rebuild them with the reference to the new .dll file. Then, I need to deploy every one of my applications. It is a lot of time, paperwork, and testing to do this, so I asked the maker of this .dll for a workaround.

They gave me this Stack Overflow thread as a suggestion and said it would "work perfectly." However, I haven't quite figured this out.

In my application, I have added this to Program.cs:

static Program()
{
        AppDomain.CurrentDomain.AssemblyResolve += delegate(object sender, ResolveEventArgs e)
        {
            AssemblyName requestedName = new AssemblyName(e.Name);

            if (requestedName.Name.ToUpper().StartsWith("THE.PRODUCT.NAME"))
            {
                AssemblyName assemblyName = AssemblyName.GetAssemblyName(@"C:\The.Product.Name.15.5.0.0.dll");

                return Assembly.LoadFile(@"C:\The.Product.Name.15.5.0.0.dll");
            }
            else
            {
                return null;
            }
        };
    }

In order to get this to work, I have to remove/rename the normal product .dll file in its default location, and I put the new version in simply the root C:\ directory (as the code shows). The reason for removing the .dll from its normal location is so the "AssemblyResolve" handler fires, because the referenced assembly cannot be found.

Anyway, with the above code my application gives the following exception: "An attempt was made to load an assembly from a network location which would have caused the assembly to be sandboxed in previous versions of the .NET Framework. This release of the .NET Framework does not enable CAS policy by default, ..." And so on.

What exactly am I doing wrong here? Does anyone even understand what I'm trying to accomplish? I can't believe this hasn't been done before but I am kind of at a loss at this point.

Any help would be greatly appreciated. Thank you.

Community
  • 1
  • 1
clamum
  • 1,237
  • 10
  • 18
  • 3
    Don't do this. Just use binding redirection. https://msdn.microsoft.com/en-us/library/7wd6ex19%28v=vs.110%29.aspx – xxbbcc Jul 09 '15 at 21:22
  • I appreciate the comment/help. Normally we don't use App.config files (keeping that sort of info in a database instead) but maybe we'll have to in this instance, at least for this purpose. I've created an App.config file for one of my applications to test it out, and added the node. Where would I put my new ProductName.dll file so my app can find it? Normally my apps run in C:\Programs and that folder contains the ProductName.dll as well. Currently, the old version is in that folder. What should I do with the new version? Thank you! – clamum Jul 10 '15 at 15:27
  • 1
    Just overwrite it. You build your code with v1 of the DLL (this gives you binaries). Then v2 comes out - just delete v1, put v2 in place and add the binding redirect locally in your config file. As long as v2 is binary backwards compatible, it'll work. If it's not compatible, you have to rebuild & redeploy. – xxbbcc Jul 10 '15 at 15:35
  • We ended up going the code route rather than the App.config route. It is working as far as I can see. I appreciate your help, xxbbcc. Something I'm thinking about though... say we have a "using" statement currently for a particular namespace. A new .dll version is released by this company and the namespace changes from "X" to "Y." I assume the application with the "using" statement, still referring to the old "X" namespace, will throw an exception and then require a rebuild? – clamum Jul 14 '15 at 15:34
  • 1
    Yes, a namespace change is a breaking change. (Adding a new namespace is fine, as long as the old one is unchanged.) The code route is really inflexible - make sure you understand what you're doing. The config change is very easy to maintain and to change. – xxbbcc Jul 14 '15 at 15:50

0 Answers0