It is a perfect tool in speaking of function. However, I also have the same problem that although 1.9.10714.2 is installed (on Visual Studio 2015). VS still tell me it needs to be updated from version 1.8.
I found following steps would work around.
1. After install the extension, open VS, you will see the notification tell you to upgrade the extension.
2. Close the VS.
3.Go into following three folders: 1.C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\Extensions\Microsoft\CodeContracts\1.9.10714.2 2. C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\Extensions\Microsoft\CodeContracts\1.9.10714.2 3.C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Extensions\Microsoft\CodeContracts\1.9.10714.2
4. You should find there is one file named extension.vsixmanifest in each of above three directory. Open it with notepad.
5. make sure in each of three file, on line 4, the value of Identity version is 1.9.10714.2. If not, change it to 1.9.10714 and save the change.
6. Restart VS two times, I don't know why, but first time it still tell me to upgrade, but second time and afterwards it's OK.
The version problem is due to old version information within the extension manifest files within the package. After installing, I modified the version field for Visual Studio 2015 to fix the problem on my machine.
Oh guys, you did it again - sort of ;-) I installed 1.9.10714.2 on a blank Win10 VS 2015 Community Edition and VS keeps complaining that an upgrade were available. As I found out today, someone forgot to correct the Identity Version in the extension.vsixmanifest file which still claims to be 1.8.10107.10 :-) (in a 1.9.10714.2 folder, very funny) Please fix :-)
My old review about other setup issues:
This is a great project but I'm affected by the installer issues, too - after all four or five installations since the first time I installed CodeContracts I had to clean up the
C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\Extensions\Microsoft\CodeContracts
directory. Uninstalled the old version first, then installed the new; like now there are two folders 1.7.10908.11 and 1.7.11106.10 of which I have to delete the former older one. Maybe you should explicitly delete the folder from within the MSI uninstall sequence. The files that get left behind and might not be authored for proper removal are:
This is a fantastic tool I just wish it didn't have the update issue. VS 2013 and 2015 both complain that an update is needed. VS 2013 wants to update from 1.7.11202.10 and 2015 wants to upgrade from 1.8.10107.10.
I've installed this version (1.9.10714.2) and it does seem to install into a directory with the same version number - but the manifest within claims to be a 1.8.something version and Visual Studio (2015) seems to therefore think that it still needs updating.
Overall I rate Code Contracts quite highly but I'm surprised by this issue occurring.
There is a risk with adopting tools that are pre-release. With Visual Studio 2015 coming out and little word on a update, I was worried. But, look, not a day after the Visual Studio 2015 RTM, a new version with 2015 Support.
Code Contracts is the most underrated and underused tool in the .Net ecosystem. I look forward to the day when it is fully and completely integrated with Visual Studio. Until then, I can only thanks Sergey Teplyakov and others for their work. I hope to find enough time to contribute to the project in the future.
Code Contracts is an excellent design and programming device but, as many already said, it is very frustrating that there are no signs for updating the tool for Visual Studio 2015. Can someone please break the silence and let us know what the plans are. We have existing projects relying on it - shall we rewrite our code? Please, someone say something.
This is a really good thing to have, and I was a fan of the entire idea of static analysis and especially the extreme advantages of having Code Contracts that you could actually manage constructively (such as keeping all the heaviest checks on a test version, while keeping only public surface ones for a stable environment, etc.)
However, the actual implementation has seriously lagged behind the actual tools. With the really cool features of the newest framework versions and also newest Visual Studios, the Code Contracts implementation just does not arrive fast enough for it to be a useable tool.
This coupled with strange issues and abysmal performance in some cases, makes it unusable in another context than just academic musing.
Also, one has to wonder whether this could not have actually been better done directly in the framework rather than through ccrewrite.
My team recently adopted code contracts. It's a fantastic tool that's already helped to catch some validation we would have missed otherwise. There's a learning curve for some devs who can't easily adapt to the contract way of thinking, but it's absolutely worth the curve and the time to bring people up to speed.
There are some places I wish the contracts and rewriter worked a little differently, but overall I think it's fantastic.
I will add to the requests for a MUCH needed update for VS2015. I installed the RC yesterday hoping to move my team to it next week, but we're on hold because of the ccrefgen errors related to ReadCustomMetadata.
Guys, these extensions are appreciated more than you'll ever know. YOU are unsung heroes. This pattern will no doubt grow across all aspects in computing. You have allowed us to prevent* bugs at code-time, *before* unit testing...
EDIT: I think the underlying neat synergy here is that as developers code Contract statements, it makes them *think about states, contexts, and very likely discover possible but unhandled states*. That, by itself, is fantastic ;)
There is no silver bullet, but this, combined with TFS check-in rules... = ? I don't know man... ;)
I bet a nickle at least one office conflict will be prevented (rather than resolved) as a result of this. And that is almost as good as saving a life ;) Kudos guys.
Roy Mayfield Enterprise Architect email@example.com