Incorrect formatting of C# comments

[vsfeedback]

When you want to disable (but not delete) a field etc in a C# class, you comment it out by writing "//" at the start of the line, but this causes VS 15.8.0 to incorrectly format the line when the previous line ends with a comment. You can understand this much easier when you look at my screenshot attached.

To reproduce this bug, first put this class in a .cs file:

class ExampleClass1
{
    int ExampleField1;
    int ExampleField2;  // Some comment here.
    //int ExampleField3;
    int ExampleField4;
}

Then select the text (select the entire class). Then click menubar -> Edit -> Advanced -> Format Selection. VS changes the class to:

class ExampleClass1
{
    int ExampleField1;
    int ExampleField2;  // Some comment here.
                        //int ExampleField3;
    int ExampleField4;
}

The bug also occurs when VS formats the class at other times, not only the "Format Selection" command. See the "Automatically format when/on XXXXX" options in menubar -> Tools -> Options -> Text Editor -> C# -> Code Style -> Formatting -> General.

Thanks for investigating this!

This issue has been moved from https://developercommunity.visualstudio.com/content/problem/317225/incorrect-formatting-of-c-comments.html VSTS ticketId: 668245 These are the original issue comments:

Etienne Poirier on 8/21/2018, 04:35 PM (2 days ago):

Same issue as

https://developercommunity.visualstudio.com/content/problem/20554/line-comments-unwantedly-align-to-comment-above-in.html

Thank you to check this.

These are the original issue solutions: (no solutions)

[CyrusNajmabadi]

This seems by design to me... it's a common pattern to have multi-line comments at the end of constructs, and to align them across multiple lines.

In this case, we don't really have any way to know or believe that this isn't one of those cases, and aligning the comments as shown seems reasonable in terms of respecting the common pattern that is out there.

[jinujoseph]

