If you make the old api obsolete, you'll get 43569 warnings in your testproject. You'll never be able to clean this up in a reasonable time. So you'll suppress them to get rid of it and will not see any obsolete warnings related to other stuff anymore.
I think, we can all stop talking about details and possibilities. I'm sure that the developers of Rhino know all the wishes and I'm also sure that they will find a solution. They already found tons of nice solutions for other problems, didn't they? On 4 Sep., 09:29, Mark Whitfeld <[email protected]> wrote: > Yeah. I think we are all on the same track here. > Backward compatibility in v4.0 is important, but should not mess with > the standard cleaner API for v4.0. > > My thoughts on the issue: > Have another dll called Rhino.Mocks.BackwardCompatibility.dll (or some > other name) which contains the old API possibly in a new namespace (R# > to the rescue for those old projects!). > This would not be a copy of the old project, but rather would contain > adapter classes which use internal methods in the new v4.0 > Rhino.Mocks.dll (friend assembly). > > I think that haifisch's suggestion of marking the 'old' API as > deprecated/obsolete is a good one (this could be done in the backward > compatibility dll). > In that way I could get a list of the tests needing upgrading by just > looking at the warnings on the project. Then, when I have no more > warnings then I know that I can remove the backward compatibility dll. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Rhino.Mocks" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/rhinomocks?hl=en -~----------~----~----~----~------~----~------~--~---
