can anyone help. I have recently moved servers, its IIS7 rather that our previous IIS6 but everything else is the same, i have set the region to the UK and all date formats plus system local .. I mean everything ..
But when a webpage asp.net is running on IIS7 it thinks the dates are another format..
This is really puzzling .. i did manage to fix it by putting in each web.config
<globalization culture="en-GB"/>
but i have to put it in everyone.. I know i can aslo put it in machine.config.
But i don't understand it, my other server works without modifications. I have checked the web.config and the machine.config on my old server and it has none of these additions
Any ideas?
Thanks
Make sure you have also ticked the box in Regional and Language Options (Advanced tab) to say "Apply all settings to the default user profile. The account that .Net runs under will remain as US unless you do this. Reboot.
Been there :)
Check the localization options on the box and see what it is set for--someone probably just selected en-US for the setup and forgot to tell anyone.
Related
I get the following warning in Chrome: "Resource interpreted as Stylesheet but transferred with MIME type text/html." This happens when running the website in the browser from IIS 8 (on Windows 8). If I run the website from Visual Studio (2010) using the File System I have no issues (meaning that the CSS has been applied to the website and the website is viewed as expected).
I've read through some posts on this issue, but have not yet been able to resolve it. If someone can give me some suggestions, that would be great.
Actually, I just found out that in my case it happened to be a rights (permissions)-issue. I had a look at the MIME-types before in IIS and they we're set accordingly, that is for CSS set to "text/css". When I added the Users-group to have permissions on the website-folder to have "Read & execute, List folder contents and Read"-permissions set to Allow, it solved the issue.
Conclusion
It may be that due to using a different root websites-folder for IIS that you're CSS "cannot be accessed" properly. Though you would think that the problem is with you're MIME type settings in IIS, it may be that the User-group (you probably need to add the IIS_IUSRS-group as well if you haven't already) wasn't added to the default root folder of where you're websites are located and thus experience this issue.
Follow these steps:
1. Open turn windows features on or off
2. Select and enable Internet Inforamtion Services
3. Select and enable World Wide Web Services
4. Select and enable Common HTTP Features
5. Enable Static Content
6. Press ok
This was a permission issue for myself. I have a problem with new projects my company shares and it allowing my app pool permissions. I have to go in and add the my-pc\Users group and tell it to trickle down the permissions, and give it full rights. Even when I thought I did this to get me access to the page, the JS / CSS files didn't have that group. After re adding it again, the CSS and JS files loaded up and this message was gone from the debugger.
In your configuration file add the css mimetype (text/css), it worked for me..
adding "AddType text/css .css" to my .htaccess in root folder worked for me.
Similar to pjdevries, in my case, this was caused by the inetpub folder being copied or recreated on another volume by the sysadmin. The solution was to grant the local users group execute, read and list permissions to the new inetpub folder
I have a weird issue here, and I'm not sure if its ASP.NET versions, IIS, or me doing something stupid (experience tells me its probably item 3.)
I have 2 websites that worked fine on w2k3, 1 is ASP.NET 1.1, and the other 2.0, with the currency being displayed correctly on web pages.
Since migrating these to a w2k8 box and IIS 7 I have an odd issue where the 1.1 site is now displaying $ rather than the local currency that the user browses to. But the 2.0 site works fine.
Both have IIS set to the same globalisation. (No culture, Client is false, UI Culture is English (en)).
Both sites are hosted on the same server, the only differences I can see are that;
1 binds using <Databinder.Eval(... Price, "{0:c}")> and the other binds to a property that uses String.Format("{0:c}");
So being as the code has not changed I feel that it is an IIS issue. But as both sites have the same globalisation settings in IIS I don't see that it can be.
So, anyone know whats goign on and how to solve it?
Running IIS 10 site that was developed on a UK machine server 2012 was moved to a GCP default build server 2016 which comes US "out of the box".
On the website $ signs appear where £ signs used to.
I changed everything I could in Settings > Region and Language. UK language, keyboard, Update & Security, Drive on Left etc. Absolutely nothing made any difference.
Finally found it in Control Panel > Region. After adding English UK as a display language (and gettting rid of US English)
I needed to go to Adminstrative Tab, Welcome Screen and new User Accounts. Copy the settings.
Now the site is finally displaying correct currency symbol.
Check the Regional and Language options from control panel on the new server and make sure they match the like setting on the old box.
AFAIK, at least String.Format("{0:c}") and probably <Databinder.Eval(... Price, "{0:c}")> as well will use whatever the value of property System.Threading.Thread.CurrentCulture is.
It does not matter whether or not you set it on the page, the value will be assigned to it anyway. And it is pretty reasonable to think, that these settings will come from server settings, which from your description seems to be en-US. Thus $ as currency sign... You might ask yourself why it was working before...
Well, are you sure that you have copied all the configuration files?
Another clue might be, that you have emulated version of .Net 1.1 rather than the real one on your new box. It might be not 100% compatible...
I am having this problem with my ASP.Net application and I have no idea how I can solve it: In order for my date-related parameters to be the same over the whole application, I am taking the date from SQL Server via a stored procedure.
My problem is that when I am testing on the local server, everything works ok (everything is displayed in English as it should be), but when I am publishing it on live (on my company's server), the date-related parameters (ex. month names) are displayed in my country's language (which is not English). I assume it has to do with the settings of the live server. Is there any chance I could somehow set inside my application that the language should be English, despite of localization, settings etc. of the live server?
You can set it in web.config
<globalization uiCulture="en" culture="en-US" />
Look here:
http://msdn.microsoft.com/en-us/library/bz9tc508(v=vs.100).aspx
You can manage this settings in your Web.Config by specifying globalization Element. For reference see the following url: http://msdn.microsoft.com/en-us/library/hy4kkhe0%28v=vs.100%29.aspx
The attribute to set you interest in are "culture" and "uiCulture".
If I try to use the new maxRequestPathLength settings in an ASP.NET application it does not work. I get an unrecognized attribute error. I've tried using both ASP.NET Integrated and Classic application pools in IIS 7. What is also funny is that if you search for maxRequestPathLength on MSDN it is no where to be found in the documentation except in the list of new features for ASP.NET 4. What gives?
Apparently this setting name was changed and move to the registry under "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\HTTP\Parameters." The name is UrlSegmentMaxLength. The default value is 260. This particular setting limits the amount of characters allowed in each path segment of a URL. In https://stackoverflow.com/questions, "questions" would be a path segment.
Documentation for this can be found in the Microsoft knowledge base article on http.sys registry settings.
I've been struggling with this and with help of this post en several other forum post made it work for me. Here is my log and findings:
To allow longer url's then default, just change this in your web.config (.NET 4.0 and up)
<httpRuntime maxUrlLength="1024" relaxedUrlToFileSystemMapping="true"/>
Note: if relaxedUrlToFileSystemMapping is set te to false, urlsegments larger then 260 wil fail with an IOException PathTooLongException:
The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.
To allow longer url segments then the default 260 add/change this registry setting:
"HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\HTTP\Parameters."
The name is UrlSegmentMaxLength. (Dword)
And most importantly after changing this setting. REBOOT your machine.
I've tried IIS-Reset and net stop http / net start http, but this did not make the change effective.
Currently i have 2 machines available.
My local dev-machin (Windows 7 / IIS 7.5) and a dev-server (Windows 2003 / IIS 6.0)
Both took a reboot to make the changes effective.
This had me foxed for a little while. The way to do this in .NET 4 is like this:
<httpRuntime maxUrlLength="1024" relaxedUrlToFileSystemMapping="true"/>
in the <system.web> section of the web.config. I did this and it worked.
I tried to run my WebApp on my local machine today (nothing has changed on it) and I had the above error. I know my machine had a windows update recently (not sure if that has anything to do with it).
The error produces a big print out of css styles and html markup.
In the markup it also says "The requested page cannot be accecssed because the related configuration data for the page is invalid".
Maybe you accidentally changed the web.config and now contains a malformed section. I'd recommend you take a close look to your configuration file.
I'd say that the error page should tell you the necessary information to solve the problem but I assume that if you're asking if because it's not the case :)
I changed the user info. (windows password which was changed) in the IIS & that helped me :)
You may need to enable windows (or some other type of) authentication in IIS for the site specifically.