i have a remote web site project in my sln that contains a wcf service and the server does not allow me to debug him...
when i run my client i get an error on the start that the server cannot be debugged..
how can i tell the vs to stop trying to debug the remote server?
If you have both a client and a server project in the same solution, then VS2008 is capable of debugging either one or both at the same time. There are two independent settings that control this.
Right-click on the solution and select "Set Startup Projects". This allows you to select any number of projects to start in the debugger when you press F5. Any project not in the startup list may very well be run anyway if it's a server, but will not be run in the VS2008 debugger - an important distinction.
Every ASMX and WCF service project has a property in its property window called "Always Start When Debugging" that controls whether VS2008 will auto-start it in the debugger when the client project is run.
I therefore suggest that you:
make sure that the server project is not set as one of the solution startup projects, and
make sure that the server project is not set to always start when debugging.
Related
In some of the solutions we have ASP.NET/WCF web project and a test project. Some of the tests run against ASP.NET development web server using http://localhost:port/.... In VS2010 while the ASP.NET/WCF web project was being debugged, the test runner could run the tests and if there were any breakpoints in web project, the debugger would break the execution. This seems to have been disabled/removed in VS2012.
When the ASP.NET/WCF web project is debugged (launched by pressing F5 or via attach process), both the TEST->Run and TEST->Debug sub-menus are disabled. In VS2010 only Test->Debug sub-menus were disabled while Test->Run sub-menus were still enabled. We use this way to easily debug the services within the web project. Any way to get that behavior back or workaround?
Debugging While Running on ASP.NET Development Server doesn't seem to be applicable to VS2012 or at least I can't get it to work.
In VS2013 the situation is the same: the options for running / debugging tests are greyed out while the project is being run/debugged. This is a shame especially for projects like web API's where tests for calling the API via HTTP (as opposed to creating an instance of the Controller class and circumventing any network traffic) are very useful as they are closer to what the end users of the API will experience.
As a workaround, you can either open the same solution in a separate instance of VS, or create a separate solution with the same projects, specifically for testing. Debug in the first VS instance, run tests in the second one.
If you have a solution with WCF applications and tests calling them, you can debug the applications using the tests by calling Debug All Tests or Debug Selected Tests without a previous Start Debugging (F5).
Configure your solution to Multiple Startup Projects with None set in all actions and configure your WCF applications to the start action Don’t open a page. Wait for request. With this configuration the development web server starts if you select Debug All Tests or Debug Selected Tests.
Here is a workaround to debug a single unit test along with a web server. It relies on Debugging Multiple Processes (excludes MSVS Express):
Start web server (non-debug), note its process id (IIsExpress icon -> Show All Applications)
Place a breakpoint at first line in test
Start Debuging the Unit Test, wait for it to stop at the breakpoint.
Debug -> Attach To Process, enter web server process id
Both the test and server are running live in the debugger.
I ended up writing a quick addon. It turns out that like VS2012, VS2012 test runner can also run the tests when the web project is being debugged. It is just that menu options are disabled.
Try this:
Place a breakpoint in the first line of your unit test method.
Start debugging your unit test.
Once it hits the first line in your unit test, start a new instance of the other projects you need running.
This is not a pretty solution, but it works. Using Azure DevOps TFS Version Control, create a branch of your current project. Open the solution for your project, in the other branch, in another instance of Visual Studio at the same time as your main project is running in the first/original instance of Visual Studio. Then, run your web project in your first/main Visual Studio instance. Now, run your unit tests from the other instance of Visual Studio. Voila.
To keep them in sync, you can do Merges from one branch to the other.
I still ran into this on VS 2022.
If you have multiple projects you can run. Try to set the startup projects and set at least two of them. (solution->right click)
If two instances are running in debug mode, VS also allows you to start unit tests.
(I just started two aspnet api-s from my project)
I am developing one product and there are 4 separate projects, in that I have developed one EXE project and WCF and I have done switching in debugging mode by attaching WCF project in process of debugging client of EXE and it has worked.
But when I transfer my WCF to servicestack then I could not able switch between them.
I am running my EXE project and and attached my WCF(servicestack) project to process
JsonServiceClient client = new JsonServiceClient("MYServiceURL");
RESTWCF.ServiceModel.Perfmon objBalPerformanceDataProperties = MakeObjectForServiceStackToInsertData();
var res = client.Post<RESTWCF.ServiceModel.Perfmon>("/perfmon", objBalPerformanceDataProperties);
When I click F11 on client.post I could not able to switch in WCF project, I think you can make sense of my problem.
Give me some solution of this problem so I can debug my code of WCF project (to find error :) in that)
Thanks.
You can only debug one host project at a time.
If you want to test the server set the ServiceStack project to be Start-up Host and press F5 to start debugging the ServiceStack host. Put a break-point at the start of the service you want to hit.
You can then just Run (i.e. without debugging) the client application which if everything is configured correctly, it should hit your breakpoint.
To make sure you're debugging the service correctly, instead of running the client first try calling the web service via a url, e.g:
http://localhost/MyServiceUrl/perfmon
If it hits the break-point you set, then all is well and you can run the client application as mentioned above.
Also it's a good idea to include ServiceStack's debbuging symbols, i.e. it's *.pdb files in the same folder as it's *.dll's - as it helps with debugging.
Note: WCF has nothing to do with ServiceStack - In a lot of cases that's considered an insult :-)
Suppose I have a class library cl1 and a unit test for it that is called clt1. I can use Visual Studio's Attach to Process feature to attach to NUnit runner. This lets me debug cl1, for example set break points. It's a very helpful feature for debugging.
I'm in a need of this technique in Visual Studio and IE/FF. Suppose I have a web application that utilizes cl1. This application is running via ASP.NET Web Development Server or IIS. I want to debug (set break points) in cl1. How can I do this?
Please notice that it's not possible through Visual Studio itself. Because something in markup is calling cl1 classes and I can't set a break point in ASP.NET markup. I'm running Visual Studio 2010 Ultimate.
UPDATE:
cl1 is running as server side
As your code is running server-side, you need to attach the debugger to the server (IIS, or dev server, whichever you are running).
What I normally do is set my breakpoint, browse to the site (in order to ensure that the site is running and has been "warmed up") then Debug -> Attach and find the process running the web server to attach to. I then browse to where my code will be run and go through the steps to execute it.
If IIS is running on a different server, you can do remote debugging.
I guess the class library you are referring to contains c#/vb.net code (server side) so as the code is executed by the server you will need to attach to the webserver itself. If the web site is hosted at another machine you can use VS remote debugger to attach to IIS.
Your library will be running inside the ASP.Net app pool. On IIS7 you should attach to w3wp.exe. Older versions of IIS may use aspnet_wp.exe instead.
I have a solution file containing multiple web applications and components. Mostly these web applications operate independently of one another, but I need to be able to response.redirect from one application to another. This works, and the new page runs, but I can't step into the code in the second web app and debug it.
I have both web applications set to "Always Start When Debugging" = True, with the first web app (the one that's redirecting) set as the startup web application. Does anyone know a trick that will let me step into the code in the second web application?
Open up a second instance of Visual Studio, then Ctrl+Alt+P (menu Tools > Attach to Process) then attach to the appropriate web server process (if you run under IIS this may be w3wp.exe or aspnet_wp IIRC, if you use the built in web server then attach to the process which lists the appropriate port for your project).
Optionally just run the second one and manually go to the first one in your browser by entering the appropriate address and trigger the redirect which you have verified is working.
Are both web applications running in the same process? What version of ASP.Net, IIS, and the .Net framework are you using? Those are my initial questions before I start giving other ideas.
So, I've read that it is not a good idea to install VS2008 on my test server machine as it changes the run time environment too much. I've never attempted remote debugging with Visual Studio before, so what is the "best" way to get line by line remote debugging of server side web app code. I'd like to be able to set a breakpoint, attach, and start stepping line by line to verify code flow and, you know, debug and stuff :).
I'm sure most of the answers will pertain to ASP.NET code, and I'm interested in that, but my current code base is actually Classic ASP and ISAPI Extensions, so I care about that a little more.
Also, my test server is running in VMWare, I've noticed in the latest VMWare install it mentioning something about debugging support, but I'm unfamiliar with what that means...anyone using it, what does it do for you?
First, this is MUCH easier if both the server and your workstation are on the same domain (the server needs access to connect to your machine). In your C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\Remote Debugger\x86 (or x64, or ia64) directory are the files you need to copy to your server. There are different versions between Visual Studio versions, so make sure they match on the client and server side. On the server, fire up msvsmon. It will say something like "Msvsmon started a new server named xxx#yyyy". This is the name you'll use in Visual Studio to connect to this server. You can go into Tools > Options to set the server name and to set the authentication mode (hopefully Windows Authentication) - BTW No Authentication doesn't work for managed code.
On the client side, open up Visual Studio and load the solution you're going to debug. Then go to Debug > Attach to Process. In the "Qualifier" field enter the name of the server as you saw it appear earlier. Click on the Select button and select the type of code you want to debug, then hit OK. Hopefully you'll see a list of the processes on the server that you can attach to (you should also see on the server that the debugging monitor just said you connected). Find the process to attach to (start up the app if necessary). If it's an ASP.NET website, you'd select w3wp.exe, then hit Attach. Set your breakpoints and hopefully you're now remotely debugging the code.
AFAIK - the VMWare option lets you start up code inside of a VM but debug it from your workstation.
Visual Studio comes with a remote debugger that you can run as an exe on your server. It works best if you can run it as the same domain user as your copy of visual studio. You can then do an attach to process from the debugger on your machine to the IIS process on the server and debug as if it was running on your machine. You get more options for .Net debugging, but there's support for older platforms too.