Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

.NET Hot Reload Support via CLI

devblogs.microsoft.com

Post reply on HN
Print view View original

261–267 of 267 posts

Re: .NET Hot Reload Support via CLI

#261

Post by Too »

pritambaral wrote: post #214
Too wrote: post #189

Earlier quoted context omitted.

Do you have any suggestion for alternative systems, which uses this supposedly "real" git flow, paired with reviews? All the git operations you listed work perfectly fine locally on a repo from github, it's only once you want to push to main you have to go through the review-gate and that's configurable. Gitlab works mostly the same as Github, and for both of them you can configure the merge-strategy and PR requireme…

> Do you have any suggestion for alternative systems, which uses this supposedly "real" git flow, paired with reviews? GitLab (I know it works, because I set up this workflow in my company). Before GitLab: Phabricator, Gerrit. > All the git operations you listed work perfectly fine locally on a repo from github ... Irrelevant. GitHub needs to be compatible with Git, not the other way around. This subthread began with…

The equivalent for fixing typos in a chain of commits in github is configure squash on merge, commit --fixup/--amend and finally push --force. Force pushing might ring some alarms and sound counter-intuitive, but as long as it's on an open PR that's not yet merged it's perfectly fine. In a way one could argue this is more git-native compared to Gerrits refs/for which does some server side processing of the Change-Id and whatnot to map it into one change. Biggest problem here is Githubs UI for indicating force-pushes is an abysmal line in the comment-list, instead of a showing all major updates to the branch in one place and mapping the comments to each of them.

Just small remark that I personally much prefer the Gerrit model over Github, both UI and the git interaction :) Just don't see either as any big barrier or deviation from git workflow, as long as you stay away from the github client of course.

Re: .NET Hot Reload Support via CLI

#262

Post by int_19h »

saghm wrote: post #255
int_19h wrote: post #251

Earlier quoted context omitted.

VS Code has integrated builds, testing, and debugging. I would argue that, by any sensible definition of IDE, it's an IDE.

I think it's possible to customize it to be an IDE in some cases, but at least for some languages, it's not one out of the box. I have no idea how most people use it, but it doesn't seem obvious to me that all or most users would necessarily use it as and consider it an IDE.

Well, out of the box, it really only supports JavaScript and TypeScript - and those two are at the level I'd consider to be an IDE (i.e. with debugging etc). Any other language requires an extension. But most major language extensions also provide a full suite of IDE services. Although sometimes that is spread across several different extensions - as with e.g. Java - but in that case, there's usually also an extension pack that gives you the unified experience.

Re: .NET Hot Reload Support via CLI

#263

Post by tekknik »

moonchrome wrote: post #222
katbyte wrote: post #95

Earlier quoted context omitted.

I get the all products pack every year personally and it's worth every penny. One of the two software packages i break my "no subscriptions" rule for, and the only one i'm not even salty about doing so.

This - if you're a professional software developer you'll find value in the 200€/year package for their tools. They are just good all around. My only gripe is not supporting remote development but it's in the works.

My problem with them is so many editors. I want one editor, and it should support every language I want to write in.

Re: .NET Hot Reload Support via CLI

#264

Post by tomnipotent »

saghm wrote: post #255
int_19h wrote: post #251

Earlier quoted context omitted.

VS Code has integrated builds, testing, and debugging. I would argue that, by any sensible definition of IDE, it's an IDE.

I think it's possible to customize it to be an IDE in some cases, but at least for some languages, it's not one out of the box. I have no idea how most people use it, but it doesn't seem obvious to me that all or most users would necessarily use it as and consider it an IDE.

> it's not one out of the box

Then by that definition there are no IDE's.

Re: .NET Hot Reload Support via CLI

#265

Post by katbyte »

tekknik wrote: post #263
moonchrome wrote: post #222

Earlier quoted context omitted.

This - if you're a professional software developer you'll find value in the 200€/year package for their tools. They are just good all around. My only gripe is not supporting remote development but it's in the works.

My problem with them is so many editors. I want one editor, and it should support every language I want to write in.

They all kinda support editing all languages - syntax highlighting ect. but the ui/menus/tools/refactoring/etc are all tailored in each app the the desired language

Re: .NET Hot Reload Support via CLI

#266

Post by pritambaral »

Too wrote: post #261
pritambaral wrote: post #214

Earlier quoted context omitted.

> Do you have any suggestion for alternative systems, which uses this supposedly "real" git flow, paired with reviews? GitLab (I know it works, because I set up this workflow in my company). Before GitLab: Phabricator, Gerrit. > All the git operations you listed work perfectly fine locally on a repo from github ... Irrelevant. GitHub needs to be compatible with Git, not the other way around. This subthread began with…

The equivalent for fixing typos in a chain of commits in github is configure squash on merge, commit --fixup/--amend and finally push --force. Force pushing might ring some alarms and sound counter-intuitive, but as long as it's on an open PR that's not yet merged it's perfectly fine. In a way one could argue this is more git-native compared to Gerrits refs/for which does some server side processing of the Change-Id…

> configure squash on merge

This makes it one commit per PR. Undesirable.

> commit --fixup/--amend

I'm aware of these (and magit makes it seamless). The problem is with the force push that these necessitate.

> Force pushing ... it's perfectly fine

Not when it breaks the reviewers' process.

> In a way one could argue this is more git-native compared to Gerrits refs/for which does some server side processing of the Change-Id and whatnot to map it into one change.

It is that server-side mapping that allows comments and discussions on changes to carry over from one version to another. Unlike on GitHub, where I've had to re-raise the same comment after a force push. It sometimes feels like GitHub's treatment of force pushes make it a dark UX pattern to slip bugs by reviewers.

This problem is big enough that I sometimes simply can't review a branch on GH. Unlike on GitLab, where I can be sure my comments, even when outdated, won't simply vanish.

> Biggest problem here is Githubs UI for indicating force-pushes is an abysmal line in the comment-list, instead of a showing all major updates to the branch in one place and mapping the comments to each of them.

For a platform whose main selling point was "Look, pointy-clicky web interface!", this is a major problem. The PR discussions interface sometimes feels like it hates the humans interacting with it. You better not ever let it get too long!

Force pushes aren't the only thing it makes you hunt down, BTW. Got an old comment somewhere? Perhaps one that has been "outdated" by a force push (aside: this is server-side processing, BTW, and worse than Gerrit)? Well, good luck finding that in a sea of hidden comments.

> Just don't see either as any big barrier or deviation from git workflow,

'Git workflow' is not the same as 'GitHub workflow'. GitHub doesn't currently mind you using them for the former, but they'd much rather you do things the latter way.

Re: .NET Hot Reload Support via CLI

#267

Post by babypuncher »

gbraad wrote: post #103
babypuncher wrote: post #102

Earlier quoted context omitted.

This is what keeps me on Visual Studio. It's free for personal and open-source use, so I use it at home. Since I know it and am familiar with it, I make my employer pay for a commercial license at work. In the grand scheme of things, it is not that expensive in a commercial setting. VS Code is great, but I do not think it is a comprehensive replacement for Visual Studio proper when doing full stack .NET development.

You can use OmniSharp. It is not ideal, but makes life easier. Though it seems MS actively disallows employees to come n tribute to them. If you do GUI work, you pretty much have to use VS. :-/

Microsoft's official C#/.NET extensions for VS Code use OmniSharp to provide IntelliSense, so I think they are becoming a lot more friendly on that front.

As others have already pointed out, OmniSharp is "good enough", but what's built into Visual Studio is still a lot better.

Post reply on HN