Also referred here (edit: this was moved to #29647)

[verelpode]

This seems by design to me...

I can't really agree with you because VS 15.8.2 also does it when the first comment is single-line // and the second comment is multi-line /* */ The following shows the result after executing the "Format Document" command:

int ExampleField2;  // Some comment here.
                    /*
                    int ExampleField3;
                    int ExampleField4;
                    int ExampleField5;
                    */

I don't believe that anyone wants the above formatting.

it's a common pattern to have multi-line comments at the end of constructs, and to align them across multiple lines.

I never do that, and apparently multiple other people also never do that, therefore I suggest making a checkbox in the Options window, so that people can simply switch this behavior on or off as desired. However, in my opinion, the mixed example above seems to be a bug not a feature.

[dibarbet]

@sharwell do you recall if there was an outcome for this in design review, or does it still need to be discussed?

[sharwell]

@dibarbet This one is still in the queue

[dibarbet]

Thanks for confirming, wanted to make sure. I'll park these 2 until the next meeting then.

[sharwell]

I'm bringing this to a design review today. My proposal is as follows:

• The current behavior is generally by design

• We could modify the current behavior in the case where a line comment starting with a space is followed by a line comment not starting with a space:

  int x; // This comment starts with a space
         //This comment did not start with a space

  For this case, the first line comment not starting with a space would be aligned with int instead of the current behavior of aligning it with //.

[CyrusNajmabadi]

Note that some linters will complain if you don't start your comment without a space.

[sharwell]

@CyrusNajmabadi Other linters will complain about comments at the end of a line of code. Most relevant to this issue though is the fact that most cases where I've seen this reported as a bug, including the original example above, do not have a space on the line of code that the user did not want to see indented.

[verelpode]

most cases where I've seen this reported as a bug, including the original example above, do not have a space on the line of code that the user did not want to see indented.

That's an interesting pattern observation, but I think you'd like to see this issue fixed and terminated forever, but I fear that if the solution relies upon whether or not that particular space character exists, then it will be precarious and this issue will in future again be reported as a bug, instead of being laid to rest permanently. Did you dislike the idea of solving it via a tickable option in the Options window?

Another case to remember is mixed comment types, such as the following example. The solution for mixed comments appears to be simple and unambiguous and does not require an option in the Options window. If the second comment is a different type than the first comment, then the second comment should never be indented to match the first comment, thus VS should never produce the following:

int ExampleField2;  // Some comment here.
                    /*
                    int ExampleField3;
                    int ExampleField4;
                    int ExampleField5;
                    */

[verelpode]

If the idea of putting it in the Options window is rejected, then I'm trying to brainstorm an alternative solution, and I thought about maybe making VS look for a tab character in the place marked with "\t" following:

int x;\t// This comment is preceded by one or more tab characters.
// This comment would never be aligned with the previous comment.

int x; // This comment is preceded by one or more space characters.
       // This comment would be aligned with the previous comment.

On my computer, I have Options -> Text Editor -> C# -> Tabs set to "Keep tabs". I can't stand the "Insert spaces" option. I always use tab in-between ";" and "// comment". Despite the fact that I have VS set to "Keep tabs", when I copy & paste a line or otherwise trigger VS to format the line, VS changes my tabs to spaces. I wish it wouldn't do that.

I write it with tabs like this:

int x;\t\t// Comment. 

...and VS 2019 changes my tabs to spaces against my wishes:

int x;     // Comment. 

[CyrusNajmabadi]

I thnk i'd much rather have the rule that the //s are aligned if they abut. BUt not if there's a blank line between them. So, if you have:

int foo; //a comment
         //this follow the above

and

int foo; //a comment

//this does not

Needing to understand that having a space (or not) would affect alignment of comments seems super strange to me. Whereas, if there's this obvious gap between them, it would make it much more clear if they were intended to not be together.

[CyrusNajmabadi]

Another case to remember is mixed comment types,

Yes, i think i would agree that mixed comment types should not align here.

[verelpode]

Wait, here is another alternative solution, better than my previous brainstorming. VS would only increase the indenting of a comment if it is already indented by at least one space or tab char. Example:

int x;  // First comment.
    // VS would align this comment with the first comment because it is already indented.

int y; // Blah blah.
// This comment would never be aligned with the previous comment.

Thus the final result is:

int x;  // First comment.
        // VS would align this comment with the first comment because it is already indented.

int y; // Blah blah.
// This comment would never be aligned with the previous comment.

In other words, if a comment is aligned with "int x;" then it remains at that level, but if it already indented beyond "int x;" by one or more space or tabs, then VS aligns it with the previous comment.

[verelpode]

Needing to understand that having a space (or not) would affect alignment of comments seems super strange to me. Whereas, if there's this obvious gap between them, it would make it much more clear if they were intended to not be together.

I agree, but that's identical to the current behavior of VS 2019, therefore it would continue to trigger bug reports. So how about making VS only increase the indenting of a comment when it is already indented further right than int x; ? If a comment is currently exactly aligned with int x;, then why should VS think that a preexisting exact alignment is incorrect?

[verelpode]

Note that if the formatting of comments is influenced by the preexisting formatting/spacing (in the manner as I described above), then this behavior is not at all unusual nor inconsistent with other VS formatting behavior, because VS formatting is already influenced by the preexisting spacing. For example, when I run the "Format Selection" command on the following code in VS 2019 on my own computer, VS doesn't change the code at all. VS respects the fact that I wrote TestProperty2 on a single line and it leaves it on a single line.

int TestProperty1
{
    get
    {
        return 123;
    }
}

int TestProperty2 { get { return 456654; } }

In the same way as VS retains my preexisting formatting of a property, it can retain my preexisting formatting of a comment.

int x; // Blah blah.
// This comment is already exactly aligned with "int x;" 
// thus there is NO reason to think it's wrongly aligned.

int y;   // another comment
   // this comment does look wrong and should be reformatted.

[CyrusNajmabadi]

@verelpode in general we haven't had that concept in the formatting engine yet. But i'm personally amenable to it. I think it's a reasonable approach that would give the user some level of control here in a manner that would be reasonably intuitive.

[sharwell]

Design review summary:

The current general recommended approach is to add a blank line before the comment which should not have the extra indentation. However, to address the specific issue here, we would take a pull request which added a conditional formatting rule where comments already aligned where code would be indented on the same line will anchor at that location instead of the current behavior of anchoring to the trailing comment on the preceding line.

[verelpode]

Great, I think this solution will successfully prevent this issue being reported in future again as a bug. To my surprise, it was even possible to satisfy all users automatically without the burden of creating yet another option in the Options window.

[HappyNomad]

This horribly annoying behavior in Visual Studio bothered me multiple times today. It's so unbelievably annoying! I'll upgrade to VS 2019 just for this improvement once it's available. I'm anxiously awaiting.

[jcouv]

I've encountered this problem in Roslyn as well. The current behavior is annoying. See CS1720WRN_DotOnDefault02 for an example.

Original code (with formatting warning):

1>C:\repos\roslyn\src\Compilers\CSharp\Test\Semantic\Semantics\SemanticErrorTests.cs(21922,17,21922,17): warning IDE0055: Fix formatting

Code with formatting fix applied, but undesirable formatting:

This is using 16.2p3.

[jinujoseph]

also reported DC

[HappyNomad]

@jinujoseph Why is it moved to the backlog? This keeps coming up and it is SO ANNOYING. How about just adding an option to turn this nonsense off?

[CyrusNajmabadi]

@ChainReactive as mentioned in this post here: https://github.com/dotnet/roslyn/issues/29482#issuecomment-481007848

The current general recommended approach is to add a blank line before the comment which should not have the extra indentation. However, to address the specific issue here, we would take a pull request which added a conditional formatting rule where comments already aligned where code would be indented on the same line will anchor at that location instead of the current behavior of anchoring to the trailing comment on the preceding line.

In other words, if a community member wanted to contribute such a PR, roslyn would take it. however, absent that, the advice would be to just put in a blank line in the code.

If this is something you are passionate about (which seem evidenced by https://github.com/dotnet/roslyn/issues/29482#issuecomment-491030328 and https://github.com/dotnet/roslyn/issues/29482#issuecomment-548212118) perhaps you would be willing to help out here with a PR yourself?

Note that there are a couple of good channels to help out people working to contribute toward roslyn (internal and external alike):

gitter.im/dotnet/roslyn and aka.ms/csharp-discord

Cheers!

[HappyNomad]

@CyrusNajmabadi, @sharwell Visual Studio is a commercial product with a dedicated team on staff at Microsoft. I'm not already familiar with Roslyn, nor do I have time to dive down that rabbit hole. The people who's job it is to improve Visual Studio's user experience would be better equipped to fix this.

[CyrusNajmabadi]

@CyrusNajmabadi, @sharwell Visual Studio is a commercial product with a dedicated team on staff at Microsoft.

It's also an open source project with a community that actively contributes to it and provides PRs when their needs don't align with the priorities of the main team itself. I'm one of those people and have contributed as an external community member a large number of times.

As i've already pointed out, the stated view of the team is that there is an easy workaround if hte current behavior is undesirable to you. If that workaround is not tenable and you want to see this fixed, it will have to come from a PR from someone willing to view the change as valuable enough to invest their own time.

I personally don't feel like it's worth fixing myself, but i'd be happy to help you with a PR to change if it is something that is affecting you.

The people who's job it is to improve Visual Studio's user experience

As an open source project, "the people" includes the community (including you, me, and other interested parties).

would be better equipped to fix this.

Yes, that's likely true. But they're also tasked with work felt to be more important and a more valuable use of their time. And so here we are.

[HappyNomad]

@CyrusNajmabadi I'd welcome your assistance in making up for Microsoft's negligence. As I've already mentioned, I don't have time to get into Roslyn. How about I send you my kudos once you fix this bug? But if your Roslyn skills aren't up to stuff, then don't worry about it.

[CyrusNajmabadi]

@CyrusNajmabadi I'd welcome your assistance in making up for Microsoft's negligence.

Teams prioritizing things different from you is not negligence. There are millions of users and thousands of signals indicating what is valuable and important to actually address with the resources available. This minor issue simply isn't one of those. I can imagine you probably have to make similar decisions in your own work when deciding where to allocate your own resources.

How about I send you my kudos once you fix this bug?

I am personally not interesting in contributing a PR here. Primarily because i don't find the behavior particularly problematic, nor do i feel that the workaround is insufficient.

Still happy to help you out at any point if you change you mind. The links to the channels still apply. Cheers!

[CyrusNajmabadi]

But if your Roslyn skills aren't up to stuff, then don't worry about it.

When it comes to this area, they may not be. Hence why I was offering to work through it with you. Two minds being better than one and all that :)

Cheers and good luck! If you change your mind, just let me know! :)

