cannot await in the body of a catch clause

[taualex]

The ReVision.Forms.WSHandler (line 97) is using one of the C# 6.0 features - await in the catch() clause. There are few solutions for this:

1) move await outside the catch() clause 2) install Roslyn package for VS13 3) move the projects for .net 4.6 and VS15 4) install .net 4.6 target for VS13 and use 4.6 as target for all the projects - this is probably the most sensible solution.

Which one would be preferred? I was considering creating a VS15 solution (in addition to the default one for VS13) and project files for people that use VS15 (including me), then use compile directives to have 4.6 and 4.5 features separated.

[taualex]

For now I moved the await outside the catch() clause, so I can compile and run.

[Terricide]

I'm happy to use 4.6. I'm using visual studio 2015 but it was compiling and working for me no problems and I didn't see a reason to require 4.6. But I also want to see if we can target asp.net core

[taualex]

Corrected: initially I wrote a comment under the assumption that issue #2 was related to using VS2013 and .net 4.5, but I realized that you are using VS2015 and .net 4.5. I loaded the project in VS2013 (C# 5.0) and it gave me the compile error above. I need to use VS2015 (C# 6.0) and .net 4.5 - my bad! I'm going to revert my changes for this issue, then close it.

There are few good reasons why .net 4.6 can be used - mainly a better Garbage Collector (compacting heap feature?) and some improvements for WebSockets/await/async. I noticed our production pools work better under 4.6.

[Terricide]

Lets just go for .net 4.6 because I also wanted to take advantage of the null propagation operator when checking to see if event handlers were null

[Terricide]

By the way did you see that I added mousemove, mouseenter and mouseleave support? And the ability to use custom controls that override the onpaint method?

[vikingau]

Hi, Guys, You can use Palli's VWGProjectConverter to move the project between VS versions. I decompiled it (naughty) and removed a restriction so that it will work on any VS project, not just VWG. So, as long a there are defs for each language variant, then the project can be converted as required. I also would like that capability because at the moment, my hosted VWG project sites are all restricted to .Net 3.5 or 4.0, and too expensive for me to move to newer .Net hosting. So, can we keep in mind that not everyone is able to use 4.5+. Of course where that becomes impossible or the language features are not available, then everyone like me will need to bite the bullet. Thanks, Geoff

[taualex]

Mark - that's awesome!

Geoff - that might be tricky... while differences between 4.5 and 4.6 are not too many, there is a lot of code that will need to be re-written to support 3.5/4.0, mainly around await/async and Tasks. Keep in mind, I think it will be about 12-18 month before ReVision reaches true production maturity, and by that time the need for 3.5/4.0 will be gone, just like 2.0 nowadays. Your hosting could be on Win12/.net 4.6 by that time, because Microsoft will be dropping full support for Win2008 in 2017, I think...

[taualex]

I just reverted my changes for this issue, going forward, I'm using VS2015.

[Terricide]

If you need to backport it to .net 4.0 you could look at the Microsoft package https://www.nuget.org/packages/Microsoft.Bcl.Async which backports async/await to .net 4.0

[vikingau]

Hi, All. Given that it will be tricky and cumbersome, and there is a long way to go, I think development should only consider newer technologies say from .Net 4.5 and VS2013(2?). What ever has the native level of functionality required. If it comes to the day when I or others have to upgrade clients or freeze the application, then that's just the way it is... I'll be installing VS2015 over the coming days... Geoff