I installed fiddler the other week, and now some HTTPs requests only work when Fiddler is open and running. When Fiddler is not open. I have gone into Windows system proxy settings and confirmed that the proxy server is off. Uninstalling fiddler does not fix it.
I also uninstalled Fiddler Everywhere and installed Fiddler Classic. Same thing, only works when Fiddler is running, only difference is the port number changes. It looks like dotnet core is caching the information somewhere that I cannot find.
I am using .net 6.0.3 and Visual Studio 2022. When running the same code on production server there is no issues. There should be no proxy server set.
No connection could be made because the target machine actively
refused it. (127.0.0.1:8888)
UPDATE: Looks like RestSharp is caching the proxy?
Related
I have an ASP.NET website that is hosted on a client's web-server, which I used to be able to publish directly from Visual Studio with Web One Click Publish. The connection was made over FTPS, so would connect to the server's IP address on port 21; i.e. ftps://101.102.103.104:21.
However, after a recent update to the SSL cert on the server, I can no longer publish to the server from VS - I get the error below when testing the connection or attempting to publish the files:
The workaround I've got is to publish to a local folder and then connect with FileZilla to push the files up. The credentials I use are the same in FileZilla, and that doesn't have any issues with making the connection or uploading the files. So there appears to be an issue with Visual Studio publishing over FTPS with this new cert in place.
One initial difference I noticed with deploying via FileZilla was that upon initial connection, I would get a warning about the certificate mismatching the site name - but that was only when connecting by IP address. If I used the server name (which has the same domain as the wildcard cert on the server), it didn't display that certificate popup. Unfortunately, using the server-name in the VS publish settings still gave the same error.
While I was grasping at straws for a fix, I tried connecting on port 990 to see if I could use implicit SSL (a few articles mentioned this as an option), but this didn't work - I'm not sure if that port is blocked at the firewall or if there's just no service listening, but I can't telnet to the server on port 990.
I don't believe this is a limitation of Visual Studio as it was working before. Possibly our IT guys made some server-config changes at the same time as they applied the certificate? Has anyone else encountered this and were you able to resolve the issue?
So after some further digging, I found a Visual Studio problem ticket from January 2018 that indicates FTP publishing doesn't support TLS 1.2:
https://developercommunity.visualstudio.com/content/problem/190065/unable-to-publish-web-app-via-ftp-over-tls-1112.html
From checking the FTP connection to the web-server from FileZilla, it appears this requires a TLS1.2 connection. Therefore I assume that when the new certificate was applied, the TLS1.0 protocol was disabled on the server by IT, and that led to the FTP connection failing.
Hopefully if anyone else runs into this issue, they'll benefit from the knowledge that TLS1.2 is not currently supported in Visual Studio FTP publish (as at version 15.7.4).
UPDATE:
Can confirm that Visual Studio 2019 (v16.1.1) does support FTPS publishing using TLS1.2
I am just trying to get node and websockets running alongside an ASP.NET MVC project.
I am running on Server 2012, IIS8, latest node.js and iisnode. Websockets are enabled for IIS and .NET 4.0 MVC project runs fine. Also, I can run websockets on node independent of IIS just fine (on a separate port).
I downloaded the faye websocket and the dante example project and installed it.
When I do not have websockets disabled, I get
Unable to establish WebSocket connection to ws://localhost/dante/server.js
When I disable websockets, whether in dante or wwwroot, I get
This configuration section cannot be used at this path. This happens when the section is locked at a parent level. Locking is either by default (overrideModeDefault="Deny"), or set explicitly by a location tag with overrideMode="Deny" or the legacy allowOverride="false".
I tried to specify overrideMode="Allow" in the wwwroot webconfig and that didn't seem to work.
I have also tried removing the wwwroot web.config and it seems to make no difference. I also tried turning off the firewall on the server (just for kicks) and that didn't change anything.
Thanks for any help and assistance. I am open to using anything (socket.io, for example) but would like to keep running ASP.NET MVC and node on the same port to eliminate firewall issues and prevent having to use multiple servers/domains/etc.
EDIT:
Running
c:\windows\system32\inetsrv\appcmd.exe unlock config -section:system.webServer/webSocket
Made the IIS error go away, but now I still receive this:
Unable to establish WebSocket connection to ws://localhost/dante/server.js/ws
WebSocket connection is closed.
I've opened an issue here.
EDIT 2: I had installed iisnode from the Web Platform Installer. Apparently, the version from WebPI is old. I needed to get the latest from the github site here under Installing for IIS 7.x/8.x. Once I installed the latest version, IT WORKS!
This is fantastic! Thanks to tjanczuk! :)
iisnode added support for websockets starting from version 0.2.0. Make sure you install the latest iisnode using links from https://github.com/tjanczuk/iisnode.
I know that generally speaking, this cant be done, that is get another PC to call a site hosted under the ASP.NET DEvelopment Web Server remotely (generally you can only use localhost:port to get to it).
But I was wondering if anyone has seen, or knows of a way to get around it? I am a RESTful API developer in my office, and I would like the PHP guys to test the APIs on my machine so that I can have the Visual Studio 2005 debugger attached, and I can more easily find problems.
THe main issue is, that my machine is a Vista machine, and unfortunately, the APIs I have developed do not work under IIS7, even Classic Application Pool mode (which eliminates hosting them on a local IIS impossible).
Alternatively, is there a way to use IIS6 on another machine to suite my needs?
Update
Based on the advise that I have gotten and after much trial and error with the suggestions made, I was able to get Squid to act as a reverse-proxy and do exactly what I wanted to do. I have blogged about it http://www.ashleyangell.com/index.php/2009/03/configuring-a-basic-reverse-proxy-in-squid-on-windows-website-accelerator/ in case anyone else wants to do the same thing.
This is substantially easier than the Squid option:
"Accessing the Visual Studio ASP.NET Development Server from iPhone"
Also there is an update that works well under Windows 7, too:
"iPhone Accessing the Visual Studio ASP.NET Development Server - Windows 7 Update"
I have just tried http://code.activestate.com/recipes/483732-asynchronous-port-forwarding/ successfully. It's a Python script that just forwards the traffic.
Assuming the machine your dev server runs on is 192.168.42.42 and the dev server is on port 12345, run the script (on the same machine) with the command line arguments
-l 192.168.42.42 -p 8000 -r 127.0.0.1 -P 12345
From a different machine, you can then access the server via http://192.168.42.42:8000.
Be sure to change sender.handle_close as noted by Dwight Walker in the comments:
def handle_close(self):
self.close()
if len(self.receiver.to_remote_buffer) == 0:
self.receiver.close()
Can't you just run IIS7 in Classic Application Pool mode?
The Development Web Server is strictly limited to Localhost, you would either need to decompile and recompile it, or set up some kind of Proxy on your machine.
And on an unrelated Topic: Even though Win2003 Server SP2 R2 should be supported up to March 2012, maybe IIS7 Support should be added to your application to make sure you can run on 2008 Server as well.
Basically i spent 5 hours making this work, and ultimately if you want a 5 min fix here goes:
1. Port forward incoming traffic to your local ip on your network
TCP Any -> 3127-3128
TCP Any -> 80-81
TCP Any -> 8080
TCP Any -> 8000
TCP Any -> 8888
to
192.1681.1.3 (the local ip of the machine running .NET Dev server.)
2. Download SPI Port Forward
3. Heres the tricky part - Setup 2 forwarding rules as follows:
Local port: 8080 Remote: localhost Remote port 8080
Local port: 8080 Remote: localhost Remote port: .NET Dev server port
Without that second rule the .NET dev server wont serve the page
4. now visit your public IP address at port 8080 -- and you got it
Z
You might want to take a look at UltiDev's version of the Cassini web server. They took the Microsoft Open Source Cassini web server and enhanced it to allow among other things, remote connections.
You can attach VS to the process, and watch your RESTful APIs being called from the PHP application, exactly as you describe above.
Just use a simple Java TCP tunnel. Download this Java app & just tunnel the traffic back. No messing with IIS necessary!
http://jcbserver.uwaterloo.ca/cs436/software/tgui/tcpTunnelGUI.shtml
In command prompt, you'd then run the java app like this... Let's assume you want external access on port 80 and your standard debug environment runs on port 1088...
java -jar tunnel.jar 80 localhost 1088
(Also answered here: Accessing asp. net development server external to VM)
Switching IIS 7 to Classic pipeline does not resolve your compatibility issues?
VS 2005 has a remote debugger, as did many versions before that.
YES THERE IS! :D
I was also looking around to overcome this limitation for some time and accidentally I stumbled upon following article:
http://eeichinger.blogspot.com/2009/12/sniff-http-traffic-with-aspnet.html
I haven't tried it myself yet, but looks quick & simple (although some may say this is hardcore).
BTW. I recommend you look at some other posts at Erich Eichinger's blog, since there's more really valuable stuff.
This post helped me:
http://staticvoidmain.cognitioab.se/index.php/2013/01/remote-debugging-asp-net-development-server-with-spi-port-forward/
It suggests using a third-party application on your developer machine to act as a proxy (sort of). So you connect to this app, and it forwards all your requests to the development server. Works like magic :)
Developing an ASP.Net website.
Running IE8.
Need to test website under IE6.
MultipleIE6 install broken by IE8 install (can't type in textboxes, yes I deleted cache, yes I re-registered the dll's).
Created VPC running IE6.
Can't connect to host WebDev.WebServer.exe.
Is there any way to configure WebDev.WebServer.exe so that it will accept remote connections?
The workaround for the way that webdev.webserver is crippled to refuse remote requests is to use a lightweight proxy server running on the same host as webdev.webserver. The remote browser then uses the proxy and its requests appear to webdev.webserver like requests originating from localhost. I've used Privoxy succesfully.
Sample config:
Configure Privoxy to listen on an IP
address that is routable from your VM
(eg 192.168.1.1:8118). You can put an IP address on a looback on your host OS and use NAT with the client OS.
Configure your browser(s) in the VM to use
192.168.1.1:8118 for its proxy for all connections including localhost.
Start your app in webdev.webserver
With your VM browser go to the same URL as you would with a browser on your host OS (eg http://localhost:3254)
From the perspective of webdev.webserver the requests will originate from Privoxy on 127.0.0.1 and it will happily serve them up.
UPDATE
These days, I am using Fiddler2 for this. Fiddler has an option in Tools > Options > Connections to "Allow remote computers to connect." But also note that IISExpress can be configured to accept remote connections.
AFAIK, WebDev is coded to specifically reject all external connections... so the short answer would be "no".
Best thing to do would be simply publish the website to your VPC running IIS and test it that way.
I ran into this same issue, and after some research, found that the method detailed at this site worked for me:
http://www.funkymule.com/post/2009/04/17/Making-ASPNET-Development-Server-Listen-for-Remote-Connections.aspx
It involves modifying and reassembling the Webdev server and DLL, but once it's all up and running, I've been able to use older versions of Internet Explorer running in VPC/XP Mode to connect to the WebDev server running on the host machine via the internal network IP (192.168.x.x).
Hmm i am not shure this works, but try adding the WebDev.WebServer.exe to be unblocked from your Windows Firewall.
If this doesn't work you have to install IIS and set a virtual directory directly on your development folder.
I use one of Microsoft's VPC images to test IE6 using the debug webserver, so I don't know what could be causing your issues. Sounds like it could be a networking issue with the virtual machine.
Also IEtester works well for quick checks of rendering and functionality. I have yet to see any major differences between the behavior in IEtester and the real IE6 under XP, but the possibility exists so I still check with the virtual machine before release to production.
http://www.my-debugbar.com/wiki/IETester/HomePage
Im testing an ASP.NEt site. When I execute it, it starts the ASP.NET Development Server and opens up a page.
Now I want to test it in the intranet I have.
Can I use this server or I need to configure IIS in this machine?
Do I need to configure something for it to work?
I've changed the localhost to the correct IP and I opened up the firewall.
Thanks
Yes you can! And you don't need IIS
Just use a simple Java TCP tunnel. Download this Java app & just tunnel the traffic back.
http://jcbserver.uwaterloo.ca/cs436/software/tgui/tcpTunnelGUI.shtml
In command prompt, you'd then run the java app like this... Let's assume you want external access on port 80 and your standard debug environment runs on port 1088...
java -jar tunnel.jar 80 localhost 1088
(Also answered here: Accessing asp. net development server external to VM)
No, you can't. It's set up so it only works on localhost, and I couldn't find any workarounds to make it work.
But, here's what I've been doing - I created the website on a specific port in IIS and opened that port up so it's visible on the network. I pointed that IIS website to my website's root folder (the one with web.config in it). Then I continued to use the ASP.NET Development server on that local machine while developing - both IIS and the ASP.NET Development Server can access the files at the same time (unless you're doing something wacky).
Let me know if there's a challenge with running IIS on your machine and I'll update my answer.
I realize this isn't a direct answer to your question, but an alternative to debugging using the ASP development server is to attach to the IIS process: How do I attach the debugger to IIS instead of ASP.NET Development Server?
Nope, stupidly (IMHO) there's no way to get the default ASP.net development server to serve pages to IPs other than localhost. What I did was to use UltiDev Cassini which is very quick to set up and is basically a version of the ASP.net development server compiled by UltiDev, and it will serve pages to any IP address.
Just for those who don't want/cant set up IIS for whatever reason...
Use fiddler or similar on your host - set your browser on the client VM to use the proxy then just use localhost:dev_port as usual on the client.
All requests from the client goto the proxy on your dev machine which routes to localhost on the dev machine and the ASP.net dev server thinks the request is from your dev machine!
You can recompile Cassini to get it to work - there's a fairly easy to remove check for localhost in there. Or, I'm pretty sure Ultidev's Cassini doesn't have this restriction. Both of these are easier to setup than IIS.
But, yeah, the builtin WebDev.WebServer doesn't work....Hmm, unless you run something like AnalogX's Proxy on your dev box and point it to the WebDev port. That should work (though I haven't tried it, it should take < 2 mins to setup).
You can use Cassini to expose your web apps externally. You just need to proxy the connection. I wrote a simple program to do this that you can run in another VS instance. Just change the port to match the port Cassini is using.
https://gist.github.com/945649
You can do port redirection using SOAP Toolkit 3.0
Once installed, go to My Programs > Microsoft Soap Toolkit 3 > Trace Utility
Once Trace Utility opened, go to File > New > Formatted Trace
In the dialog insert your ASP .NET Development Server port in Forward To Destination Port field.
It's only a workaround for testing purposes
I believe the built in ASP.NET server only works on localhost. You'll have to use IIS.
Compile all you website in Debug mode, then create the website and publish it in IIS (make sure you can view it from other machine). Then attach the VS2010 Debugger to the process with the AppPool of your website (the process is called w3wp.exe when IIS>v5 and aspnet_wp.exe when IIS<5).
If you make some changes, just replace the package contents on the physical path of the website, and there you go again.