I am currently developing a service with wcf 4.0 (visual studio 2010 RC).
When I try my service on the Visual Studio Development Server, it all works perfect.
However, when I tree to run my service on IIS7 on a windows 7 machine, the service doesn't work anymore. (I already changed the framework version on my application pool).
When I call an operation on the service, like the default operation GetData when I create a service, I get an error.
I used the WCF test client to connect to the service.
When I call the operation on the service, the Visual Studio Just-In-Time debugger shows the following message:
An unhandled win32 exception occured in w3wp.exe
The Just-In-Time debugger was launched without necessary security permissions. To debug this proces, the JIT debugger must be run as an administrator. Would you like to debug the proces?
As far as I know, I am running Visual Studio as an administrator and this is probably the process that starts the JIT debugger.
The only option I have is to debug the W3WP process, which is probably not the right thing to do.
What can I do the make the Service to run on IIS7?
I already solved my problem, it was the ApplicationPoolIdentity that was blocking everything.
Related
I have recently deployed my ASP.NET Core application to my IIS8 server. However due to some issues, I have to remotely debug it.
I installed the Remote Debugger and managed to connect to the server and Attach a process.
However, I am unsure of what to attach from there. I have tried attaching all dotnet.exe and w3wp.exe processes but each time I do that, my breakpoint turns white and says that it won't hit.
I took a look at my Modules tab and for some reason, my symbols aren't loaded for my application dlls. I have made sure that the configuration is Debug and that the ASPNETCORE_ENVIRONMENT is Development.
Currently this is what I am doing:
Run the Remote debugger on the IIS server
Run the website on my local laptop
Attach a process in Visual Studio
I am new to azure, I have hosted a asp.net core web api in Azure App services. I am able to browse the azure link. However I am getting some internal error while accessing the service.
To find out the error I want to debug the application by attaching to visual studio. But while attaching the debugger I am getting below error as shown in the image.
ERROR POPUP WHILE ATTACHING DEBUGGER
Error: "Unable to find a process called dotnet with arguments .\APICore.dll. The process may still be starting, please try again."
APICore is my Web api project.
I have verified that REMOTE Debugging is enabled.
Application is ASP.NET Core.
Visual Studio is VS 2017 community
edition.
I've had the same problem today, and this is what worked out for me:
1) Instead of attaching the debugger via Server Explorer, go to Debug > Attach to Process...
2) Set the Connection Target to your App Service url without http and with port 4022.
So, http://myappservice.azurewebsites.net would become myappservice.azurewebsites.net:4022
3) Hit the Refresh button. You will be prompted for credentials to access your App Service. Those can be found on the MSDeploy publish profile of your publish profile file:
<publishData>
<publishProfile profileName="myappservice - Web Deploy" publishMethod="MSDeploy"
publishUrl="myappservice.azurewebsites.net:443"
userName="{USERNAME}" userPWD="{PASSWORD}" ...>
<databases />
</publishProfile>
<publishProfile profileName="myappservice - FTP" publishMethod="FTP" ...>
<databases />
</publishProfile>
</publishData>
4) After the available process show up, select w3wp.exe and hit Attach
Had the exact same issue, tried several things (open in Admin mode, open outbound port 4022, 'Attach debugger', 'Attach to process') but nothing worked.
Just switched from VS 2017 Community edition to Visual Studio 2019 - Enterprise edition and now it instantly works flawless:
Published my Azure App Service in Debug configuration
Attach debugger via the Cloud Explorer
Set the breakpoints and hit them when sending requests to the API
So perhaps switching to 2019 will solve it for you as well.
There are few options that you can try out and see if that helps.
Ensure Visual Studio is opened in Administrator Mode and follow the
same steps.
Open the Outbound ports 4022 for VS 2017 on corporate firewall.
You can also go through the below links in order to Remote debug the
application
https://learn.microsoft.com/en-us/visualstudio/debugger/remote-debugging-azure?view=vs-2017#remote_debug_azure_app_service
The answer above using a regular
"Attach to Process" using creds from a publish profile downloaded from the portal worked for me.
VS2019 (community and professional, multiple azure accounts, multiple machines, physical and virtual) here, and the cloud explorer "AttachDebugger" never worked. In fact it hung vstudio at "attaching to process" and had to kill VStudio from task manager to stop it.
Strange because at other companies/projects I didn't have this problem. For years I relied on debugging azure from desktop for a variety of projects. This particular software I inherited, and I expect that something in its origination or construction (there are several ..."sub optimal"... aspects to it).
My application can not deploy because of the following error:
Web deployment task failed. (The application pool that you are trying to use has the 'managedRuntimeVersion' property set to 'v2.0'. This application requires 'v4.0'.)
Right now, I'm attempting to deploy my .NET application to IIS. VS is attempting to target the "DefaultAppPool" application pool. I want it to instead target the "ASP .NET v4.0" application pool. How do I do that in Visual Studio?
I am trying to not change any settings within IIS if possible.
I don't know if this would be considered a hack, but it got the job done without any issues.
What I did was I first created a folder in IIS and then converted it to an application. After which, I had it target the .NET 4.0 application pool and voila, Visual Studio was able to deploy the application without the error.
I hope this helps people in the future that Google their issue and come upon my question.
I have an ASP.Net web application developed in Visual Studio 2008 (.Net 3.5). I have copied this solution to another root folder (both on my Win7 64b machine) and upgraded the copy to VS2013 (Professional) and .Net451, but when I try to debug the web app in VS2013 I get an Access Denied error ("Unauthorized: Logon failed due to server configuration. Verify that you have permission to view this directory or page based on the credentials you supplied and the authentication methods enabled on the Web server"). I don't have this issue runing the original from VS2008 on the same machine.
Apart from the changes mentioned above the two are a straight code copy.
In VS2008 the project Web properties are: Use Visual Studio Development Server, auto-assign port, Virtual path = /
In VS2013 the project Web properties are: Server=IIS Express, Project URL=http://localhost:63064/ (and I have clicked on Create Virtual Directory)
I can see this must be some sort of security issue, but what extra needs to be done to get a VS2008 web app, upgraded to VS2013, to run within the VS2013 IDE?
Postscript: If I start the web app without debugging (ctrl-F5) I get "HTTP Error 503. The service is unavailable."
It turns out that the simple solution is configure the web app properties in VS2013 to use the local webserver (IIS) instead of IISExpress, and also to run VS2013 as administrator (but this is not necessary for VS2008). So obviously it is an IIS permissions thing but IIS is common and hasn't been changed - so what has changed in VS2013 to make this necessary? I don't really want to run VS2013 as administrator if I can avoid that.
I've been trying to debug an existing asp.net web application that requires me to debug against an IIS website.
I've installed the app and can navigate to it on localhost. However, when I start VS 2008 as an Administrator and try to debug it, I get a message "Unable to start debugging on the web server. The IIS worker process for the launched URL is not currently running."
I've looked through some of the help file contents and can't seem to figure out what is going on. Clearly, the IIS worker process IS running, since I can navigate to the site locally without VS open.
My boss has suggested that it might be because my OS is 64 bit. Any ideas?
You must start the IIS worker process for the application pool,
Place a test HTML page in the web application folder. Access to this HTML page to initiate a w3wp.exe process for this application pool.
Attach VS debugger to this process.
Start to access the ASPX pages and do debugging.
Be sure you are using the x64 or x86 debugger respectively depending on how you compiled your app.