Hi;

We have an interface in our library (our_lib.dll). Users can create classes 
based on this interface that we then load when we are running.

The problem is each time we create a new version of windward.dll, the 
version number changes and our_lib.dll is strongly named. So if the user has 
their class build using version 4.1.22.1 of the interface from our_lib.dll 
and they are now running the newer version 4.1.22.3 of our_lib.dll, the 
interface does not match because the version number is different.

Which leads to two questions:

1) We are dynamically loading the user built class from their dll. How can I 
get the version numbers when there is a class cast exception? Because right 
now the message is can't cast to MyInterface from MyInterface which is 
non-sensical. (It's correct, but it strikes people as non-sensical.)

2) How can we set things in our code so it accepts any version of the 
interface that is 4.1.*.*

-- 
thanks - dave
david_at_windward_dot_net
http://www.windwardreports.com

Cubicle Wars - http://www.windwardreports.com/film.htm

David,


>The problem is each time we create a new version of windward.dll, the 
>version number changes and our_lib.dll is strongly named.


Is windward.dll the same as our_lib.dll or are you talking about two
different assemblies?



>1) We are dynamically loading the user built class from their dll. How can I 
>get the version numbers when there is a class cast exception? Because right 
>now the message is can't cast to MyInterface from MyInterface which is 
>non-sensical. (It's correct, but it strikes people as non-sensical.)


I don't think you can make the version number show in the excaption
message. But I'd also argue that you shouldn't show exception messages
to the user directly.



>2) How can we set things in our code so it accepts any version of the 
>interface that is 4.1.*.*


You can solve this with binding redirects in the application config
file or with publisher policy for our_lib.dll. Both procedures are
documented in MSDN.


Mattias

-- 
Mattias Sjgren [C# MVP]  mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.

Hi;

1) Sorry yes, windward.dll == our_lib.dll.

2) The person who will get the error message is a programmer 99% of the time 
so it would be very useful info for them.

3) This is in a Word AddIn so we are not allowed to put anything in the 
winword.exe.config file (Microsoft rule). And we would like for the rules on 
this to be installed with our_lib.dll. Is there a url somewhere that says 
what approach we want in that case and how to implement it? I did a search on 
publisher policy and got a ton of hits and it's not clear what exactly we 
should do.

-- 
thanks - dave
david_at_windward_dot_net
http://www.windwardreports.com

Cubicle Wars - http://www.windwardreports.com/film.htm




"Mattias Sjögren" wrote:


> David,
> 
> >The problem is each time we create a new version of windward.dll, the 
> >version number changes and our_lib.dll is strongly named.
> 
> Is windward.dll the same as our_lib.dll or are you talking about two
> different assemblies?
> 
> 
> >1) We are dynamically loading the user built class from their dll. How can I 
> >get the version numbers when there is a class cast exception? Because right 
> >now the message is can't cast to MyInterface from MyInterface which is 
> >non-sensical. (It's correct, but it strikes people as non-sensical.)
> 
> I don't think you can make the version number show in the excaption
> message. But I'd also argue that you shouldn't show exception messages
> to the user directly.
> 
> 
> >2) How can we set things in our code so it accepts any version of the 
> >interface that is 4.1.*.*
> 
> You can solve this with binding redirects in the application config
> file or with publisher policy for our_lib.dll. Both procedures are
> documented in MSDN.
> 
> 
> Mattias
> 
> -- 
> Mattias Sjögren [C# MVP]  mattias @ mvps.org
> http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
> Please reply only to the newsgroup.
> 

Hi Dave,

A publisher policy is usually used when you try to release an updated 
version of assembly and want to all your existing clients to automatically 
use the updated version without recompiling. However, by design, the 
publisher policy is only used to redirect from version that has change 
major.minor. In your case, the major.minor is not changed and only the 
build number is changed, therefore the publisher policy doesn't apply here.

On the other hand, I will discuss with you about your plugin (I don't use 
the add-in here to avoid confusing with Word add-in) architecture: normally 
we will put the interfaces required by a plugin into a separate assembly; 
this is usually called the "Host SDK". In your case, the Windward.dll 
should be the "Host Application", which references the "Host SDK" assembly 
and loads plugin implementations created by your users. The plugins will 
only reference your "Host SDK" but not your "Host Application". Normally a 
"Host SDK" will seldom change since it defines the contract between your 
"Host Application" and the plugin implementations. When the time comes that 
you need to change the interface, you will change the major.minor version 
of the "Host SDK", and then you can use publisher policy to redirect the 
"Host SDK" assembly (or the plugin implementations will be recompiled 
anyway).

If you follow this pattern, then whenever your "Host Application" (the 
Windward.dll) is changed, since the "Host SDK" is not changed, the plugin 
implementations will be still correctly loaded by it.

Hope this helps.


Regards,
Walter Wang (wawang@online.microsoft.com, remove 'online.')
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

Very good suggestion - thank you

-- 
thanks - dave
david_at_windward_dot_net
http://www.windwardreports.com

Cubicle Wars - http://www.windwardreports.com/film.htm




""Walter Wang [MSFT]"" wrote:


> Hi Dave,
> 
> A publisher policy is usually used when you try to release an updated 
> version of assembly and want to all your existing clients to automatically 
> use the updated version without recompiling. However, by design, the 
> publisher policy is only used to redirect from version that has change 
> major.minor. In your case, the major.minor is not changed and only the 
> build number is changed, therefore the publisher policy doesn't apply here.
> 
> On the other hand, I will discuss with you about your plugin (I don't use 
> the add-in here to avoid confusing with Word add-in) architecture: normally 
> we will put the interfaces required by a plugin into a separate assembly; 
> this is usually called the "Host SDK". In your case, the Windward.dll 
> should be the "Host Application", which references the "Host SDK" assembly 
> and loads plugin implementations created by your users. The plugins will 
> only reference your "Host SDK" but not your "Host Application". Normally a 
> "Host SDK" will seldom change since it defines the contract between your 
> "Host Application" and the plugin implementations. When the time comes that 
> you need to change the interface, you will change the major.minor version 
> of the "Host SDK", and then you can use publisher policy to redirect the 
> "Host SDK" assembly (or the plugin implementations will be recompiled 
> anyway).
> 
> If you follow this pattern, then whenever your "Host Application" (the 
> Windward.dll) is changed, since the "Host SDK" is not changed, the plugin 
> implementations will be still correctly loaded by it.
> 
> Hope this helps.
> 
> 
> Regards,
> Walter Wang (wawang@online.microsoft.com, remove 'online.')
> Microsoft Online Community Support
> 
> ==================================================
> When responding to posts, please "Reply to Group" via your newsreader so
> that others may learn and benefit from your issue.
> ==================================================
> 
> This posting is provided "AS IS" with no warranties, and confers no rights. 
> 
>