Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. General Programming
  3. C#
  4. Loading different versions of strongly named assemblies

Loading different versions of strongly named assemblies

Scheduled Pinned Locked Moved C#
csharpasp-netsysadminsecuritycollaboration
1 Posts 1 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • P Offline
    P Offline
    predakanga
    wrote on last edited by
    #1

    Hi all, I've recently been working on an IRC bot in C# (yes, I know there are a thousand others that could probably do what I want, but it was for the experience as much as anything) - the core of the bot works perfectly fine, but one of the subsystems, a plugin system, is giving me no end of grief. To support unloading plugins, I isolated plugins in their own appdomain, and so far that has worked just fine, but I recently implemented a few changes - I decided to write an auto-updater as a plugin, so I set the plugin appdomain to use shadow copying, and strongly named assemblies (for a bit of security). The auto-updater queries a server regularly, and downloads any new or updated assemblies to the plugin directory, before reloading the plugins. Now from what I've read, if shadow copying is enabled, when an assembly is loaded, it will first be copied to the shadow directory and then loaded from there, and any subsequent load attempts will use newer assemblies from the plugin directory (rather than the shadow copied version) if they exist. However, if I try to load the new assembly specifying a complete AppName, and the assembly version has changed, the load fails, with the fusion logs remarking that it found an assembly (purportedly in the plugin directory), but that it has the plugin version of the previously loaded assembly (I've checked in explorer, and it is definitely the correct version). I've been able to work around this by loading by using the codebase, but that has an unacceptable downside in that it doesn't check that the public key token matches. The only thing I can think of is that the previous version of the assembly is still loaded in a different appdomain. If anyone has any suggestions, or could put me right if I've made any incorrect assumptions, I'd appreciate it. The code is available, but I'd prefer not to check this broken code into my SVN if I don't have to. Apologies if that was too rambling, but it's early in the morning and I'm running low on caffeine.

    1 Reply Last reply
    0
    Reply
    • Reply as topic
    Log in to reply
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes


    • Login

    • Don't have an account? Register

    • Login or register to search.
    • First post
      Last post
    0
    • Categories
    • Recent
    • Tags
    • Popular
    • World
    • Users
    • Groups