tags:

views:

69

answers:

1

Is there a way to check that the method signatures of a bunch of .NET dlls are "lined up" against one another? Basiclly what the complier does during compile time,but instead it would be trying me trying to move a single dll up instead of the whole group of 20 to fix a problem.

For example you have a function that lives in AssemblyB.dll

function foo(strMyValue as string, objObject as IObject)

turns into this a few months later

function foo(strMyValue as string, objObject as IObject2)

And you want to move AssemblyC which calls function foo from AssemblyB.dll. If you move all your dlls at one time, no problems because AssemblyC has the new method signature from AssembleyB and passes in the new type. But lets say there is an emergency and you need to just move AssemblyC up to fix a problem. The only way I know of to catch that is to actually hit the line of code that will call the method.

Things to consider I have no branch. I wish I did, but I wasn't around for the start of the system, and at the tail end of the system we don't have a way to get there.

I could move all my dlls, but there will be hundreds of undocumented changes that come along with that. The system currently sits at 4 million lines of code.

A: 

I assume what you're referring to is the fact that you've already made a bunch of changes that you're not necessarily ready to move live, but need to move a build in an emergency.

instead of turning

function foo(strMyValue as string, objObject as IObject)

into

function foo(strMyValue as string, objObject as IObject2)

Could you not overload foo to have both method signatures in AssemblyB? Obsolete the first function so that people will at least be told they shouldn't use it and then upload AssemblyC when you're ready to make the change to it? After that, once you're certain you've completely switched over, you can remove the original method signature.

If you never alter a method signature, you should never have a problem like that.

But, in my opinion... I'd get yourself up and running on some kind of source control.

Wes P
We use TFS right now, and just came from VSS. We wanted to put branches in, but previous developers created circular references on our old code.It would be great if the old methods were obsoleted, and we have started to do that, but not everyone did. With us having two souce controls, its not fun.
Josh