[HappyNomad]

Teams prioritizing things different from you is not negligence

I disagree with you on this in the current context. The (ir)responsible team at Microsoft is neglecting a lot of users by not fixing this bug. Just google "visual studio c# turn off align comments" to see.

This minor issue simply isn't one of those.

It is a "minor issue" in that it'd be easy for them to fix, although the choose not to. It's not a "minor issue" in that it is indeed super annoying.

[CyrusNajmabadi]

is neglecting a lot of users by not fixing this bug.

And if they fix this and this do not fix another because they focused here, are they then neglecting the users affected by those other issues?

Framing the decision to prioritize bug fixing in a way you don't like as 'neglect' is not helpful. Any project will have bugs and every team will fix using a system that will not align with the desires of all members of their user base.

And, as mentioned above, if that order doesn't fit your desires, you actually have something you can do about it.

[HappyNomad]

And if they fix this and this do not fix another because they focused here, are they then neglecting the users affected by those other issues?

I'm sure they're working on new and great things, but some house keeping of low hanging but high value fruit like this issue would be nice. I'm sure there are other such issues that they quickly could pick off right in a row, and I wish they would.

Framing the decision to prioritize bug fixing in a way you don't like as 'neglect' is not helpful. Any project will have bugs and every team will fix using a system that will not align with the desires of all members of their user base.

