Let's say I have plug-in API. A number of assemblies implement
plug-in API version 1. Over time plug-in interface changes to version
2. How would you handle assemblies implementing old API?
10  1469 
Have the plug-in installed in the GAC. Then the version can coexist, that
is if you want to maintain legacy support.
"bazad" <no****@noreply.not> wrote in message
news:sl*******************@STA01052.itron.com... Let's say I have plug-in API. A number of assemblies implement
plug-in API version 1. Over time plug-in interface changes to version
2. How would you handle assemblies implementing old API?
Have the plug-in installed in the GAC. Then the version can coexist, that
is if you want to maintain legacy support.
"bazad" <no****@noreply.not> wrote in message
news:sl*******************@STA01052.itron.com... Let's say I have plug-in API. A number of assemblies implement
plug-in API version 1. Over time plug-in interface changes to version
2. How would you handle assemblies implementing old API?
In article <OP*************@TK2MSFTNGP10.phx.gbl>, Peter Rilling wrote: Have the plug-in installed in the GAC. Then the version can coexist, that
is if you want to maintain legacy support.
There is no point to use GAC for a plug-in. Plug-in by definition has
only one version.
The real problem is that the same process with a newer version of the
framework will need to be able to load assemblies. Some of these
assemblies implement the current IPlugIn interface version and some of
the assemblies were not upgraded and implement older version of the
interface. How do you handle that?
"bazad" <no****@noreply.not> wrote in message
news:sl*******************@STA01052.itron.com... Let's say I have plug-in API. A number of assemblies implement
plug-in API version 1. Over time plug-in interface changes to version
2. How would you handle assemblies implementing old API?
In article <OP*************@TK2MSFTNGP10.phx.gbl>, Peter Rilling wrote: Have the plug-in installed in the GAC. Then the version can coexist, that
is if you want to maintain legacy support.
There is no point to use GAC for a plug-in. Plug-in by definition has
only one version.
The real problem is that the same process with a newer version of the
framework will need to be able to load assemblies. Some of these
assemblies implement the current IPlugIn interface version and some of
the assemblies were not upgraded and implement older version of the
interface. How do you handle that?
"bazad" <no****@noreply.not> wrote in message
news:sl*******************@STA01052.itron.com... Let's say I have plug-in API. A number of assemblies implement
plug-in API version 1. Over time plug-in interface changes to version
2. How would you handle assemblies implementing old API?
"bazad" <no****@noreply.not> wrote in message
news:sl*******************@STA01052.itron.com... In article <OP*************@TK2MSFTNGP10.phx.gbl>, Peter Rilling wrote: Have the plug-in installed in the GAC. Then the version can coexist,
that is if you want to maintain legacy support.
There is no point to use GAC for a plug-in. Plug-in by definition has
only one version.
The real problem is that the same process with a newer version of the
framework will need to be able to load assemblies. Some of these
assemblies implement the current IPlugIn interface version and some of
the assemblies were not upgraded and implement older version of the
interface. How do you handle that?
Isn't that breaking one of the fundamental concepts of what an interface
provides. I always thought that once you release an interface you don't
change it...
"bazad" <no****@noreply.not> wrote in message
news:sl*******************@STA01052.itron.com... Let's say I have plug-in API. A number of assemblies implement
plug-in API version 1. Over time plug-in interface changes to version
2. How would you handle assemblies implementing old API?
"bazad" <no****@noreply.not> wrote in message
news:sl*******************@STA01052.itron.com... In article <OP*************@TK2MSFTNGP10.phx.gbl>, Peter Rilling wrote: Have the plug-in installed in the GAC. Then the version can coexist,
that is if you want to maintain legacy support.
There is no point to use GAC for a plug-in. Plug-in by definition has
only one version.
The real problem is that the same process with a newer version of the
framework will need to be able to load assemblies. Some of these
assemblies implement the current IPlugIn interface version and some of
the assemblies were not upgraded and implement older version of the
interface. How do you handle that?
Isn't that breaking one of the fundamental concepts of what an interface
provides. I always thought that once you release an interface you don't
change it...
"bazad" <no****@noreply.not> wrote in message
news:sl*******************@STA01052.itron.com... Let's say I have plug-in API. A number of assemblies implement
plug-in API version 1. Over time plug-in interface changes to version
2. How would you handle assemblies implementing old API?
In article <uB**************@TK2MSFTNGP10.phx.gbl>, Michael Riggio wrote:
"bazad" <no****@noreply.not> wrote in message
news:sl*******************@STA01052.itron.com... In article <OP*************@TK2MSFTNGP10.phx.gbl>, Peter Rilling wrote: > Have the plug-in installed in the GAC. Then the version can coexist, that > is if you want to maintain legacy support.
There is no point to use GAC for a plug-in. Plug-in by definition has
only one version.
The real problem is that the same process with a newer version of the
framework will need to be able to load assemblies. Some of these
assemblies implement the current IPlugIn interface version and some of
the assemblies were not upgraded and implement older version of the
interface. How do you handle that?
Isn't that breaking one of the fundamental concepts of what an interface
provides. I always thought that once you release an interface you don't
change it...
You are correct. But what do you do when requirements change over time? "bazad" <no****@noreply.not> wrote in message > news:sl*******************@STA01052.itron.com...
>> Let's say I have plug-in API. A number of assemblies implement
>> plug-in API version 1. Over time plug-in interface changes to version
>> 2. How would you handle assemblies implementing old API?
In article <uB**************@TK2MSFTNGP10.phx.gbl>, Michael Riggio wrote:
"bazad" <no****@noreply.not> wrote in message
news:sl*******************@STA01052.itron.com... In article <OP*************@TK2MSFTNGP10.phx.gbl>, Peter Rilling wrote: > Have the plug-in installed in the GAC. Then the version can coexist, that > is if you want to maintain legacy support.
There is no point to use GAC for a plug-in. Plug-in by definition has
only one version.
The real problem is that the same process with a newer version of the
framework will need to be able to load assemblies. Some of these
assemblies implement the current IPlugIn interface version and some of
the assemblies were not upgraded and implement older version of the
interface. How do you handle that?
Isn't that breaking one of the fundamental concepts of what an interface
provides. I always thought that once you release an interface you don't
change it...
You are correct. But what do you do when requirements change over time? "bazad" <no****@noreply.not> wrote in message > news:sl*******************@STA01052.itron.com...
>> Let's say I have plug-in API. A number of assemblies implement
>> plug-in API version 1. Over time plug-in interface changes to version
>> 2. How would you handle assemblies implementing old API?
comments inline...
"bazad" <no****@noreply.not> wrote in message
news:sl*******************@STA01052.itron.com... In article <uB**************@TK2MSFTNGP10.phx.gbl>, Michael Riggio wrote:
"bazad" <no****@noreply.not> wrote in message
news:sl*******************@STA01052.itron.com... In article <OP*************@TK2MSFTNGP10.phx.gbl>, Peter Rilling wrote:
> Have the plug-in installed in the GAC. Then the version can coexist,
that > is if you want to maintain legacy support.
There is no point to use GAC for a plug-in. Plug-in by definition has
only one version.
The real problem is that the same process with a newer version of the
framework will need to be able to load assemblies. Some of these
assemblies implement the current IPlugIn interface version and some of
the assemblies were not upgraded and implement older version of the
interface. How do you handle that?
Isn't that breaking one of the fundamental concepts of what an interface
provides. I always thought that once you release an interface you don't
change it...
You are correct. But what do you do when requirements change over time?
We introduce a new interface that the main object implements (so it now
implements both the new and old interfaces). Old clients will be able to
use the old interface and new clients can simply attempt to cast to the new
interface. Everyone is happy. "bazad" <no****@noreply.not> wrote in message
> news:sl*******************@STA01052.itron.com...
>> Let's say I have plug-in API. A number of assemblies implement
>> plug-in API version 1. Over time plug-in interface changes to
version >> 2. How would you handle assemblies implementing old API?
comments inline...
"bazad" <no****@noreply.not> wrote in message
news:sl*******************@STA01052.itron.com... In article <uB**************@TK2MSFTNGP10.phx.gbl>, Michael Riggio wrote:
"bazad" <no****@noreply.not> wrote in message
news:sl*******************@STA01052.itron.com... In article <OP*************@TK2MSFTNGP10.phx.gbl>, Peter Rilling wrote:
> Have the plug-in installed in the GAC. Then the version can coexist,
that > is if you want to maintain legacy support.
There is no point to use GAC for a plug-in. Plug-in by definition has
only one version.
The real problem is that the same process with a newer version of the
framework will need to be able to load assemblies. Some of these
assemblies implement the current IPlugIn interface version and some of
the assemblies were not upgraded and implement older version of the
interface. How do you handle that?
Isn't that breaking one of the fundamental concepts of what an interface
provides. I always thought that once you release an interface you don't
change it...
You are correct. But what do you do when requirements change over time?
We introduce a new interface that the main object implements (so it now
implements both the new and old interfaces). Old clients will be able to
use the old interface and new clients can simply attempt to cast to the new
interface. Everyone is happy. "bazad" <no****@noreply.not> wrote in message
> news:sl*******************@STA01052.itron.com...
>> Let's say I have plug-in API. A number of assemblies implement
>> plug-in API version 1. Over time plug-in interface changes to
version >> 2. How would you handle assemblies implementing old API?
This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Mart Rogers |
last post by:
We have a situation where we have decided (in an attempt to keep things
simple) to stick to local assemblies rather than global ones.
However we now have the following situation looming
AssyA ...
|
by: KWilliams |
last post by:
Hello,
We are trying to set up replication between different versions of SQL
Server (7 & 2000).
This is how the 2 servers are now setup:
DB1 - External web-server w/SQL Server 7
DB2 -...
|
by: Ken Durden |
last post by:
I'm working on a client-server application where the client is
controlling two devices (aka servers) which both implement the same
interface contract.
We have a set of about 4 assemblies which...
|
by: zorro |
last post by:
Hello,
If I have to test my code on different Netscape versions, can I
download and run those versions on the same computer or will it create
conflicts? And if I had to test only one version...
|
by: Max M |
last post by:
I would like to install several copies of Python 2.4.2 on my machine,
but it doesn't seem to be possible.
If I allready has a version installed, the installer only gives the
options to:
-...
|
by: Mary Jane Pronio |
last post by:
Any information would be greatly appreciated~~!!
Thanks!
|
by: Ecohouse |
last post by:
I have a computer with XP on it. I loaded Office 97 first because I
needed Access 97 for some work. I then loaded Office 2000.
Everything seemed to be running fine. But I have come across a few...
|
by: Squirrel |
last post by:
I've developed an Access 2002 database which will be deployed with the
backend on
a server and frontend on the users' PCs. I've now been advised that new
employees will
be given laptops with...
|
by: Brinkie |
last post by:
Hi,
I have the following situation:
I have a COM enabled application installed on multiple machines. I'm
building a management application for the COM application. Normaly this is
very easy...
|
by: =?Utf-8?B?a3lvbmc=?= |
last post by:
Quick question.
Say I have a project against the 2.0framework. I also have a dll compiled
against 3.5. If I reference the 3.5 dll in the 2.0 project, how would that
work?
So I'm thinking that...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
| |
