Hello i have a problem of debugging in VS with iis that is :
so what i should do always is :
and here there is the pool of application in IIS :
How can i resolve this problem ?
Two options
In Visual Studio attach a debug built project via Debug -> Attach To Process and filter/select w3wp.exe. If you have multiple sites/services running its best to put different sites/services on different app pools. That way you can identify which one to attach to. Below my service I attach to is on App Pool 8.
F5 debug the site/service. You may need to change some web.config values like such as allowunlisted if dealing with restful web services. Also setting the debug in compilation is helpful <compilation targetFramework="4.5.2" debug="true"/> as an example.
Related
I know this has been asked before but I just cannot figure this out. I believe I have covered everything that has been brought up already but I'll cover those.
I am getting this message when I try to step into a service that is a project that is currently in my solution:
I have 3 projects in my solution:
SuburbanCustPortal <-- my website
SuburbanHub <-- my serice
WebsiteLogging <-- my logging project (no significance here)
I read that I should check the following items:
Make sure that debug is on. I have this in both of my project's web.config:
Make sure they are both using the same .net version. They are both on the .net framework 4.0.
Make sure Enable Just Your Code is unchecked:
The service is pointed to a local url:
I can pull up the service in my browser without error:
This is my settings for iis:
I have restarted visual studio, the computer and removed the service and added it back.
I cannot, for the life of me, figure this out. If I have missed anything I am willing to give it a shot.
It is very important that I get this resolved so I can get this project out this weekend so any help would be greatly appreciated.
IN RESPONSE TO Sanket Shah
I do not have the option w3wp.exe:
SOMETHING I FORGOT TO MENTION
I have set debug=true in both of my projects:
<compilation targetFramework="4.0" debug="true">
<assemblies>
<add assembly="System.Data.Entity, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
</assemblies>
</compilation>
Also, I wanted to add that I have been able to step into my service before but since coming back to the project recently, I am not able too. I have a break point on the line that calls the service and when I try to F11 in to it, I get the above message.
IN RESPONSE TO Pawel
I have tried setting symbols the follow ways and neither allowed me to step in:
I have even tried to use the Microsoft symbols:
IN RESPONSE TO Pawel #2
ADDITION INFO
I just noticed this, I'm not sure if it is related:
ADDITIONAL INFO ABOUT DEBUG MODE
I have all projects set in debug mode:
Your solution/project/settings file(s) might be / seems like it is corrupted. If you create a new solution from scratch, adding new projects which mimic your current structure, you can try and see if debugging works properly.
If that works, gradually move the code over while keeping checking that debug keeps working.
I don't know why this doesn't work.
I have a work-around for you, which you verified in the comments: add System.Diagnostics.Debugger.Break() somewhere in your service after it starts. This should pop up some sort of exception window, with a list of Visual Studio instances open. Pick the one with your solution and click OK, and it should attach correctly to that location.
Annoying? Yes. In my experience with Visual Studio, it can be very finicky sometimes about debugging into Windows services. This is the only reliable way to do it that I know about.
In addition to other answers, you can do two things:
Close your solution, delete [solution-name].suo file, reopen solution. See if your problem still persists.
Open a command prompt as admin, cd %windir%\Microsoft.net\Framework\v4.0.30319, execute this aspnet_regiis.exe -i.
In solution, have you tried to set all assemblies (client and server) to start in debug mode rather than trying to attach it after launch ? (right click on solution in the top of Solution explorer, startup, multiple startup project, choose "start" for every assembly which is an entry point : server, client, etc).
Have you tried to run only the "server" part in debug mode (the one which is not debuggable) and call it for example with soap ui ?
You should try to see if you can run it directly and debug it without the "step in" from another process, or if it also fails to load in debugger even if started directly.
FYI, if you use IIS Express it's normal you don't see "w3wp.exe", which is for IIS. You may have a iisexpress.exe process, or in some cases aspnet_wp.exe.
Don't forget to check "show processes for all users" in Debug->Attach to process window if you choose to hook on existing process rather than doing that I was saying first.
Go to Properties of the solution select Multi statup project and select all projects with start, then debug the solution.
Are there any differences between System.Web.HttpContext.Current.IsDebuggingEnabled and System.Diagnostics.Debugger.IsAttached?
If so, what are the exact differences besides the fact that one is only for web applications while the other works in all kind of projects?
HttpContext.IsDebuggingEnabled is about the compilation setting in the web.config. Debugger.IsAttached defines if there is actually an active debugger listening to the information coming from the web server.
See the explanation at DotnetPerls regarding HttpContext.IsDebuggingEnabled:
Debug mode is not the default. ... When you do not set debug="true" in Web.config, the site is compiled in Release mode.
Regarding your question why the first 'one is only for web applications': web applications have the ability to compile at run-time, while all other .NET products are pre-compiled. Because of this, you can define in the web.config if the build is done in Debug or Release mode. This is a ASP.NET only option, so the property is only available there.
As answer to your second question, why the first option is only for ASP.NET: There is also a way for a Windows application to check it's build status: by checking the DebuggableAttribute as explained in How to check if an assembly was built using Debug or Release configuration?.
IsDebuggingEnabled refers to "debug mode" which does not necessarily mean a debugger is actually attached. You can set ASP.NET websites into debug mode by setting <compilation debug="true"> in your web.config file.
When a website is in debug mode, JIT optimizations are not applied to code contained within your view files (.aspx, .cshtml, etc) as well as any runtime-compiled code-behind files or the App_Code directory. There are also other effects.
I have a self-hosted WCF service. I don't have an app.config file, instead all the configurations are performed at run time in the code. But I cannot figure out how to enable debugging in the code.
UPDATE
I have a VS solution with two projects:
WCF service hosted in a WinForms application
Simple console client consuming the service
I'd like to be able to start the debugging session in Visual Studio, debug the client, set and hit breakpoints in the service application. I was able to do this when I used app.config files, but now I'd like to do the same without them.
Attach the debugger to the process that your wcf service is running in.
If in IIS you will have to attach to the corresponding w3p.exe process.
If in a stand alone app or windows service, attach to the name of your exe.
In VS in debugger option there is sub option "attach to process". You will need to set brak point to the appropriate code and call the service causing that code path to execute.
Can refer this link:
http://msdn.microsoft.com/en-us/library/aa702726.aspx
as well as this one:
http://www.codeproject.com/Articles/17258/Debugging-WCF-Apps
This might be helpful to you.
if you need to launch debugger from the code, write the following line:
System.Diagnostics.Debugger.Launch();
I often use this tecknique in debugging purpose. But it is better to remove it in release version.
If you want to attach to the already running process, open Visual studio, go to menu Debug > Attach to process, find the hosting process and click "Attach" button.
I have an asp.net web app, and I have added some related class projects to my solution file. When I run the web app, I want to break and step through the code in the class (when a class is referenced).
I don't get an error messages. The code in the class project just does not kick in.
I have searched and read this post Debugging a Class Library but no luck.
How do I get that to work?
Can you try to stop the ASP.NET process? I usually have this problem when the asp.net service is still running, and I compile (by asp.net service I mean the icon that appears near computer clock). Try to close that, recompile, then run.
Are you sure you have <compilation debug="true"/> set in your web.config file? Are the classes in the same assembly as the rest of the application?
edit: The only other thing I can suggest is stop IIS and/or all instances of the vs development server, clean the project, rebuild, and give it another shot. Also be sure there is only one web.config and you aren't running in release against Web.Release.config or something.
This sometimes happens. Check Debug>Modules to see if there is your dll loaded. It seems that VS debugger doesn't have .pdb file available. Clear Temporary ASP.NET Files in your .NET folder, Clean/Rebuild and try debug again.
Also do not forget to run VS as Administrator. Try to Attach to process instead of F5.
You can call in your code this function, and the debugger will pop-up
System.Diagnostics.Debugger.Launch();
alternative you can call the Debug.Fail("Stop me to see what next");
I've got a Visual Studio 2008 solution with a WCF service, and a client.
When I run my client, and call a method from my service I get a message saying "Unable to automatically debug 'Home.Service'. The remote procedure could not be debugged. This usually indicates that debugging has not been enabled on the server."
I've googled around, and have tried the following.
<system.web>
<compilation debug="true" />
</system.web>
has been added in app.config on both the client and the server.
I have also made sure that the project is being compiled in Debug mode.
What else could be causing this message?
Edit: Added more info based on feedback questions
It is using wsHttpBinding
I have set
<serviceDebug includeExceptionDetailInFaults="true"/>
I am using
var service = new HomeReference.HomeServiceClient();
service.ClientCredentials.Windows.ClientCredential = CredentialCache.DefaultNetworkCredentials;
Unfortunately the error shows up the first time I call a method on my Service. I can dismiss the messagebox, and the application continues working. Any Exceptions thrown on the server at not propagated back to the client though (I assume it should?)
I was fighting with this exact same error for over an hour and low and behold I restarted VS2008 and it magically fixed itself. Give it a try as it might save you some time.
In my case the problem turned out to be a mismatch between security settings on client and server. I was using a custom binding like this:
<customBinding>
<binding name="AuthorisedBinaryHttpsBinding" receiveTimeout="00:03:00" sendTimeout="00:03:00">
<!-- this next element caused the problem: -->
<security authenticationMode="UserNameOverTransport">
</security>
<binaryMessageEncoding>
<readerQuotas maxDepth="100" maxStringContentLength="1000000"
maxArrayLength="655360000" />
</binaryMessageEncoding>
<httpsTransport />
</binding>
</customBinding>
When I removed the security element that I've highlighted above the problem with the "Unable to automatically debug" message went away.
To solve the problem I first turned on WCF tracing. This showed me that WCF was throwing a MessageSecurityException:
Security processor was unable to find
a security header in the message. This
might be because the message is an
unsecured fault or because there is a
binding mismatch between the
communicating parties. This can
occur if the service is configured for
security and the client is not using
security.
That pointed me to look at the Binding settings on the client side. It turned out that I hadn't added the required security element to my custom binding there. Since I was doing this through code, I needed the following (note the 3rd line):
var binding = new CustomBinding(
binaryEncoding,
SecurityBindingElement.CreateUserNameOverTransportBindingElement(),
new HttpsTransportBindingElement { MaxReceivedMessageSize = MaxMessageSize, });
As to why Visual Studio was showing that error, I've no idea - looks to me to be a bug.
Automatically attaching to a service has the following limitations:
The service must be part of the Visual Studio solution you are debugging.
The service must be hosted. It may be part of a Web Site Project (File System and HTTP), Web Application Project (File System and HTTP), or WCF Service Library project. WCF Service Library projects can be either Service Libraries or Workflow Service Libraries.
The service must be invoked from a WCF client.
Debugging must be enabled with the following code in the app.config or Web.config file:
<system.web>
<compilation debug="true" />
</system.web>
See Limitations on WCF Debugging
In addition, if both projects (client and service) are in the same solution but will run in different processes (for example if you are using your local IIS Server for development and are running your web application on a different application pool than the service it consumes), you may need to enable "Multiple startup projects" for the solution (on Solution Properties -> Startup Project) so that the debugger can attach to both.
To avoid the service browser window to show up every time you debug, you may set the "Start Action" (on service project properties) to "Don't open a page. Wait for request from external application."
This is from personal experience and may help others.
The other reason you might see this error (and I believe is the case for me) is if you're running in 64bit Windows. Apparently Visual Studio doesn't have any x64 debugger support.
You can work around this by changing the Platform Target for the consuming application:
Project Properties -> Build -> Change "Platform Target" to "x86".
Unfortunately this won't work for me as I'm trying to run in the Windows Azure Development AppFabric which seems to require everything to run in 64bit mode!
I also got the same problem. I changed in both client & service config files like
Compilation debug is set to true.
This worked for me.
Have you tried
<serviceBehaviors>
<serviceDebug includeExceptionDetailInFaults="true"/>
</behavior>
</serviceBehaviors>
For debugging purposes?
Edit : nevermind, I think I misunderstood the question
I've had a similar problem and it turns out to have been due to Windows Authentication not being enabled on the IIS site/virtual directory.
Have you tried setting the authentication mode to Integrated instead of Anonymous?
http://msdn.microsoft.com/en-us/library/x8a5axew(VS.80).aspx
In your web service web.config ensure that compilation debug is set to true.
That should fix your problem!
In my case the problem turned out to be something completely different. I had changed the name of an operation on the webservice and forgot to update the client. For some reason this resulted in the "Unable to automatically debug ..." error.
It can also be that the same port number is used in IISExpress and IIS. If you are developing a WCF application in Visual Studio and IISExpress and then install the same application on your local IIS make sure not to use the same port number in IIS and IISExpress. Using the same port number will lead to this error message.
I had the same issue in Visual Studio 2017. After deleting the hidden .vs folder in the root of the solution folder, I was able to debug again.
Add this line of code after you create your service reference in your client.
MyWCFService.IService _proxy = new MyWCFService.IService();
_proxy.ClientCredentials.Windows.ClientCredential = System.Net.CredentialCache.DefaultNetworkCredentials;