You seem to be seeking some sort of recognition and I must concede it to you. You have a knack for justifying inaction.

And, as mentioned above, if that order doesn't fit your desires, you actually have something you can do about it.

As I mentioned above, I don't have time. Nor really for this pointless discussion, although I hope you got something out of it at least.

[CyrusNajmabadi]

I'm sure they're working on new and great things, but some house keeping of low hanging but high value fruit like this issue would be nice.

Many issues like that are fixed in any given release. You can just look at the issues closed with merged PRs over a certain time period. That doesn't mean all the things you care about will be addressed though.

You have a knack for justifying inaction.

I've already offered my time toward helping you fix this in a paired manner. If you view my willingness to work with you to fix hte issues you care about as "inaction" then that's on you.

As I mentioned above, I don't have time.

If that changes in the future, let me know. Still happy to help you out here to reach a resolution you would like! :)

[verelpode]

@ChainReactive wrote:

Visual Studio is a commercial product with a dedicated team on staff at Microsoft. I'm not already familiar with Roslyn, nor do I have time to dive down that rabbit hole. The people who's job it is to improve Visual Studio's user experience would be better equipped to fix this.

I agree! It's surprising to see that you (or I) were forced to say that explicitly, despite how obvious and self-explanatory it is. It shouldn't be necessary for you or I to say that, but it was necessary, therefore it raises the question: What on earth is going on here? Something is wrong here.

Being an app developer (or likewise) is already a challenging, time-consuming, and exhausting job. Thus it would be very unreasonable to expect app developers to do even more work in the form of unpaid casual side-jobs for various other projects such as Visual Studio etc, while simultaneously trying to perform their normal job. Such a workload would learn to burn-out (a very significant mental health issue with serious effects).

It would be wildly unreasonable to expect app developers to sacrifice all of the following.

• Sacrifice mental health (re burn-out) as a consequence of excessive workload / unpaid side-jobs.
• Sacrifice the proper raising of own children (applicable to everyone that has children), because of excessive time and energy spent doing unpaid side-jobs, resulting in insufficient time/energy remaining to properly raise and take care of children.
• Sacrifice the relationship with partner/girlfriend/boyfriend/wife/husband.
• Sacrifice a healthy amount of social life with friends and relatives (this loss can also lead to degradation of mental health).
• Sacrifice relaxation/leisure time (insufficient leisure time also damages mental health).
• Sacrifice fair working conditions and remuneration for staff members of businesses.
• Sacrifice ethical behavior.

@CyrusNajmabadi wrote:

