locked
Code contract on interface methods

    General discussion

  • Hello guys,

    another quick question: should static analysis work against contracts defined for interfaces? here's a quick example:

    [ContractClass(typeof(PersonContract))]
        public interface IPerson
        {
            String FirstName { get; }
            String LastName { get; }
            void ChangeName(String firstName, String lastName);
        }

        [ContractClassFor(typeof(IPerson))]
        public class PersonContract:IPerson
        {
            public string FirstName
            {
                get { return CodeContract.Result<String>(); }
            }
            public string LastName
            {
                get { return CodeContract.Result<String>(); }
            }
            public void ChangeName(string firstName, string lastName)
            {
                CodeContract.Requires(firstName != null);
                CodeContract.Requires(lastName != null);
            }
        }

        public class Person:IPerson
        {
            private String _firstName;
            private String _lastName;

            public String FirstName
            {
                get { return _firstName; }
            }

            public String LastName
            {
                get { return _lastName; }
            }

            public void ChangeName(string firstName, string lastName)
            {
                _firstName = firstName;
                _lastName = lastName;
            }
        }

    Should the following code be caught during static analysis:

    var p = new Person();
    p.ChangeName(null, null);

    As you might guess, static analysis isn't picking this on my machine...

    thanks again

    Luis Abreu
    Friday, November 07, 2008 8:40 PM

All replies

  • Sigh. It should. I've fixed it and hope we can put out a new release soon. Sorry for the bugs! But I'm glad you are really trying it out.

    Currently the contract class needs to explicitly implement the interface methods, not implicitly as in your example. (But even if you do that, the released version won't work yet.) Do you think that is okay?

    Thanks!

    Mike
    Monday, November 10, 2008 3:40 AM
  • Hello Mike.

    thanks for the tip.

    Since the contract class is only there for setting up the contract, I think that explicitly implementation won't be too much to ask for.

    thanks again and keep up the good work!

    PS: don't forget to update the docs. I think that there's nothing in the current pdf which mentions that the contract class must implement the interface explicitly.

    Luis Abreu
    Wednesday, November 12, 2008 9:23 PM
  • Thanks for posting this.  What's really weird is  that this seems to work in VS2010, but not when run on my TFS 2010 Build server.  The VS2010 test seems to realize to expect a Contract exception and that's what the test harness produces in VS2010.  But when in TFS 2010, it knows to expect the Contract Exception, but does not receive it.  Maybe I just resaid what has already been stated.

    As I am evaluating this for use by my team, I think it is an easier sell if the Interface does enforce the contracts, or at least the compiler should verify that the derived class does enforce them.  No idea how hard it would be to enforce that.  Perhaps that's a Code Analysis feature.  But whatever the case, I'd like to keep the code repetition to a minimum or I'll get pushback from the DRY entusuiasts.

    Love the product though, so far.  Also agree on the docs... didn't even realize they were out of date.

    Friday, November 19, 2010 9:05 PM
  • Should have finished my testing before I posted on this one... but when I add the exact same code contracts from the interface into the class, and rerun the pex explorations, everything works fine on my PC.  But once I check in the updated files and tried to build on the TFS Build Server, I get the following:

    "The agent process was stopped while the build was running"

    This happens on 5 of my 13 generated tests, and then the rest are 'Not Executed'.

    I removed  the code contracts from the class, regenerated the Pex Explorations, checked in the changes, and the error went away (though I was back to expecting the wrong exception)

     

    Friday, November 19, 2010 9:20 PM
  • Anyone know why this build error is happening?  I've been going through scenarios for days trying to get some consistency, but if I can't get it, I'm going to have a really hard time selling this to my team as a useful tool for our next project.

    Thanks

    Tuesday, November 23, 2010 7:02 PM
  • It sounds as if some part of the contracts tools are not installed on your server. Can you send us the output from the rewriting step?
    Mike Barnett
    Friday, November 26, 2010 3:55 PM
  • Ah... yes, I had installed the PEX assemblies, but not the Code Contracts on the build server.  Installed those, rebuilt my tests and everything works great!  Thanks!

    Monday, November 29, 2010 6:07 PM