In VS2019, when I start my ASP.NET Core 5 app, which just exposes an API, if that matters, a console window pops up for that app. There used to be some setting to decide whether to run it as a console / standalone app or host it in IIS Express. I always preferred the console / standalone version because it lets me see the logs in realtime.
In VS2022, when I start the very same project, no window appears at all, and, interestingly, neither do I see IIS Express starting up.
How can I get back to having the project start as a console app? (Except starting it from the command-line and then attaching the debugger.)
UPDATE:
ok, so at long last I noticed that, strangely, a minimized console window is being created and because I start a dozen projects (microservices), I didn't notice before, and procexplorer telling me that the executable had no window added to the confusion. So this is much less problematic, albeit still weird - why does this one particular application not start un-minimized? The only difference it has to all the other executables is that it uses ASP.net core while the others (all background services communicating via messagequeue) don't.
and this only in VS2022, in VS2019 all executables including this one start unminimize
You have to make sure, that you selected "IIS Express" as your debug profile
VS 2022 debug profile
I believe you are looking for this. Follow the steps highlighted in in each image:
Go to your project properties:
Then you will see that the console is open in the task bar.
In Visual Studio 2022 this is currently NOT POSSIBLE
Related
After creating a new project using the "ASP.NET Core Web App" template, when I run the project, I want the console window to automatically be brought to the foreground. Since I'm mainly developing a web API, I don't want the browser to launch (which I've done in launchsettings.json), but do want the console window to show.
I've verified that this is the default behaviour when creating a .NET Core 6 Console app, yet I can't find the settings responsible for this desired behaviour.
It can be achieved easily just by changing a debug setting. It may be a little bit different in old versions of Visual Studio!
VS2022
1. Open Launch Profiles window:
2. Select relevant profile from opened window and change Launch browser setting(uncheck it)
3. Save the change if there is any Save button. and run the project.
I am running an asp.net docker container remotely. I have enabled SSH, mapped the port and also installed VSDBG in the container.
In visual studio I am able to attach to process over SSH. I choose my project dll file. There are no error alerts and it appears to be debugging but on every breakpoint there is this message:
The breakpoint will not currently be hit. The breakpoint is pending and will be resolved when debugging starts.
Also if I open modules window there is no entries.
What is going on? Why is remoe debugging not working?
There are usually two reasons:
1. project publication made with release instead of debug configuration
2. the projects are not consistent. There is a difference between the project on the local machine and the server.
Edit: After downgrading to .NET SDK 1.0.4, I can debug my app inside Rider and experience is pretty good.
What is the best way to set up a clean debug configuration for my ASP.NET Core app on Ubuntu in Rider 2017.1?
I want to just click on Debug button and have the tool automatically build the app, host it on some port, and open the url in browser.
Should I just try to use launchSettings.json(as VS automatically creates) or Rider offers something else?
I have .NET Command Line Tools 2.0.0-preview2-006497 installed.
You can't.
Until a new version of Rider with .Net Core support is released, debugging doesn't work.
In fact, you'll see the event log full of messages like this if you try:
12:01 PM .NET Core version problem: .NET Core 2.x is not fully supported. Some features will not work as expected.
(You can still just open a project and hit the play button and it'll run your project; but hitting the debug button doesn't actually work at the moment)
As of the time of writing, testing, nuget restore, project references (ie. between projects in the same solution) and running in debug don't work.
For now it's just a waiting game until the next version of rider comes out with these features in Fall, 2017:
We want to roll out at least two more releases this year: an inevitable bugfix release in a few weeks, and another major release (2017.2) in the Fall. Things that we expect to be addressing include support for MSTest and .NET Core 2.0, as well as releasing an SDK. We’ll certainly be keeping a close eye on your feedback (submitted via the support form, issue tracker or elsewhere) to see what other major issues need to be addressed.
Before beta8 it was possible to start a Web Application, change some of the code (e. g. the ViewBag.Message of the About-View), save and refresh the browser - voilá, the new Message is displayed without rebuilding the project.
Now when creating a new Web Application with beta8 which uses DNX and Kestrel this seems no longer to work. Any idea why?
Beta8 contains a new library called 'dnx watch' which monitors your project files for changes during execution and automatically rebuilds the project. Install it by running the following from a command prompt:
dnu commands install Microsoft.Dnx.Watcher
Additionally, make sure you've installed the beta8 web tools for Visual Studio.
Finally, make sure you're not running in debug mode as code changes will not reload projects while running with the debugger attached. CTRL+F5 will start your web project without the debugger.
You can read up on this and the other changes in beta8 here:
http://blogs.msdn.com/b/webdev/archive/2015/10/15/announcing-availability-of-asp-net-5-beta8.aspx
** post was edited, more info below
I've just watched two great videos about Advanced Dotnet Debugging (by Brian Rasmussen) and I am trying to repeat some steps, but just don't know how to proceed with tis error:
An attempt to set a processes DebugPort or ExceptionPort was made,
but a port already exists in the process.
I've found some answers on google and i generally understand what the error says but I just don't understand one weird fact: when i compile my simple app < .NET 4.0, I can attach as the movie shows, trying to do the same after i compile targetting .NET 4.0 disables me from attaching.
One of google's answers says "try to attach from windbg using noninvasive mode" but.. Brian do not use any of such checkboxes. It just works on his videos.
What's the difference? Where's the catch? Is it Windows 7 vs Vista? Maybe some different compile settings matters?
I am using MS VS 2k10 with MS SDK with Windbg x86 downloaded from msdn and symbols correctly configured to http server. The system is MS Vista x86.
Resources (exact time >= 8:15):
http://channel9.msdn.com/posts/MDCC-TechTalk-Advanced-NET-Debugging-part-2
Edit:
Error shows when attaching to process that was run from VS. Trying to attach to process that was run /outside VS, windbg doesn't show any content.
Edit2:
Windbg had some refreshing problems in my system. Using few times "Windows \ [Undock | Dock all]" menu option i was able to see the content of attached process, that was missing.
So the only question now is: what's the difference when attaching to process started from VS, when it's compiled in once using target < 4.0 and again = 4.0? Why when targetting 4.0 windbg cannot attach to the process in not "noninvasive" mode. What has changed in VS 2k10?
I take it you're debugging from Visual Studio (F5) and then trying to attach. You can only have one active debugger at a time, so that is why you get this error. If you want to launch the process from VS, run it without debugging (Ctrl-F5). If you do that, you should be able to attach from WinDbg.
EDIT : I am sorry, I missed the point about various versions of .NET behaving differently in this respect, so let me try to address your questions again. The reason it "just works" in the video, is because I use run without debugging every time I launch from VS. So if you simply want to follow the examples in the videos, all you need to do is run without debugging.
I started using WinDbg/SOS on CLR2 and x86. Launching a x86 .NET process from VS back then would trigger the error, so I made a habit of just launching without debugging.
However, as you have discovered there are scenarios where you can actually attach to a process that is being debugged by VS. I can reproduce the scenarios you describe, but I can also attach to a x64, .NET 2 process started with debugging from VS2008, but I cannot attach to the same process if the platform is set to x86.
Apparently there are subtle differences that I haven't been aware of, and it doesn't seem to be related exclusively to the .NET version, as I can attach to a x64 .NET2 process even if it is under the control of the VS debugger.
I'll update my answer if I find additional details.