... I'm one of those people and have contributed as an external community member a large number of times. ...

Wow. If you wish to sacrifice yourself, then you have the right to do that -- that's your decision for your life. However, it would be wildly unreasonable to expect @ChainReactive to sacrifice himself like you do. My personal opinion is that your behavior appears to be unethical, inappropriate, and unprofessional, and it does not belong in any GitHub repository linked with Microsoft.

[CyrusNajmabadi]

My personal opinion is that your behavior appears to be unethical

It's unethical to provide support to people to show how they can contribute to the Roslyn open source project?

Being an app developer (or likewise) is already a challenging, time-consuming, and exhausting job. Thus it would be very unreasonable to expect app developers to do even more work in the form of unpaid casual side-jobs

This is how much of the open source world works. Projects are made freely available for people to use and modify and contribute back to. When the priorities of the team don't align with your particular desires, you can choose to petition that they change, and/or you can choose to contribute your own efforts to align the project with your own desires.

However, it would be wildly unreasonable to expect @ChainReactive to sacrifice himself like you do.

I have never expected @ChainReactive to do anything. I have simply pointed out that this is something he can choose to contribute to if he wishes. And, if he does wish to do so, i am 100% willing to provide my own time and experience toward aiding that effort. There are many other community members who are willing to do that as well, and this has led to hundreds of community PRs and thousands of commits to the Roslyn repo that have improved the project for everyone. This is the power and value of it being an open source project.

Cheers! :)

[CyrusNajmabadi]

Sacrifice ethical behavior.

Working with a community to improve an open source project sacrifices no ethical behavior as far as i can tell.

[verelpode]

@CyrusNajmabadi

It's unethical to provide support to people to show how they can contribute to the Roslyn open source project?

You've been doing more than that. You're free to follow your choice of religion/philosophy, and various people such as @ChainReactive, myself, and others are free to follow our own choices of religion/philosophy. It's unethical and inappropriate if you frequently try to push or manipulate forum participants into joining your religion/philosophy.

If I followed your recommendation and adopted your religion/philosophy, then it would substantially damage the upbringing of my children. That would be even worse than unethical -- it would be monstrous to harm my children in that way.

[CyrusNajmabadi]

It's unethical and inappropriate if you frequently try to push or manipulate forum participants into joining your religion/philosophy.

Continuing to offering help is not pushing religion. Nor is it unethical to provide free support to people who can choose to take it or not.

If I followed your recommendation and adopted your religion/philosophy, then it would substantially damage the upbringing of my children.

Then don't. Nothing about what i've said insists that you do this. It merely offers you the choice of doing this. It's not unethical to make ones time available to help people freely if they are interested. I do this in many avenues in life. I freely offer tutoring for many different subjects. I freely offer assistance with learning different programming languages. I freely offer time and information toward contributing to some FOSS projects.

it would be monstrous to harm my children in that way.

So you're saying i'm operating unethically for offering my time and knowledge to people who may want it because if you were to take me up on it it would hurt you? Does that not strike you as ridiculous?

Should i also not offer free tutoring for interested students because if some were to take it they might be negatively impacted in other avenues of life?

Does it not make more sense (and seem more ethical) to have this be available and to leave it entirely to you (and others) to decide if you want to take it or not? I don't see how this is at all a religion, but i certainly can see how it's a philosophy. And it's a philosophy that has worked well for dozens of people out there. I think it's a good thing that I can help out, and I'll continue to do so and will continue to announce this possibility so that if there are people out there (even if its not you) will know and can take advantage of it if they wish.

Cheers!

[CyrusNajmabadi]

@verelpode @ChainReactive I'm not sure what else can be stated at this point. The team has put forth their position on this issue and how it is currently prioritized (i.e. in the help-wanted bucket). I'm available to help out if you, or anyone else, is interested in tackling this from the community.

As a FOSS project, Roslyn thrives on shared efforts by dedicated teams at MS, outside of MS and from community efforts. It's part and parcel of that that not all work is done internally. There is effectively interest from many thousands of individuals and groups about what is important, and the way Roslyn effectively manages that is to make it so that the core team itself is not the limiting factor for improvements happening. This is a virtue of the project, and one of the very specific reasons it is open source.

