Changes not reflected by IIS - c#

I have done some changes(added a button) to Home.aspx page of my vb.net web site.
I have published my website and hosted in IIS.
I could able to see the code for button in my Home.aspx page of my published files.
But when I accessed via URL, I did not get button on my home page.
What could be the issue? I guess the problem would be in IIS. Please suggest some options to try out in IIS.

Problem solved.
While publishing my code in VS, I have unchecked 'Allow this precompiled site to be updated'

Related

Site not working correctly when browser history cleared

I have an old ASP.NET intranet application where the forms login page is demonstrating unusual behavior. If any version of IE has a cleared history (history, not cookies) when they submit to log in the page executes a blank post back and remains on the login page.
If they refresh the page or had been redirected to the login page from trying to directly access another page then they are logged in without trouble.
I have published additional copies of this application to the same IIS server and they initially did not exhibit this behavior however after some number of hours they began acting the same way. Republishing to the same instance does not "fix" the issue like publishing to a new site does and neither does removing the old application and then publishing to the same name.
I'm not sure where to go from here so any help would be appreciated.
To me these are the key observations I have made:
This only effects our production server. The same code published to two other servers do not exhibit this defect. This code has worked for years until recently.
I replaced the button click code with a Response.Redirect to Google. When the button is not behaving correctly this redirect was not being fired. This indicates to me that the button code is not being executed. After the page is reloaded/refreshed it redirects properly since the button code is now firing.
When the same code is published to this IIS server under a different name it does not exhibit this defect for a number of hours. What could happen after a few hours to cause this behavioral change? Republishing to the same IIS site does not fix the issue for a few hours like publishing to a new IIS site does.
I have removed the button code from this posting because it is in my opinion a red herring as the code doesn't appear to be being executed at all.
This is what the cookies looked like in the network tools when the site is working
The difference here from when the site is working to when it is not working is that the Form1 key is marked as Sent and not Received.
Something new I have also noticed is that when the site is not working the favicon shows as (aborted). I now believe that the request is being completely aborted because I have overriden the page's OnInit and the code I entered is not being executed when the site is not working.
Today my work opened a ticket with Microsoft to help get this problem resolved and they have said it was a "head scratcher."
I disagree with Nick's thought that there is a problem in the code because of your assertion:
This only effects our production server. The same code published to two other servers do not exhibit this defect. This code has worked for years until recently.
This suggests there is a difference between servers, the way they are configured or the code is deployed that is stopping it from working. As it is a forms authentication problem, I am reminded of the bug that screwed up forms authentication in IE10 - see IE10 User-Agent causes ASP.Net to not send back Set-Cookie (IE10 not setting cookies)
Are your servers identical? Running the same OS, .NET versions, patches, hotfixes etc?
Microsoft saved the day.
They told us that the older versions of IE will look for the favicon in the root folder in IIS and not the application path regardless of where you're pointing it to look. There we found that the root folder's authentication settings were set to Windows Authentication only. For whatever reason this was causing the forms authentication to be aborted until we added Allow Anonymous to the root folder.

asp.net page does not displaying after publishing on production environment

I have developed a website in asp.net. It has a menu control.
It is working fine in development environment but not in the production environment.
I have link on menu control to the page called connect.aspx. When I click on this link it's redirected to
http://websitename.com/ErrorPage.htm?aspxerrorpath=/connect.aspx
where as it should be redirected to the below link
http://websitename.com/connect.aspx**
I searched on google but does not getting exact reason behind it.
Please help...

Navigation is not working on aspx page

I am developing a web app in asp.net web forms with master page. Application is running in debug mode in my localhost. When I click on the link in menu it navigates but when I again click on any link in menu it gives me the resource cannot be found.
The problem is a location issue. Make sure you are calling the file in the right directory.
If you are Redirecting from the Server-Side then use
Response.Redirect("~/MyFolder/MyPage.aspx");
or from the Client-Side
href="../MyFolder/MyPage.aspx"
This is assuming that you have the MasterPage in its own folder in the project.
u should try giving the links using ResolveClientUrl,I had the same problem..!!
<a href='<%=ResolveClientUrl("~/Folder/Page.aspx") %>'>LinkName</a>

silverlight with forms authentification - redirect to login.aspx

I've got a Silverlight Application which uses forms authentication. I tried to deploy and run it on my new Test-Server but its really weird.
I activated anonymous and forms authentication.
When I run [serverip] I get redirected to Login.aspx (which doesn't exists) and I don't know why.
When I run [serverip]/Default.aspx I get a blank white page. Fiddler shows me, that the Default.aspx page gets loaded, but getting the embedded Silverlight xap File results in a redirect through to Login.aspx.
Does someone have any idea what I'm doing wrong?
I deployed the application via file system. Unfortunately the user "everyone" had no access to the ClientBin-folder. Giving "everyone" access to this folder solved my problem.

How to deploy an MVC application on IIS 7?

I have a MVC application and I can't get it working on IIS 7. Debugging in VS2010 works fine, but when I publish the website to my local IIS7, I see nothing but blank pages.
Here is what I have done:
On the project, right click and click Publish. In the Publish Web window I set these settings:
Publish method: Web deploy
Service URL: localhost
Site/application: Default Web Sit\Africa
both, Mark as IIS application on destination and Leave extra files on destination (do not delete are checked.
In IIS, my application runs under a application pool with supports .net 4.0 and managed pipeline is set to integrated.
I don't get any error while publishing, but when I navigate to my site I only see blank pages. Nothing happens.
What goes wrong?
EDIT:
When I navigate to http://localhost/Africa/ I see a blank page. When I navigate to http://localhost/Africa/Views/Home/ I get a 500 error.
How can I solve this?
I ran in to the same exact problem, it took quite a bit of digging to solve.
I finally found the solution to it on this page: Getting an ASP.MVC2/VS2010 application to work in IIS 7.5
Yeah, I know that this is an old thread but for the sake of saving someone else's time I'm adding this. Also make sure you have HTTP Errors, HTTP Redirection, and Static Content enabled in IIS.
In your application pool advanced settings, make sure you have Enable 32-bit applications set to true.
Some other things to try:
Change the application pool to classic.
Make sure you have the correct version of MVC installed on your server.
If you are getting 500 errors, you can turn on Failed Request Tracing and check the logs. If you are getting 500 errors and no logs are being created, you need to check your web.config.
Blank page normally doesn't necessary mean it's not working, if you default page doesn't have anything, it will be blank.
If you run into some error, you normally will see an error page.

Categories