Visual Studio 2017: March 7th
-
Everyone, get your detectors ready: you have six days! :D
-
@RaceProUK 2015 was shit. I prefer 5th sequel 2010.
-
I've been using the RC. It's a bit buggy but seems quite nice
-
@Jaloopa I've not used it much (happy with VS2015 for now), but I've not seen anything that makes me think it's not worth switching. Then again, I've not seen anything that makes it worth switching either.
-
@RaceProUK Is 2017 free and doesn't call back home like everytime I touch a key?
I use PVTS for python stuff and 2010 is still better than most of this crap.
-
@RaceProUK Yeah, there haven't really been any major visible changes since 2012. I'll probably start using it properly once it's officially released, but if I didn't have it as part of my MSDN subscription I wouldn't be that bothered
-
@lucas1 I believe there'll be a free Community Edition, like 2013 and 2015. Not sure if a Microsoft Account will be mandatory or not though.
-
@RaceProUK It's been increasingly stable as of late.
The best things it offers:
- NCrunch-alike continuous testing for MSTest 2
- New exception dialog
- Installs really fast
- Can root the solution explorer at a folder
- A few more annoying C# features I hope no one uses
- Better refactorings and suggestions
-
@RaceProUK It is. Using 2015 for current work. Totally wank. Tries to do too much.
-
@Magus said in Visual Studio 2017: March 7th:
A few more annoying C# features I hope no one uses
The new stuff for C# 7, I presume. Yeah, I'm not find of some of the new stuff either. The tuple stuff couple be useful though.
-
@RaceProUK It never has been, and lets you use multiple if needed (I know I do).
Besides, the biggest change from 2012 to 2015 was Roslyn taking over as the compiler, making it so they can offer the whole analyzer thing.
-
@Magus said in Visual Studio 2017: March 7th:
NCrunch-alike continuous testing for MSTest 2
New exception dialog
Installs really fast
Can root the solution explorer at a folder
A few more annoying C# features I hope no one uses
Better refactorings and suggestionsAll those look like 2-3 minor releases' worth of work and a plugin (NCrunch), to be honest.
And yet it's a full-fledged major version, which means at least 2-3 months before both it and the plugins iron out the kinks.
-
@Maciejasjmj They've reworked the whole installer too, so now you don't install features, you install 'workflows'.
-
@RaceProUK said in Visual Studio 2017: March 7th:
Then again, I've not seen anything that makes it worth switching either.
The most important reason for upgrading is that their C++ support is getting better with every release.
-
@RaceProUK said in Visual Studio 2017: March 7th:
Everyone, get your detectors ready: you have six days! :D
When I join this company, they installed Traditional Chinese version of VS2015 to me, and I can't understand the option, menu items and others.
I'm lookup forward for the launch of VS2017 as an excuse for reinstallation. (Here we developers are not given local admin access to the desktops so I can't do reinstallation myself. Only the support staffs have it.)
-
@cheong said in Visual Studio 2017: March 7th:
we developers are not given local admin access to the desktops
I know it's not uncommon, but still worthy.
-
@Maciejasjmj said in Visual Studio 2017: March 7th:
@cheong said in Visual Studio 2017: March 7th:
we developers are not given local admin access to the desktops
I know it's not uncommon, but still worthy.
Btw, this is the main version why lots of out long-running applications are written as console applications but not as Windows Services. When we write a service we cannot test install/run it and see if it works or not.
-
@RaceProUK Workflows sound homosexual. Not installing that.
-
You can install already.
Installs faster, choosing "workflows" makes it a bit hard to find what you want, but its ok.
Upon a quick look I do not see any difference between 2017 and 2015.
Unreal Engine still prefers to work with 2015.
I heard UE is also fine with VS2017, didn't try myself.
-
Our canary user (I couldn't stop him from upgrading the minute it's available if I tried) is girding his loins as we speak.
Last time we had issues with the corporate MITM firewall borking all HTTPS between VS and it's authentication servers, nuget, etc.
His response until the issue was fixed was to skive off all day at the office and go home and work all night, disconnecting from the VPN whenever he needed HTTPS to work. Because just using VS2013 was unacceptable.
-
@Weng Is said canary aware he can run 2013, 2015, and 2017 side by side?
-
@RaceProUK He does. But he refuses to use the older ones.
-
@RaceProUK What the point of using anything lower than 2012 if you are using 2015+. 2010 is old enough to be incompatible and different. 2013 up I can't tell the difference.
-
Hell, when VS2013 came out we were still using ancient TFS and it wouldn't work. He would load 2012 to do his source control and switch back into 2013.
-
@Weng Does the twat know that TFS works on the command line as well. Sack the twat.
-
@lucas1 MS's artificial limitations on what versions can develop Store apps for Windows 8, 8.1, and 10.
-
... Of course, we're only using Ancient+1 TFS now. I wonder if they broke that....
-
@Magus I also like live-editing XAML. No more restarting the app just because you discovered that your positioning was just a bit off.
-
@RaceProUK I mostly do web apps. So 2010 is good enough (most of the time) and after 2013 I can't tell the difference.
-
@lucas1 that's probably how he did it, using the older versions commandline. I didn't pay any actual attention because it was all stupid.
-
@lucas1 said in Visual Studio 2017: March 7th:
@RaceProUK I mostly do web apps. So 2010 is good enough (most of the time) and after 2013 I can't tell the difference.
Then clearly that's good enough for everyone.
-
@Weng The commandline tools bring up a winforms app, so fuck knows tbh.
-
@heterodox Did I say that? Oh no I didn't.
-
@Rhywden said in Visual Studio 2017: March 7th:
I also like live-editing XAML.
I forgot about that: that'll come in handy with a personal project I recently started.
-
@Rhywden Anything in .NET that binds itself to an XML or HTML-esque front end you can edited without a recompile. The binding is done at runtime.
-
Honestly, this new version feels like mostly minor things, but some of it is really nice, like the docker service fabric and docker deployment options. I've only been mentioning things that are relevant to me.
Overall it seems to run a bit better, especially on large solutions, and has been overall less buggy than 2015 ime.
Our team's reliance on a legacy application makes the docker stuff a win, to the point where we really have to install it as soon as possible, but I seriously think its worth it anyway.
And if Roslyn is finally a bit more complete (You guys remember when I wrote the variable shadowing analyzer a few months back? Stuff was conspicuously missing.) that will also be a plus.
-
@Magus said in Visual Studio 2017: March 7th:
A few more annoying C# features I hope no one uses
@RaceProUK said in Visual Studio 2017: March 7th:
The new stuff for C# 7, I presume. Yeah, I'm not find of some of the new stuff either.
Such as?
@Magus said in Visual Studio 2017: March 7th:
You guys remember when I wrote the variable shadowing analyzer a few months back?
No?
-
-
@RaceProUK LOL Didn't even know you could do half of this stuff now. I am still doing C# 4.
It looks a lot like typescript features that are being added.
-
@RaceProUK I seriously never want to see a ref return used anywhere. It's a terrible, TERRIBLE idea.
The pattern matching, though, is great.
EDIT: Though that ref local to dynamically index a location in a struct seems cool.
-
@Magus My options are thus:
- Out variables: Could be useful, as I have several times declared a variable just to sink an
out
value. - Pattern matching: Hell yes! The power this will give to
if
andswitch
is going to be so worth it! - Tuples: These look pretty damn useful too, and should be easier to use than the
Tuple<>
family. The IntelliSense improvements alone will be worth it. - Deconstruction: See Tuples.
- Local functions: This is one of the things I like about JavaScript, and it's good to see C# adopt them, as long as they allow for recursion, like the JS ones do.
- Literal improvements: I don't see me using this much, but it's nice to know it's there.
- Ref returns and locals: No. Just no. It's pointers by the back door.
- Generalized async return types: Sounds useful, though I'd prefer a way to avoid the
Task<>
syntax in the first place. - More expression bodied members: Expansion of an already useful feature is good, so long as it's used right.
- Throw expressions: Another thing I don't see me using often, but could come in handy.
- Out variables: Could be useful, as I have several times declared a variable just to sink an
-
What's wrong with ref returns/locals? They're not pointers but well-managed references that the compiler proves to be safe to use for you. (Just like existing ref/out parameters).
I didn't have any cases I wanted to use these myself, but it sounds like it can help when dealing with performance-critical code that uses structs, so I see no harm.
-
@RaceProUK said in Visual Studio 2017: March 7th:
@Magus My options are thus:
- Out variables: Could be useful, as I have several times declared a variable just to sink an
out
value.
Pretty much, yeah
- Pattern matching: Hell yes! The power this will give to
if
andswitch
is going to be so worth it!
Meh. C# is finally just beginning to catch up to what Boo's been able to do for 10 years now.
- Tuples: These look pretty damn useful too, and should be easier to use than the
Tuple<>
family. The IntelliSense improvements alone will be worth it. - Deconstruction: See Tuples.
- Literal improvements: I don't see me using this much, but it's nice to know it's there.
Again, C# is late to the party. Other CLR languages have had this for years. (But of course the C# team goes and introduces some new and incompatible implementation of it because NIH.)
- Local functions: This is one of the things I like about JavaScript, and it's good to see C# adopt them, as long as they allow for recursion, like the JS ones do.
What's the point? Does this provide anything at all that we can't already do with delegates and lambdas? Do we really need a third syntax variant for declaring a function inside a function???
- Ref returns and locals: No. Just no. It's pointers by the back door.
...with appropriate restrictions to keep it verifiable. The biggest problem with pointers was that you could get them pointing to garbage and end up with arbitrary memory access and stompage. If you can't do that here, more power to you!
- Generalized async return types: Sounds useful, though I'd prefer a way to avoid the
Task<>
syntax in the first place.
Meh. Is there anything wrong with
Task
s, that you need your own task class instead?- More expression bodied members: Expansion of an already useful feature is good, so long as it's used right.
- Throw expressions: Another thing I don't see me using often, but could come in handy.
Anything that lets you cut down on the amount of
{}
cluttering things up is an improvement.
- Out variables: Could be useful, as I have several times declared a variable just to sink an
-
@RaceProUK As to the ref locals at least, I can kind of see the advantage in the situation they describe, and it seems like the kind of thing I've occasionally felt a need for.
As for the tasky stuff, I don't really get the point, since you'll still never be dealing with that stuff: You just await them anyway. You only ever see them in the method definition, or when calling async code synchronously, which is generally a bad thing to do anyway. I just don't get why they're bothering.
-
@CreatedToDislikeThis Ref returns just seem hard to understand. I'm sure there is a valid use for them, but if you have to spend an extra 10 minutes staring at it to figure it out, it's just not worth it.
-
@masonwheeler said in Visual Studio 2017: March 7th:
What's the point? Does this provide anything at all that we can't already do with delegates and lambdas? Do we really need a third syntax variant for declaring a function inside a function???
The main issue with using lambdas/delegates as local functions is that:
- You can't assign them to "var" - you have to specify their type explicitly (due to it being possible to treat them either as a delegate or as an expression tree).
- You can't use recursion unless (IIRC) you split the declaration of the variable and its assignment into separate lines.
So having a new syntax that does away with these restrictions* is definitely a good thing, especially as the syntax is identical to the existing method declaration syntax, so you can think of it as an extension of an existing function syntax rather than a new one.
*At least I hope it allows recursion!
-
@Magus said in Visual Studio 2017: March 7th:
As for the tasky stuff, I don't really get the point, since you'll still never be dealing with that stuff: You just await them anyway. You only ever see them in the method definition, or when calling async code synchronously, which is generally a bad thing to do anyway. I just don't get why they're bothering.
I think the idea is that once they implement a ValueTask<T>, you'll be able to use it to improve performance for async methods that usually return immediately and return a struct - there'll be less (hopefully zero?) allocations that way.
Ways to improve performance while mangling a minimal amount of code are always welcome, IMO.
-
@RaceProUK said in Visual Studio 2017: March 7th:
Generalized async return types: Sounds useful, though I'd prefer a way to avoid the Task<> syntax in the first place.
I will add that having to write out Task<> explicitly, as RaceProUK mentions, is not only ornery but will also prevent the ValueTask<> optimization from being carried out automatically.
-
@CreatedToDislikeThis said in Visual Studio 2017: March 7th:
The main issue with using lambdas/delegates as local functions is that:
- You can't assign them to "var" - you have to specify their type explicitly (due to it being possible to treat them either as a delegate or as an expression tree).
- You can't use recursion unless (IIRC) you split the declaration of the variable and its assignment into separate lines.
Both of these could be trivially fixed by fixing the language, without having to invent yet another nested-function syntax.
- It's always a delegate by default unless it's being explicitly assigned/passed to a variable/property/argument of an expression tree type.
- Special-case the definite assignment rule to be aware of the fact that assigning a lambda to a variable always means that that variable will be assigned before the lambda is executed.
-
@masonwheeler Yeah, could be.
But I think there's still a place for local functions alongside lambdas -
int doMyThing (int x)
{
... some code ..
}Just reads better than
var doMyThing = (int x) =>
{
... some code ..
}Lambdas are great for quick & simple function parameters, but local functions read better when you want a well-defined "sub-function" inside your function.
And yes, the fact that's there's a third function syntax (using "delegate") in C# is unfortunate, but it's basically deprecated, so I don't mind it not being taken into account when deciding which features to add.