I've inherited an ASP.NET web application written in C#. In many pages throughout the site the hostname is retrieved using:
BaseHost = Request.Url.Host;
Since I am using Visual Studio 2012 Express and it's installed local IIS Express server, I seem to be stuck with a port number appended to the hostname (localhost) when I debug/run locally. The above code does not result in the port number being included and as such breaks links that are generated by code (menu item links, redirects, etc).
I see that I can overcome the issue by changing the code to:
BaseHost = Request.Url.Authority;
This seems to fix it by including the port when I'm running locally (localhost:4652) and when published to my staging server (development.mysite.com).
My question: Is this bad form? Is there a time or a situation in which this is going to cause problems on my live site? It just seems a lot easier to do a quick replace of all these instances. I've considered writing a small routine to append : with Request.Url.Port, but it seems easier just to use Request.Url.Authority. Too easy maybe...
I've tried to research my question online and at MSDN, but I don't see an answer.
According to MSDN Authority includes the port number while Host does not. Another aspect is that Authority will escape reserved characters if need be.
Without knowing your application it is hard to say whether it is a good idea, but in general I would suspect that it won't break anything... so go ahead...
Another option is to run the application IIS instead of IIS Express...
My problem with this is that it ALWAYS adds the port, even when the port is not required. This can cause issues with multiple servers in some cases For example, in a production server environment behind a firewall on a pair of load-balanced web servers, it kept putting the firewall port in place, but that caused the URL to break because the port was tied to a specific web server in the server farm that wouldn't map correctly through the firewall. So I would be very careful with this method if you're using it across multiple servers. It caused a breaking issue with our application and had to be reverted back to using Url.Host. Plus, it made production web URL's look weird with the port number.
Related
I'm developing a .NET MVC Application to query a PLC for inputs and outputs status using Snap7 library.
For development reasons I connect to my PLC (behind a router) using an SSH tunnel bound to a localhost port, so it becomes reachable at 127.0.0.1:102 address. In this scenario, everything works fine and I manage to read data from the device.
When I deploy my application to the production server a subtle problems begins: I'm no longer able to connect PLC. Error code from Snap7 library is cryptic and the only difference in code is the IP address (192.168.1.100:102 instead of localhost:102) so I suspect a permission problem is involved.
I'm searching for two solutions to my problems: one for the normal deployment, where I have full access to IIS Server and one for Azure deployment. I'm searching for something to put inside Web.config but I'm not still able to find suitable configurations or workarounds.
I am still experimenting with Azure multi tenant development. I now have my first trial thingy, but in order to use subdomain names (customer.site.com) I need to switch my Azure website to shared/reserved. Since I am still experimenting, I rather not start paying for Azure. Is there a way around this? Or, is it possible to test the multi-tenant part in my local visual studio webserver?
No, you can't have custom domain names with FREE websites.
But what you could do, is to switch the tenant recognition from sub-domain to a path. So instead of having tenant10.site.com/ you would have mysites.azurewebsites.net/tenant10/. That would basically be just a change in URL Rewrite rules - which I think is the right way to handle multi-tenancy recognition at URL level. And URL rewrite is supported in Azure WebSites as well Azure Cloud Services.
Testing the multi-tenancy locally is even easier. You just open your hosts file (in a typical windows installation it is located in c:\windows\system32\drivers\etc\hosts. Just add entries for all (sub)domains you want to test, and map them to 127.0.0.1. Something like:
127.0.0.1 tenant1.mydomain.com
127.0.0.1 tenant2.mydomain.com
127.0.0.1 tenant15.mydomain.com
...
Then, run your project with F5 like you would normally do and manually type in the new address in browser's address bar: tenant1.mydomain.com.
However first launch the project with F5 to check the real IP address of local development fabric, because sometimes it may not be 127.0.0.1, but 127.0.0.8 or something else. The IP address that is used in your browser's initial launch is the IP Address you have to fill in your hosts file.
However, if you work with real (sub)domain names in hosts file, do never forget to remove the entries from it, as you will never reach the real Internet sites.
(Sorry if this is a really long question, it said to be specific)
The company I work for has a number of sites, which have been running for some time with no problems. The applications are a mix of ASP.NET 2.0, 3.5, and 4.0, all using an ADO.NET to connect to a SQL Server Standard instance (on the same webserver) all being hosted with IIS7.
The problem began when we moved to an upgraded webserver. We made every effort to set up the server, db instance and IIS with the exact same settings (except for the different machine name, and the fact that we had upgraded from SQLExpress to Standard), and as far as we could tell, we did. Both servers are running Windows Server 2008 R2 (all current updates applied), and received a default install.
The problem is very apparent when starting up one of these applications. When you reach the login page of our application, the page itself loads extremely fast. This is true even when you load the page from a new machine that could not possibly have the page cached, with IIS caching disabled. The problem is actually visible when you enter your login information and click the login button. Because of the (not great)design of our databases, the login process must access a number of databases, theoretically up to 150 separate DBs, but in practice usually 2. The problem occurs even when only 2 databases (the minimum) are opened. Not a great design, but we have to live with it for now.
When trying to initially open a connection to the database, the entire process stops for about 20 seconds every time, regardless of whether you are connecting to 2 dbs or 40. I have run a .NET profiler (jetbrains dottrace) against the process, and the only information I could take from it was that one or all of the calls to sqlconnection.open() was accounting for 90% of the time. This only happens on first-use of the application, but the problem is compounded by the fact that IIS seems to disregard the recycling settings we have set for it, and recycles the application after a few minutes of idle, causing the problem to occur again.
I also tried to use the SQL Server profiler to see which database operations were the cause of the slowdown, but because of all the other DB activity, (and the fact that I had to do this on our production server, because the problem doesnt occur in our test environments) I couldn't pin down the exact operation that was causing the stoppage. I will try coming in late at night and shutting down the production sites to run the SQL profiler, but I might not be able to do this right away.
In the course of researching the problem, I have tried a couple solutions
Thinking it might be a name resolution problem, I tried modifiying both the hosts file on the webserver as well as giving the connectionstrings an IP address instead of the servername to resolve, with no difference. I have heard of the LLMNR protocol causing problems like this, but I think trying to connect by IP or resolving with the hosts file should have eliminated that possibility, tho i admit I never tried actually turning off LLMNR.
I have increased the idle timeouts, recycling intervals etc in IIS, but this doesn't even seem to be respected, much less solving the problem. This leads me to believe there is a setting overriding the IIS application settings on the machine.
multiple other code fixes, none of which made any difference. Is a SqlServer setting causing the problem?
other stuff that i forgot by now.
Any ideas, experience or whatevers would be greatly appreciated in helping me solve this problem!
I would advise using a non-tcp connection if you are still running the SQL instance on the local machine. SQL Server supports several protocols, tcp, named pipes, and shared memory are the more common.
Named Pipes
Data Source=np:computer\instance
Shared Memory
Data Source=lpc:computer\instance
Personally I prefer the Shared Memory. Remember you need to enable these protocols, and to avoid configuration mistakes I suggest you disable all you are not using.
see http://msdn.microsoft.com/en-us/library/ms187892.aspx
IIS Reset
In IIS7 there are two ways to configure the idle-timeout. Both begin by clicking on the "Application Pools" section and right-clicking the appropriate app domain. If you click the "Recycling..." option there is one setting. The other is in "Advanced Settings..." under the section for "Process Model" you will find "Idle Time-out (minutes)" which set to zero disables the process timeout. This later option is the one that works for us.
If I were you I'd solve this problem first as restarting the appdomain and/or worker process is always painful even if you don't have a 20 second lag.
Some ideas:
from the web server, can you ping the db server and get a "normal"
response, or are you seeing a similar delay?
if you're seeing a delay, run a tracert to see if you can nail down where the slowness is occurring
try using a tool like QueryExpress (http://www.albahari.com/queryexpress.aspx) which doesn't require an install to run. You can download this EXE and run it from your web server. See if you can connect to your db using this and run queries in a normal fashion.
Try something like SysInternals' TcpView (http://technet.microsoft.com/en-us/sysinternals/bb897437) to take a look at your open connections and see what activity is happening on your server and how much data is being sent to and received from your db server.
Just some initial thoughts on where I'd start to look based upon your problem description. I hope this helps. Good luck with things!
With IIS not respecting recycling settings: did restarting IIS/rebooting change the behavior?
I have a bug where special characters (danish 'ø' in this case) are shown correctly when running locally, but wrong when the code runs on a server (I get a pipe '|'). I was trying to solve this today, but I did not have access to the server, other than updating the code files. I will limited access monday, so I can at least write intermediate results to a log file, but to be prepared I thought I'd ask for suggestions here.
Program flow:
A C# test calls my own web service via a WebRequest.
This web service calls an external web service via another web request.
When running my own web service locally I get correct results returned from the external web service.
When deploying the code to the server the external web service returns an error; it didn't find the word I was searching for. Except that I entered 'Bøssemagergade', but the word it complains about is returned as 'B|ssemagergade'. What can cause this difference? AFAIK the server runs with the exact same regional settings as my local machine.
I'm sure this is common stuff, but I haven't been doing web services before (I do feel at home with C#/.NET though, and know about encodings etc.).
Thanks!
You need to check your data at every stage in the process. Make sure you understand which encoding you're using (try to avoid using Encoding.Default) and verify the binary data going across the wire with something like WireShark.
See my debugging unicode problems article for further information.
I'm quoting myself on a previous question I asked to further explain:
"I'm trying to run a freshly created ASP.NET Website using C#, however when I do so it launches FireFox and attempts to connect to http://localhost:1295/WebSite1/Default.aspx (for example), but after about 10-15 seconds it displays a "Connection Interrupted - The connection to the server was reset while the page was loading." Error.
This issue is also present with older ASP.NET C# pages/Web Services I've built in the past, nothing is actually running off the ASP.NET Development server."
This is the problem that was occuring, that is before I noticed every time I ran the website, the notification for the ASP.NET Server-startup showed one port (1130 for example), and when the website failed to load; it turns out it was attempting to load the site on another port (In this case, 1128). It was suggested that an anti-virus program could have caused this kind of redirection; low and behold uninstalling Nod32 fixed the problem!
So my question is: Has anyone found a way to create an exception or remove this functionality from Nod32?
Within Nod32 enter the Advanced Setup options, and turn off protocol filtering.
It's a known problem with NOD32. Looks like it's IMON module (protocol filter) accidentally does some modifications of TCP packets that go through it.
The solution is to either turn it off, or use a different software.