At this point, i don't think I can add any more help here. My offers of assistance seem to not be welcome, and the discussion seems to not be providing any actual value toward solving the originally reported issue.

If anyone is interested in solving this issue in the future, see the links provided above for a large group of community members (internal and external) and resources that can help out here.

Thanks all!

[HappyNomad]

@CyrusNajmabadi

You have a knack for justifying inaction.

I've already offered my time toward helping you fix this in a paired manner. If you view my willingness to work with you to fix hte issues you care about as "inaction" then that's on you.

I was talking about the Microsoft team's inaction on this bug, not yours. You seem strangely passionate about defending their inaction.

To be clear, I think that contributing to open source is a wonderful and worthy endeavor. We need more of that sort of collaboration in society. But as @verelpode pointed out, we all have a finite amount of time and other priorities in life. When it comes to side projects, we have to be selective about what we say yes to. We might have time to contribute to some but not others. I think it's unreasonable to say that, because I'm a Visual Studio user and want a bug fixed, I must go down the rabbit hole of learning Roslyn.

While I appreciate your offer of assistance, I fail to grasp the practical value of it. We're all programmers here. If I'd go to the trouble of learning Roslyn then , for such a small improvement, I may as well figure it out myself. If you sincerely want to help, rather than just pay lip service to the concept of helping, then please just fix this bug.

[verelpode]

@CyrusNajmabadi Everyone already knows that if a Mormon, Christian, or Buddhist etc came to this .NET forum and frequently promoted and proselytized his/her religion/philosophy, then it would be a case of inappropriate behavior, regardless of whether he/she does it directly, indirectly, or somewhat subtly.

Some people think that if no god is involved, then it's not proselytism. Nonsense! In reality, just because your religion/philosophy doesn't involve a god, this doesn't suddenly cause a special exception that makes it appropriate for you to engage in proselytism. For example, Buddhism doesn't involve a god. Another example: Many cults didn't or don't involve any god, but it's still bad behavior when the cult members engage in proselytism. Whether or not a god is involved is irrelevant: Either way, god or no gods, proselytism is unethical, inappropriate, and unprofessional behavior.

It's unethical to provide support to people to show how they can contribute to the Roslyn open source project?

That's the same behavior as when a fervent missionary "innocently" replies, "There is nothing wrong with providing support to people in need, to show them that Jesus loves them and will save them. I'm helping people. People should contribute to our church fund so that we can rescue even more people. I was just simply showing people how they can contribute to our projects."

[jaredpar]

@verelpode please keep your comments on topic here.

[jaredpar]

As @sharwell and @CyrusNajmabadi have already elaborated on, the Roslyn team considered this bug, discussed the impact and potential solution in design meetings, and while they did arrive at a path forward decided pursuing it simply fell below their priority bar.

The IDE team, as well as pretty much every other team, has a full load of work on their plate. Fixing this bug means there is another bug, which they value higher, that they cannot fix. In this case they've chosen to prioritize other work on their plate. At the same time they're willing to assist anyone else who wants to pursue the fix.

@ChainReactive @verelpode I understand the frustration here at a bug that you prioritize not being fixed. At the same time though the IDE team has not been dismissive of your concerns. Rather they've given it careful thought and devoted design time to coming up with a potential solution.

[jaredpar]

Temporarily locking thread to give it time to cool down.

[YxT3]

