0

I have a Xamarin Forms project that was originally created in VS 2017, and then we found out we needed to target Windows 8, so I'm working on getting the project up and running in VS 2015.

I initially tried just opening the 2017 project in 2015, and it seemed OK, but when building, I got errors on every single line that used the lambda syntax (=>), both within accessors and within regular function references. The errors are garden-variety syntax errors; the compiler doesn't seem to recognize the operator at all. For example, get => _privateVal; results in the error CS1043 { or ; expected.

I figured that it was a problem with opening a 2017 project in 2015, so I created a new project from scratch in 2015, but I have the same problem.

I don't have a lot of .NET experience, but lambdas have been around for a long time, so I don't know why a two-year old version of Visual Studio would have such a problem. I'm guessing it might be a build target problem (similar to Visual Studio 2008 doesn't recognize Lambda Expression Syntax) but if that's it, I really don't know how to correct it.

In summary, can anyone explain why C# doesn't recognize lambda syntax and have thoughts on how it can be fixed?

NineBerry
  • 26,306
  • 3
  • 62
  • 93
Ickster
  • 2,167
  • 4
  • 22
  • 43
  • Ya know, the answer might be the same, but the question isn't. Apparently the answer is that the features to support what I'm doing only came along in C# 7, which is after VS2015 came out. Not being a .NET guy, I haven't been able to figure out that although lambda syntax has been around for a long time, the particular functionality that adds it to accessors is new in 7. – Ickster Dec 02 '17 at 22:14
  • 1
    It's kinda lame that you have to know the language a platform uses before you can ask a question that people won't downvote. It's incredibly unfriendly to people new to the platform. – rianjs Dec 02 '17 at 22:18
  • 1
    No shit. I spent a few hours trying to figure this out, but since I'm new to the language, I didn't realize that the 'lambda' syntax in accessors isn't actually lambdas, so I was using the wrong wording in all of my searches. Apparently though, my question doesn't show research, isn't clear, or isn't useful. – Ickster Dec 02 '17 at 22:20
  • 2
    I have to agree with @rianjs (and with OP). We all had to start somewhere with the language(s) we write in - hell, I made so many mistakes referring to various things incorrectly! I think a possible reason for the downvotes, however, may be the clarity/context of the question itself. With the small amount of code you've posted it may be hard for us to diagnose the *actual* problem - albeit the accepted answer is the solution you're looking for. Try and include as much (relevant) code as possible, as to where the problem might lie and your post will get much more positive attention. – Geoff James Dec 02 '17 at 22:26
  • If you are doing a new project, I would recommend you to ignore Windows 8 as almost nobody use it. By targeting Windows 8, you probably loose a bunch of Windows 10 features and bug fixes and have less support and are developing using an obsolete framework. – Phil1970 Dec 02 '17 at 23:23
  • I've already lost the let's-not-support-Windows-8 battle; it's an internal app that needs to get deployed on a lot of devices that are still running 8. I pushed for an upgrade or at least a separate project to support 8 while keeping the rest of the project on the latest version by explaining that their shiny new mobile project would start off with tech debt by definition, but it didn't fly. Such is life. – Ickster Dec 03 '17 at 00:11

1 Answers1

7

Expression-bodied setters are a C# 7 language feature. In most cases, you need to use Visual Studio 2017 to use those language features, unless you want to swap the 2015 compiler.

rianjs
  • 7,767
  • 5
  • 24
  • 40
  • Hmmm. I'll look at replacing the compiler. I know that VS2017 flat-out doesn't support Windows 8-targeted projects, but I don't know if that means the IDE doesn't, or if the latest version of the C# compiler doesn't (or both). – Ickster Dec 02 '17 at 22:44