[Milestone discussion] VS2015 support

[SergeyTeplyakov]

I would like to put all bugs, issues and work items into one place to simplify our first and very important milestone - support for VS2015.

I would like to focus on this first and do the rest later. It means that we should try to focus our activities to get things done and release new version (I hope to release official version with support from @mike-barnett).

I can see following areas in this milestone:

Rewriter issues

• Support for async methods. Issues - Contract.Requires not rewritten in async methods compiled by Roslyn #51, fix - Fix for Roslyn async methods #74
• Issues with async methods with Contract.Ensures(Contract.ForAll) - NullReferenceException with lambda in requires of contract class in VS2015 #49, CCRewrite fails with NRE on async method with Ensures.ForAll with captured params because forwarder is null #72, CCRewrite fails with NRE on async method with Ensures.ForAll with captured params #69. Fix - Fix for Roslyn async methods #74
• Issue with iterator blocks with complex precondition for async methods and iterator blocks with preconditions mode only. Issue - CCRewriter produces invalid IL on async method or iterator blocks #38. I'll talk to original authors of this tool to understand potential fix.

VSIX support for VS2015

• I think we need to update VSIX package or installer to be able to use CC with VS2015.

❓ @sharwell Any ideas how to do this?

CC Editor Extensions

• Editor extension does not working with VS2013/VS2015. Issue: Support VS2013 for CC Editor Extensions #4, Fix: VSIX rework #66

❓ I don't know is it really necessary for this milestone. Because Editor Extension wasn't working for VS2013 as well, I would prefer to separate this activity from this one.

Other issues

• ILMerge. Fix: Updated ILMerge to latest version using NuGet #60.
• Build process issues. Issue: Can't run Foxtrot unit tests #70

❓ Any ideas about this milestone would be very helpful.

[aarondandy]

I think that for some people the CC Editor Extensions are very important. I would not hold off on releasing CC for VS 2015 over it but it should at least be in the next milestone. @Daniel-Svensson is at least one user that finds it important and I also would like to see that functionality.

[SergeyTeplyakov]

@aarondandy I'm not saying that CC Editor Extension is not important, I'm saying that we can split this into two releases. And, actually, Code Contracts itself and CC Editor Extensions are two different VSIX packages anyway. I'm just saying that this is two separate milestones that could be accomplished in parallel.

[sharwell]

#66 adds editor support for Visual Studio 2013, and a clear stepping stone for providing support for 2015 in a follow-up pull request. Initially I worked to modify the shared code to support both 2010-2013 and 2015, but the differences in 2015 turned out to be sufficiently complex that I'm planning to instead split the 2015-specific details into their own directory in the source tree. This would not affect our ability to ship a single VSIX that supports all versions of Visual Studio.

tl;dr Editor extension support for 2013 is already implemented (#66). 2015 is in progress, but I can't be certain when it will be finished.

[SergeyTeplyakov]

@sharwell As I mentioned already, I'm not arguing against CC Editor Extension, I'm just trying separate the concerns. I've created separate milestone (https://github.com/Microsoft/CodeContracts/milestones/CCEditorExtensionVS2015) and anyone can create the same ticket for tracking this milestone progress.

Editor Extension has different deliverables and I just can't understand why we should mix them up. We can do everything in parallel and deliver great experience in timely manner.

Those tools was always released separately and I don't think that for the very first release we should mix them up.

[SergeyTeplyakov]

❓ BTW @sharwell could you suggest what changes are required to get cccheck/ccrewrite integration with VS2015?

[sharwell]

In my previous comment, I was simply stating the current state of the items I was working on. Regarding the milestones, I would probably put all the issues into a single milestone initially. Then if one set of features reached completion and the other set still had significant work left, I'd split it at that point by simply moving all the remaining open issues from the first milestone to a new one.

The biggest issue for my code is ccrewrite functionality. We use Contract.Requires<TException>, which means without ccrewrite support Visual Studio 2015 is completely unusable for our project. I have not yet tested to see what is required, but I'm hoping to start testing this on Sunday (by "this", I mean the several open pull requests which are intended to solve some or all of the currently known problems).

I'm also thinking it would be a good idea to create a gitter room for the project, even if it means changing the room and losing history when the project moves to a new GitHub organization.

[SergeyTeplyakov]

Understood. You can pull my fix ( #74 ) and check is it working for you. If you have special test cases that you would like to test, just put them as a comment for PR.

I'll be talking with @mike-barnett tomorrow and we'll review my PR's (and other changes that I'm working on, including the fix for #38).

I've created a gitter chat room: https://gitter.im/Microsoft/CodeContracts