▪ Two years on, or three actually, and no matter how many eufemisms, mental turnings and twisted answers invented, my impression remains that CyrusNajmabadi's and Sharwell's early responses to this question ( not to mention M$'s misbegotten core position in this issue ) have been disappointing, seemed more like a denial of the problem, maybe blinded by half cooked work-arounds, it even seemed as made/written by non-programmers.

▪ Essentially this issue came into existence with VS.2017 (v15). Up to and including VS.2015 (v14) we had no such problem. Makes you wonder what could have been the problem for M$, preventing them from taking a [configurable] step back in this ?

▪ An expensive solution can be found in JetBrains ReSharper. On Visual Studio 2022 (v17) I stumbled into this darn "End-of-Line Comment vs Next Line Comment Reformatter Alignment" problem, to ultimately find a true solution in ReSharper 2021. Is this a M$ attempt to indirectly promote a JetBrains product ?

▪ This Comment Reformatting issue also flashes me back to the intelliSense Popup Height statically having been reduced in Visual Studio 2010 (v11) – a problem also resolved by ReSharper, a decade ago.

▪ Looking even wider, these situations may have similarities to Embarcadero's RAD-Studio and FreePascal's Lazarus being unable to implement Undo/Redo in their Visual Design environments.

[CyrusNajmabadi]

@YxT3 I'm not sure what you are looking for here.

We've looked into the issue and prioritized it accordingly. I've mentioned my willingness to personally spend my own off-work time to work with interested community partners to make changes here.

I get that you would like us to prioritize this higher. However, understand that that's how everyone feels about their particular issues they care about. We invariably have to make calls as to what to work on, and that means some people will not get the changes they want.

The benefit of being open source here is that customers who do really want changes that don't meet our priority bar can then contribute those changes themselves. We have dozens of developers who have done this, and we often put on special effort (including our own spare family time) to make this happen.

Let me know if you're interested in working with us on this. It is near the holidays, but I will take time out from my off time to help out.

Thanks!

[verelpode]

The benefit of being open source here is that customers who do really want changes that don't meet our priority bar can then contribute those changes themselves. We have dozens of developers who have done this, and we often put on special effort (including our own spare family time) to make this happen.

It's really inappropriate to suggest that "little guys" (individual developers) should work FOR FREE to help increase the profit of an ultra-wealthy corporation in the stockmarket. A mega-corporation that has access to billions of dollars, yet individuals should donate their time and energy to make the mega-corporation even MORE wealthy??? What on Earth is going on here?? It's unethical and highly inappropriate to suggest personal self-sacrifice for huge wealthy corporations.

Many of us have families, which means it's even worse than personal sacrifice. It's also sacrificing the welfare of our families/children.

[CyrusNajmabadi]

@verelpode This is an open source project. And, like most projects, it must pick and choose what can make any release. Not every issue will make it, and cuts and prioritization will mean that things at lower priority may take a long time until eventually getting resolved.

However, as i mentioned above, the value of open source is that if community members do feel interested in contributing, and they have the time and preference to do so, then that is a possibility available. Unlike a closed-source project (where a low priority issue might never be resolved), in an open source project there are other paths available.

This does not mean that someone should do this if they don't have the inclination or time available. I never said that. I only said that if someone was interested and could spare time for this that we would absolutely help make this happen. I'm personally spending time with my family right now. However, i would absolutely be willing to still make the time happen to work with you (or anyone else interested) in coming up with a plan and a PR to address this issue (and others that we haven't been able to fit into our schedule).

This is neither unethical or inappropriate. It's precisely the nature of software projects, especially those that are open source.

[verelpode]

@CyrusNajmabadi - Are you a real person or do you represent a marketing team that has the goal of promoting unpaid work for wealthy mega-corporations? Unpaid work is actually illegal in many countries.

[CyrusNajmabadi]

@verelpode I'm a developer on this team. I'm explaining the situation as it stands. Right now this issue is on our backlog. Meaning there are many other issues we consider more important that we will be prioritizing ahead of this for our upcoming releases.

People have shared their thoughts that htey are bummed that this isn't getting attention. I'm providing information on what are viable avenues available to see progress on this in the meantime if people want this to be fixed in a shorter timeframe.

Working on open source projects is neither illegal or unethical. The Dotnet org works with hundreds of people globally in these projects. I myself have contributed many times voluntarily. Precisely to see things changed that i personally cared about, but which the team could not find time for.

I get that you want this issue to be fixed. However, as you can see, this repo alone has over five thousand active issues that require our attention. No matter what, we must pick and choose what we think is important and what order to process that in.

If you are interested, i'm happy to work with you to come to a resolution on this issue. If you cannot make the time, i completely understand and would not ask you to give up something you consider important yourself to do this. However, there may be others in teh community who are very interested and who are willing to work on this sort of stuff. As before, we're always welcoming of this. And i know several on the team (myself included) who will do what it takes to make that succeed.