I am in the process of creating a .NET assembly that will be registered for COM so that it can be referenced by Microsoft Excel VBA.
The assembly references a third-party .NET assembly (that contains some useful classes) that is not in the GAC, however, I have a problem with the deployment of my assembly since the path to the third-party assembly is not always in the same location (it depends on the locale of the user as well as how recently the third-party assembly was installed).
This means that when deploying my assembly (using REGASM), depending on the system that it’s being installed on, REGASM will sometimes fall over as it could not find my assembly’s dependency on the third-party assembly.
Ideally I would like use early binding in my assembly, but if I do this and the path to the third-party assembly is not the same as the reference in Visual Studio then REGASM will fail.
I realise that “Copy Local” (in VS) would solve this, but as the third-party assembly is sometimes patched then I don’t really wish to keep an out of date version of it in the same folder as my assembly.
Is there a way around this so that I don’t have to use “Copy Local”? I suppose that I could use some kind of dynamic load of the third-party assembly, but then could still use early binding? (and would REGASM work?)
Why not use the ‘Copy local’ for first use, and have a routine on the application startup that goes thru a list of possible locations where the newer version might be and override (or schedule an override when not accessible etc.) the local assembly if possible.
Also, you might want to give the user an option to manually set a location where the dll should be opened from then you always (or on demand) check for newer versions.
Another aspect is, why would you want to update the new assembly if your application’s functionality depends on a certain version, since if they changed a feauture or what ever they efed up something you’re program will fail because of the update, just a thought.