what commit is the tag? (hash)
@SergeyTeplyakov I replied to your comment in #106. I don't see a commit yet which has the correct version numbers, so I'm concerned about the release tag. I'm guessing you just haven't pushed the commit yet?
Yep, I didn't created a PR
#110
But even with this fix I was unable to build Code Contracts with VS2015
#39 this fix was critical
if anyone would be able to check, would be appreciated.
I'll work on this bug: Microsoft/CodeContracts#112
Unit test added. Bug reproduced
I've seen a few issues. I can't build tunnelvisionlabs/LangSvcV2 in debug mode but I can build it in release mode (the latter being a new ability of this release).
I'm headed to lunch ttyl
I've replied in the comment and will duplicated the idea here. Because rewriter operates on IL level I think there should be clear benefits of changing current logic. Like switching to TaskCompletionSource is super simple when dealing with C#, but not so simple when you need to do this from IL. So it should be clear benefits to do this. Maybe I missing something, but I can't see them right now...
@SergeyTeplyakov The rewriter is changing the semantics of asynchronous methods in a way that breaks exception handling. If you have a
catch (MyException) in your code that works, enabling the rewriter will force you to catch (AggregateException) instead. Also it breaks cancellation, turning all canceled tasks into faulted ones.
The only case it actually works for right now is tasks that run to completion.
ok. will do
at least we get to practice the release process :worried:
And, BTW, should we separate releases for editor extensions and the tool itself? this should simplify the overall release process...
If we decide to split the two, I think we should do it when the repository is moved by actually splitting the repository into two repositories, one for the tool and one for the editor extensions.
I think I'm done for right now. Off to watch a show.
I'll look back before bed.
BTW: I found more bugs but I haven't filed all yet. The only critical one I found though was the one I fixed in #117.
I recommend at least #117 and #120 for the updated release, and possibly #121 as well.
I'll merge PR's later today.
The problem with one release is following: new Code Contracts release means that production bits for the customers could be changed. No one can freely switch to new version of such tool without proper testing. This means that the overall requirements for Code Contracts is significatly different that for editor extension. I don't want to show an updates to Code Contracts tool if there is no changes. On the other hand I don't want to block editor extensions releases when new version become available.
Thats why I think different releases are important. Just because the goals of those tools are significantly different.
I think we already had the same discussion and it seems nothing had change from that time:)
I think I found a design flaw in #80 / #97. If there are both DBs installed, we might end up toggling between both versions if we just use the one that connects first. I'm not sure what happens if a file registered in v11 will be registered again in v12 - if they are binary compatible, it might work, but we might also end up destroying the cache every time we toggle between v11 and v12.