none
Is there a way to load Plug-ins to a Strongly Named SDK without concern for build number portion of version RRS feed

  • Question

  • Hello,
      I am pretty sure this belongs here, but if another forum would be more appropriate, just let me know.  The issue I am faced with requires a little background information:
    • I am working on an SDK to be used internally within my company
    • We have different product (hardware) teams that will be using this SDK
    • I have defined a set of interfaces that those teams must implement to "plug in to" the SDK
    The issue I am finding is that the plug-ins are attempting to load the SDK dll version 2.1.5689.0.  Meanwhile I am working on a bug in the SDK and the checked in version number is 2.1.5690.0.  So I am getting a load error because the plug-in dll tells the CLR to load build 5689 and I am working on the code after build 5690 has been done.  I can go get the teams code and rebuild it against the current build number of the SDK, but as the teams are sometimes in different countries and do not all use the same version of Visual Studio (some 2005 and some 2008), this is a problematic solution at best.  What I would like is for the CLR to load any 2.1 version of the SDK.  I am aware that I can configure the machine to load 2.1.5690.0 when 2.1.5689.0 is asked for, but it seems to me that I will be spending a great deal of time editing those rules every day.  Is there a way to build the plug-ins such that they will load the SDK based on major and minor version only?  BTW, the SDK is a set of strongly named assemblies.

    Thanks for your help on this
    Pat O

    Pat O
    Wednesday, November 19, 2008 6:31 PM

Answers

  • Just to offer you some other options, you could also consider:

    - Moving the plugin interfaces to a separate assembly that only contains interfaces, no implementation. That way it doesn't have to change so often once you've settled on the interfaces.

    -  Lock down the assembly version number (which is what the CLR loader cares about) and only change the file version number. This is basically what Microsoft does when versioning BCL assemblies from RCs to RTM to SPs.

    Mattias, C# MVP
    • Marked as answer by Zhi-Xin Ye Wednesday, November 26, 2008 10:40 AM
    Thursday, November 20, 2008 8:00 AM
    Moderator

All replies

  • Check out this page on Redirecting Assembly Versions on MSDN
    Wednesday, November 19, 2008 6:45 PM
  • Just don't put them in the GAC on your dev machine.  Copy them in your app's probing path, it won't check the version number.  The IDE supports this with the Copy Local option.
    Hans Passant.
    Wednesday, November 19, 2008 7:41 PM
    Moderator
  • Can I know what the probing path is, given that this is an SDK that will be used by a different group and installed  using their installer?


    Pat O
    Wednesday, November 19, 2008 9:01 PM
  • This is just for you to test the code, right?  You don't have to reproduce the exact same setup as your customer would use.  The default probing path is the same folder as the .exe
    Hans Passant.
    Wednesday, November 19, 2008 9:22 PM
    Moderator
  • I would not need to reproduce it, but this will need to work on my Customer's customers machine.

    Pat O
    Wednesday, November 19, 2008 10:40 PM
  • Which is an entirely different kind of test, the details of which you probably worked out a long time ago.  It sounds like you're not buying, what's the hang-up?
    Hans Passant.
    Wednesday, November 19, 2008 10:44 PM
    Moderator
  • Just to offer you some other options, you could also consider:

    - Moving the plugin interfaces to a separate assembly that only contains interfaces, no implementation. That way it doesn't have to change so often once you've settled on the interfaces.

    -  Lock down the assembly version number (which is what the CLR loader cares about) and only change the file version number. This is basically what Microsoft does when versioning BCL assemblies from RCs to RTM to SPs.

    Mattias, C# MVP
    • Marked as answer by Zhi-Xin Ye Wednesday, November 26, 2008 10:40 AM
    Thursday, November 20, 2008 8:00 AM
    Moderator