After installing the Asynchronous Programming for C# and Visual Basic CTP release, the async and await keywords are not supported by ReSharper. Will this be supported in a future version and is there a way to add that support now?
We are not going to support experimental builds of C# vNext compiler before we get any official information from the vendor about the future plans, features, etc. Please understand, that it is not just "parser", it is the whole infrastructure for new way of doing things and it doesn't make any sense to support it in an experimental mode.
Fair enough, I had hoped there was some kind of generic language definition xml that would allow us to use the CTP without Resharper choking on methods marked with async and blocks marked with await, but since that is not the case I'll just turn resharper off while experimenting with the CTP. Thanks for the response!
What would break current situation if you add the following:
async Task<T> Foo()
{
var a = await Xxx();
return new T(a);
}
check async modifier requirement with methods containing await
require these methods to be either void or return a Task<T>
all returns have expression of type T
all "await {expression}" simply can be replaced with "{expression}.Result" ({expression} is something of type Task<T>) for type analysis.
Compiler has to do fancy syntactic expansion, but for R# syntax validation do you really need to understand the details of this? This shouldn't go into primary release though, I'll be happy with some EAP build you guys are spawning too often anyway :)
Yes, we have the specs. Nobody said they are final, though. And who knows what other features there will be in C# 5, which will influence C# support in ReSharper. It would be just waste of time to support them now.
Sorry, that was more in reference to Alex for him to dig into the complexity of the feature. As I said before, definitely understand the difficulty in supporting an unreleased spec. Is there the possibility that ReSharper would not support C# in the future?
Why would ReSharper stop supporting C#? :)) No, it is not going to happen, provided world remains mostly the same and suddenly all developers do not stop using C# anymore.
Ilya, the point of my comment was that if you handle those items (and oh yeah, I forgot to mention anonymous functions with all their type inference jazz) things like control flow analysis shouldn't be affected. R# could still analyze an async method sequentially ignoring the fact that compiler does a complex transformation.
But I realize that it can't be as simple I see it from my viewpoint. Just augmenting a unit test collection to cover new specs would be a sizable project. I'd be really interesting to read more blogposts about not-so-obvious nuances of C# which from our standpoint as regular users of the language don't stand out as much as they do for you guys. Thanks for your hard work!
var x = from item in items where item > 10 select item.Foo;
This converts to
var x = items.Where(item => item > 10).Select(item => item.Foo);
depending on what is "items" (not necessary IEnumerable) and how methods Where and Select are implemented, item in the original query can have different type in where and select clause. Go figure how to handle this :)
A hotfix to simply ignore the keywords would be great, understand support is not feasible but just not highlighting the keywords red would be a great start, simply ignore them when parsing the code?
Now that the Async CTP SP1 Refresh has an Go-Live license, I am using this new feature and do not want to miss it anymore. Resharper's competition does not support it... yet. So I was looking for an alternative. If Resharper somehow supports the async/await keyword - or ignores it so that it does not get in its way - I am going to switch to Resharper...
I started using async/await to see how it works. It's awesome. Now, I don't need any callbacks and the using() statements to dispose everything work perfectly. The problem of TPL without the new feature or BackgroundWorker in general is that you need to take care of the callbacks. The more you refactor your code, the more event chains you have to maintain. The only problem of async/await is that ReSharper doesn't recognize it. Until MS releases VS2012/.NET5, just ignoring the keywords would work for me.
Here's a vote for simply ignoring the keywords as well, if possible. The CTP is just too useful to ignore right now and some large projects are using it already, such as Raven DB.
You have another vote from me for the feature that R# could ignore the new async keywords for now. I understand this might be a daunting task to implement, especially since you are working hard on stabilizing R# 6, however I would not ignore this important and useful CTP simply based on it being experimental. The Async CTP goes a long way in freeing us from callback-hell, giving us the benefit of faster development and cleaner, more maintainable code. Ultimately this is the same reason why we like working with R#, it's just a pity that their use is mutually exclusive.
Here's another vote for some kind of kludge to minimise the pain of using resharper with the Async CTP. I'm not expecting R# to pickup errors associated with incorrect async usage but it would be nice if it could suppress errors associated with these keywords so my R# error bar is no longer a sea of red :-)
Another vote for ignoring the keywords, or a pragma as suggested above. It would make our code so much cleaner to use async, but it's a no-go at present because of the clash with R#.
Another vote for ignoring the keywords! I'm trying Resharper after talking to a fellow developer, and hearing how fantastic it was. I'm rather heavily invested in the Async CTP (as Microsoft very kindly adjusted thier EULA) and seeing red squiggles makes me sad. :) Apart from that, I'm rather enjoying R#!
Yeah, another vote for just ignoring the keywords if possible until vNext. Really makes developing async code a pain with R# switched on, which means switching off a really important and expensive tool... I know full implementation and support would take time but simply ignoring the keywords would allow us all to continue developing.
The first one from JetBrains that posts a link to build 6.1.0.2421 will get "+1"'d from me. :D. Otherwise, a possible date for public access to 6.1 EAP would also suffice.
We are working on some other improvements and bugfixes for 6.1, so we cannot share builds right now. I think EAP builds will be available in a month or two, depending on their quality and completeness.
I saw in another forum that the plan was to release the 6.1 EAP in September, with less than two week left in September, is that still the plan? Do we have a date yet? This async issue is killing us. Even StyleCop for Resharper has added async support now.
I have to agree with Craig. As a developer writing LOB apps in Silverlight, it is very cumbersome not being able to use the Async language feature. I would much rather have async + a bug prone EAP of ReSharper 6.1, than having to choose between only one of them. Is there any insider news on the current state of 6.1 you could share with us? Much appreciated.
Support for async and await is not the only thing we do for ReSharper 6.x. Having EAP build for CTP product is itself quite a bit of pain, and we don't want to deliver half-baked build. As soon as build is stable enough to be useful, we'll deliver.
TeamCity Changes
async Task<T> Foo() { var a = await Xxx(); return new T(a); }Compiler has to do fancy syntactic expansion, but for R# syntax validation do you really need to understand the details of this? This shouldn't go into primary release though, I'll be happy with some EAP build you guys are spawning too often anyway :)
And for visual basic: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=7de30baf-b897-453e-ad18-e1ee2226ea86&displaylang=en
If you're looking for concrete information.
But I realize that it can't be as simple I see it from my viewpoint. Just augmenting a unit test collection to cover new specs would be a sizable project. I'd be really interesting to read more blogposts about not-so-obvious nuances of C# which from our standpoint as regular users of the language don't stand out as much as they do for you guys. Thanks for your hard work!
This converts to
depending on what is "items" (not necessary IEnumerable) and how methods Where and Select are implemented, item in the original query can have different type in where and select clause. Go figure how to handle this :)
We only want to use both Resharper and Async CTP.