I would like to be able to step through an application deployed to a remote location which as yet has nothing bar version 3.5 of the .Net framework.
What steps do I need to go through to achieve this and how long would you envisage this taking?
How to: Set Up Remote Debugging
Screencast for Visual Studio 2008 - Remote Debugging with MSVSMON.EXE
This is also a good KB showing some troubleshooting scenarios..
If you have unrestricted TCP/IP access to the remote location, this will be very easy (as in, 5 minutes tops to get it to work): see How to: Set Up Remote Debugging and How to: Run the Remote Debugging Monitor for the steps involved.
If your development machine is separated from the remote server by firewalls, routers, etc., things get a bit more difficult. Since remote debugging requires Windows authentication, DCOM and other things that are usually (and quite sensibly) blocked by security policies, you'll most likely require some kind of VPN access to the remote network in order to get things to work.
Setting up a Routing and Remote Access service on the target server is a quick way to get PPTP dial-in access to it, but there are significant security implications to doing this. So, this is most likely the step that will take up most of your time (and, depending on the organization that manages the target network, lots of discussions with their network/security people...).
My advice would be to start testing with remote debugging using a test machine on your local LAN first, and deal with the connectivity issues once you're comfortable with the basics.
Related
We have run into a problem with IIS, TLS 1.2 and domain users. I searched SO and other forums, but all possibly related topics didn't lead me to a solution.
Please don't judge the configuration, it wasn't invented by me, I just need to solve this problem.
What happens is the following:
We have an old web application, that opens an executable with Process.Start and that executable calls an external webservice. This used to work fine with TLS 1.0, but in the near future, the external webservice demands TLS 1.2.
So now we are trying to make this work, and we are almost there: we upgraded the executable's .Net Framework version to 4.7.2 and enabled TLS 1.2 on the Windows Server 2008 R2. The web app's .Net Framework version is set to 4.6.1. It seems to me that this should be everything there is to it.
And indeed, when we run the executable stand alone (not called by the web app) from the server, so owned by the domain user logged on to the server (with RDP), everything works as expected; we receive the proper answer from the web service.
Also, when we call the executable by the web app and in IIS the application pool identity is set to a build in account: ApplicationPoolIdentity, everything works as expected as well.
But, when we set the application pool identity to a dedicated domain account (so a different one than the one that executed the executable earlier), the trouble begins. Connecting the web service fails with the following exception:
System.ServiceModel.EndpointNotFoundException: There was no endpoint
listening at https://<some url>/<some webservice name>.asmx that could
accept the message. This is often caused by an incorrect address or
SOAP action. See InnerException, if present, for more details. --->
System.Net.WebException: Unable to connect to the remote server
---> System.Net.Sockets.SocketException: A connection attempt failed because the connected party did not properly respond after a
period of time, or established connection failed because connected
host has failed to respond ...
Now the question is of course, what could be causing this?
I like to believe that the failing domain account is configured correctly, but it seems it is not. Or could it be something else, that I don't even know the existence of...
EDIT:
I managed to narrow it down to a permissions issue: when the dedicated domain account runs the application stand alone, it works as it should. When the dedicated account runs it from within the IIS context (started by the web app), it doesn't work, but when the dedicated account is given admin rights, it also works as expected.
That leaves me to the question: what additional permissions does IIS need to allow this setup? Maybe in combination with TLS 1.2 thingies.
Any help would be greatly appreciated.
I belong to a team of several people, divided throughout the world.
We are building software for a certain platform, lets call it "Platform S". To develop for this platform there are 2 resources that are necessary. One is the SDK, which can be installed only using certain installer, that connects directly with the Platform S centrail server, and install it in out machine. The other resource is the developer website, where people post their questions and doubts about the SDK and hardware it operates on itself.
The problem comes that to connect to these resources, both the forums and to download/update the SDK, I need to have always the same IP address.
To solve this problem, I initially created a server with a fixed IP and installed proxy software in it, so that we could configure our local machines to connect to the proxy, and all have the same IP address.
Of course, to avoid that this proxy were used with nefarious purposes by hackers, and others, I protected the proxy with a password. When accessing the forums, this was no problem, as the browser opened a small dialogue window, to ask me for the user and password. But the installer that is in charge of installing/updating the SDK does not offer me this dialogue window. The last time, I disabled the password for a while, since SDK updating is not a task that one does that often, but after just a couple hours, I already got a notice from my server provider to warn me that the server was being used for malicious purposes. So that meant that this solution was not appropiate.
What approach could I take to solve my problem? Is the proxy idea the wrong way to go?
There is an intranet based ASP.NET application that is deployed to a server (IIS) and a group of clients (about ten). The end user can then decide to either connect to the local application (deployed to their local machine) or the server version. I do not understand the reasoning for doing this. My question is: is this common practice?
yes, it is a common practice to verify the performance of the application. Each client will have their own settings and as per process, application should not break in any kind of environment. it is always beneficial to put a server version and a local version.
If the clients are laptops, and the application supports disconnected data sets and synchronization, it would make sense. Typically you'd see something like this when the client machines are taken off-network to be used at a remote work site.
I get a
Stack Trace:
[SocketException (0x2af9): No such host is known]
System.Net.Dns.GetAddrInfo(String name) +471
when trying to debug an ASP.NET web site on a laptop that has no network interfaces connected.
It is logical since no DNS server is present to resolve the localhost GetAddrInfo call. How do I work around this issue and allow myself to debug web site in a disconnected environment?
I'm a pretty dedicated "hack great things on long plane flights" guy. The long term answer is you design the app to work in a disconnected environment. This is tougher with today's apps that tend to rely upon public internet services to function. Then again they are putting wifi on planes.
Anyhow, specific advice is hard to give as the important question is "why are you hitting the external host in the first place". If you only have a a limited number of sites it reaches out to and it can handle not being able to talk to the external services in question you could use the windows hosts file to provide your own local DNS services. You could probably fake some more things behind that. But that does not scale well in general.
You could add a virtual network card. That should bypass the problem with the DNS. Here are few options on doing that:
How do you create a virtual network interface on Windows?
We have deployed an application on the server.
Problem is, sometimes the application will be down due to some issue (Ex: While Downloading huge volume of data into Excel).
The application will be up after manually restarting the IIS.
We are creating a new application, so we are not working to fix this issue.
As a workaround, we are trying to build an exe with the below requirement:
Ping the application deployed on the server and find out whether the application is up or down, If the application is down, restart IIS.
Is it possible to ping a local website on the IIS? Is there any other way to do a temporary fix?
Hmmm, that kind of stability isn't good. However, you're interested in monitoring a URL and determining whether it is active...
TBH, I'm sure there are a few monitoring applications knocking around, some even free if that's you thing that will recognise specific ports and utilise appropriate protocols such as HTTP. But if you fancy having a go yourself you could always utilise the HttpWebRequest to mock up a request to the server and hopefully it will respond in a timely manner. Typically if you're just touching the server you can utilise a 'HEAD' request you just receives the header data rather than all the data. Check out this example.