Partial Deployment- Comparing changed dlls

  • Thread starter Thread starter Jack Wright
  • Start date Start date
J

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 FieldNotFoundException.

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
 
Jack Wright said:
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 FieldNotFoundException.

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.
Click to expand...

Sounds like an interesting problem... You could use reflection to figure out
assembly dependencies (see Assembly.GetReferencedAssemblies). 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
 
Thanks Sami,
Sounds like an interesting problem... You could use reflection to figure out
assembly dependencies (see Assembly.GetReferencedAssemblies). 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.
Click to expand...
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
 
Jack Wright said:
Thanks Sami,
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...
Click to expand...

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
 
Back
Top