Partial Deployment- Comparing changed dlls

[Jack Wright]

Dear All,
We are a company developing large scale software in .net Windows
Forms. We use the Updater Application for updating our clients. We
often send patches of our application. Our aim is to patch only those
dlls that have changed. We have a program that looks into VSS code to
check for changes in source code, but there is a limitation there, we
fall into trouble the following way:
1. We change a Object type in one.dll.
2. Since source of two.dll is not changed it is not shipped.
3. But in two.dll a function is accessing this Object.
4. So when the software is run we get a FieldNotFoundEx ception.

In the IL of that function it shows it is ldfld of the Object's
previous type.

When we compile we compile the whole source but send only the dlls
whose source has changed. Is there some automated way where I can
compare the IL code instead of the source code and send the changed
dlls? Please help.

Thanks and regards
Jack

[Sami Vaaraniemi]

"Jack Wright" <su***@volcanom ail.com> wrote in message
news:8f******** *************** ***@posting.goo gle.com...

Dear All,
We are a company developing large scale software in .net Windows
Forms. We use the Updater Application for updating our clients. We
often send patches of our application. Our aim is to patch only those
dlls that have changed. We have a program that looks into VSS code to
check for changes in source code, but there is a limitation there, we
fall into trouble the following way:
1. We change a Object type in one.dll.
2. Since source of two.dll is not changed it is not shipped.
3. But in two.dll a function is accessing this Object.
4. So when the software is run we get a FieldNotFoundEx ception.

In the IL of that function it shows it is ldfld of the Object's
previous type.

When we compile we compile the whole source but send only the dlls
whose source has changed. Is there some automated way where I can
compare the IL code instead of the source code and send the changed
dlls? Please help.

Sounds like an interesting problem... You could use reflection to figure out
assembly dependencies (see Assembly.GetRef erencedAssembli es). When one.dll
changes, to be on the safe side, you'll want to ship two.dll and other
assemblies that depend on one.dll.

Regards,
Sami

[Jack Wright]

Thanks Sami,

Sounds like an interesting problem... You could use reflection to figure out
assembly dependencies (see Assembly.GetRef erencedAssembli es). When one.dll
changes, to be on the safe side, you'll want to ship two.dll and other
assemblies that depend on one.dll.

But it is not soe simple...I only want to send two.dll if the older
one cannot work with the newer one.dll...I want to minimise the patch
sent...
One solution would be to get the IL code of older two.dll and compare
it with the newer two.dll and if there are obvious differences then
send two.dll along...fc is a good enough tool for doing this...but is
it the only way or are there brighter ideas...please help...

TALIA
Many regards,
Jack

[Sami Vaaraniemi]

"Jack Wright" <su***@volcanom ail.com> wrote in message
news:8f******** *************** ***@posting.goo gle.com...

Thanks Sami,

Sounds like an interesting problem... You could use reflection to figure
out
assembly dependencies (see Assembly.GetRef erencedAssembli es). When
one.dll
changes, to be on the safe side, you'll want to ship two.dll and other
assemblies that depend on one.dll.

But it is not soe simple...I only want to send two.dll if the older
one cannot work with the newer one.dll...I want to minimise the patch
sent...
One solution would be to get the IL code of older two.dll and compare
it with the newer two.dll and if there are obvious differences then
send two.dll along...fc is a good enough tool for doing this...but is
it the only way or are there brighter ideas...please help...

The problem is that it is untrivial to figure out which changes break
compatibility. If a field is removed from one.dll, that is of course a
compatibility-breaking change if two.dll uses to that field. Adding a method
to a class in one.dll might break things too if the component requires the
method to be called - it depends on the semantics of the class.

Analyzing IL would allow you to find structural breaking changes but it
sounds like a lot of work. I don't know your requirements but if I were
designing this sort of a system I'd aim for correctness and forget about
optimizing patch sizes, at least initially.

In the general case I can't really think of a good way to figure out
compatibility breaking changes other than perhaps using a unit-testing based
approach. Write a set of unit tests that excercise classes in two.dll. Run
the tests with old two.dll and new one.dll. If all the tests pass, then the
versions are "compatible ". Otherwise you know you'll need to ship two.dll
too.

Regards,
Sami