Hi

I've been working on a collection of custom controls that inherit a lot
of the basic windows controls with a few additional things, one of
which means every single custom control references a dll that gives
dynamic functionality to the controls.

The only problem is that this dll will be worked on constantly with
extra functionality and fixes done to it, whilst my controls don't
require many updates.

Currently everytime the other dll changes I have to do a mass build of
a lot of projects just so that the new version can be used without the
program that uses them bombing out.

is there any way to make my controls to be able to use the .dll without
being so dependant upon a specific version? all the dlls are strong
named (the problem existed before strong naming anyway)

many thanks

Kris Wragg

Hi,


"Kristopher Wragg" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Hi

> The only problem is that this dll will be worked on constantly with
> extra functionality and fixes done to it, whilst my controls don't
> require many updates.

Do you change the interface of the types defined in these dlls?

If not what you can do is using interfaces. You define an interface and
store it in a separate dll (this part is important) and both your controls
as well as the dlls use this interface.
You can load the dlls needed using reflection at runtime.



--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation

At the moment there isn't any interfaces being used, not sure how much
work would be involved in moving that direction as I'm not actually
working on the other dll developer from another office is working on
it.

There will only be extra functionality added to the classes, theres
just one main class the other classes are for the property grid with a
UITypeEditor etc...

are there any other approaches? if not any more information regarding
loading the dll's with reflection? it sounds not particulally the best
idea in the world as the controls will be part of a designing tool
where the end user can drag and drop these controls to make their own
dynamically created views.

thanks

Kris Wragg

"Kristopher Wragg" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> At the moment there isn't any interfaces being used, not sure how much
> work would be involved in moving that direction as I'm not actually
> working on the other dll developer from another office is working on
> it.
>
> There will only be extra functionality added to the classes, theres
> just one main class the other classes are for the property grid with a
> UITypeEditor etc...
>
> are there any other approaches? if not any more information regarding
> loading the dll's with reflection? it sounds not particulally the best
> idea in the world as the controls will be part of a designing tool
> where the end user can drag and drop these controls to make their own
> dynamically created views.
>

Are you incrementing the AssemblyVersion on each build? If so, stop doing
that. It's very bad practice. Use AssemblyFileVersion to track builds, and
only change AssemblyVersion when you want force recompilation of dependant
assemblies.

David

Well we had the idea of leaving it always as 1.0.0.0 but we thought
that would be pretty bad practise as we wouldn't be able to ask
customers to provide version numbers as it wouldn't be significant.

One of the main problems also lies in the fact that although we can
release a whole set of new controls based on say 1.0.0.1 customers can
create their own controls/views dynamically with our program, which
will be based on 1.0.0.0 so when we update them to 1.0.0.1 they'll
suddenly have to go and recreate everything they've ever done...

The more I think about this problem the worse it's sounding...

I'm not sure if using interfaces is the answer to the solution... the
only code that actually uses the other class looks like this:

private AlertSelector selector = new AlertSelector();

[Browsable(true), Category("Behavior")]
[Editor(typeof(SelectorEditor), typeof(UITypeEditor))]
public AlertSelector Selector
{
get { return selector; }
set { selector = value; }
}

its just a property that the user can then get access to and make
changes through the property grid when designing their own views... I
don't have a clue how that would be implemented using interfaces...

As for not auto-incrementing, thats fine whilst the product isn't
released, but once the end-users are creating their own dll's through
our view builder and they references v1.0.0.0 and we release v1.0.0.1
all their current work will be unusable...

are there any other ideas? I've got till Friday to fix this problem for
my boss before he fly's off to the US with out beta version =\

"Kristopher Wragg" wrote:

> The only problem is that this dll will be worked on constantly with
> extra functionality and fixes done to it, whilst my controls don't
> require many updates.
>
> Currently everytime the other dll changes I have to do a mass build of
> a lot of projects just so that the new version can be used without the
> program that uses them bombing out.

I believe this is what the GAC is for. It basically allows you to tell the
..Net framework that you're taking responsibility for maintaining
compatibility between versions, and you can say something like "anything that
requires version 1.0.0.0 of my dll can really safely use 1.0.3.42". While I
haven't ever worked with anything like that, my understanding is that the
stuff for creating distributions can handle installing things to the GAC if
you give it the relevant information.

Yeah I've found that I can install a policy into the GAC for my dll's,
but I think I've found a more relevant way of doing it through
IExplore.exe.config for when customers are viewing things through IE.
And do the policy for the machines that are building the views.

Just having trouble with some of my controls permissions now...
overriding CreateParams needs Full permissions, which I have due to a
CAS policy with regards to our digital certificate but I can't find how
to assert this permission at the right place due to CreateParams being
a property not a procedure or class...