Home Dashboard Directory Help
Search

No pause after C# program execution if there is a mismatched quote in command line arguments by Medinoc


Status: 

Closed
 as Won't Fix Help for as Won't Fix


0
1
Sign in
to vote
Type: Bug
ID: 665753
Opened: 4/29/2011 6:39:39 AM
Access Restriction: Public
1
Workaround(s)
view
0
User(s) can reproduce this bug

Description

Usually, when a C# program is executed with the "start without debugging" command, Visual Studio forces a pause after program execution, before the console can close itself.

When the command-line arguments in the Debug tab include a mismatched quote, the pause doesn't happen and the console closes immediately.
Details
Sign in to post a comment.
Posted by Medinoc on 5/14/2011 at 11:25 AM
No problem. It's quite a minor bug anyway.
Posted by Microsoft on 5/14/2011 at 10:28 AM
Apologies about resolving this as duplicate when your issue was with managed projects. Upon further review in light of this fact, we have determined that we will not be able to fix this for the next VS release as we have other more severe bugs to fix and other feature work to complete. Thank you for reporting this issue though. If we receive a significant amount of customer feedback on this, then surely we will reevaluate our decision.
Posted by Medinoc on 5/13/2011 at 12:25 AM
How does one challenge a "resolved as duplicate" decision?
Posted by Medinoc on 5/13/2011 at 12:24 AM
Gah! This is not a duplicate of 540969!

540969 is about C++, and the workaround talks of .vxcproj files!
This bug is about C#, and the "workaround" from 540969 doesn't work on them!
Posted by Medinoc on 5/5/2011 at 8:32 AM
This is not a C++, project, it's a C# project, and its type is already "Console Application".
Posted by Microsoft on 5/4/2011 at 5:06 PM
The workaround for this issue is to add a <SubSystem> tag to your project file in the <Link> section with the correct sub system. An example of this is:
<Link>
<SubSystem>Console</Subsystem>
</Link>
Posted by Microsoft on 5/4/2011 at 5:03 PM
Workaround from dupe bug 540969.

Posted by Micro Hard on 1/20/2011 at 8:52 PM
Linked to this from Google and I think I have the answer and an easier workaround.

This is not for the original poster, but for future Googlers like me. With the new visual studio 2010 you might see this behavior even when you use ctrl f5 aka "start without debugging". This is most likely because you created an "empty project" instead of a "Win32 console application". If you create the project as a "Win32 console application" you can disregard this as it does not apply.

In the older versions it would default to the console subsystem even if you selected "empty project", but not in 2010, so you have to set it manually. To do this select the project in the solution explorer on the right or left (probably is already selected so you don't have to worry about this). Then select "project" from the menu bar drop down menus, then select "*project_name* properties" > "configuration properties" > "linker" > "system" and set the first property, the drop down "subsystem" property to "console (/SUBSYSTEM:CONSOLE)". The console window should now stay open after execution as usual.

Posted by Microsoft on 7/12/2010 at 6:24 PM
Thank you for your feedback. Please note the workaround mentioned above. We will be unable to fix this issue in the next VS release given our other work items. However, if the status of this bug changes, I will update this bug to reflect the change in decision.
Posted by Microsoft on 5/2/2011 at 10:33 PM
Thank you for submitting feedback on Visual Studio 2010 and .NET Framework. Your issue has been routed to the appropriate VS development team for review. We will contact you if we require any additional information.
Posted by Microsoft on 4/29/2011 at 7:13 AM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)
Sign in to post a workaround.
Posted by Medinoc on 5/13/2011 at 5:58 AM
Not much, apart from "don't put mismatched quotes in the command-line arguments field". Mismatched quotes on the command line are usually an error anyway.