I'm developing a MVC 4 website on IIS7.5 and have run across a strange issue that I cannot find a solution for. When I edit or delete a controller, the website doesn't recognize the change and seems to be using a stored version somewhere. I have disabled output cache and kernel cache on the server and added measures to prevent client side cacheing to no avail. This is a really bizarre problem that I haven't been able to find a solution for anywhere. Editing or deleting the controller affects my local machine but not the server!
Related
I have a project that is written in .NET Core 3.1 and Angular 7. I was hosting this project on a server until yesterday. I had to migrate this project to another server. After the migration, I started to have some issues. Whenever I change any SQL data, the Angular component is not refreshed and not displayed the current changes. However, testing it locally, it was fine and works as expected. But when I deployed to the new server, this problem happens.
Specifically, I have a form that I update the users. The update process is working as expected. Not receiving an error. But When I try to edit it again for test purposes, I see unedited data even though SQL database has the edited data.
I did research and found that this question has been asked here already. I followed all of the answers. The issue was not fixed. After that, I thought this could be an SSL issue because .NET Core 3.1 uses SSL for retrieving data. So I even downgraded to 2.1 but I still have the same issue.
The project is working fine with the old server and locally. But I have this issue with the new server after the deployment. I am not sure what to do after this point. Any help would be appreciated.
After a long research, a lot of debugging and modifications, I found out that (in my case) the issue is not related to .NET core nor Angular. The server has set up that is doing some caching for all sites that go through the proxies for increased performance. This certainly did cause the issue I have. Caching has been removed and everything started to work as expected.
I've inherited a Silverlight/WCF application. (Having worked on .net MVC, and SPA for quite a while)
I tried switching the IIS website folder to see if a tweak to the code and a fresh build would work, it didn't work and I switched back and although the website is functional it has a number of faults.
For some reason the Windows authentication appears to have stopped working, this authorises a number of the admin functions. I think this is broken and so not enabling the functionality in the Silverlight app.
The server I've inherited has the applications as folders in the default website, which is new to me, and quite constraining. I've gone through IISAdmin videos, and learnt a lot, but not enough to fix the issue.
I am unable to get the software to run in VS2013, quite a bump after working on Single Page Applications.
I'm stumped as to how the same code put back no longer works; I've learnt my lesson, but I still need to fix the system. I am not sure whether IISReset would make a difference since the AppPool is recycled every 29 hours. I've found out what the harm in trying is, and so I am proceeding with caution.
So my main goal would be to get the Windows Authentication working again.
We're developing a solution which uses Ektron. As part of our solution we all have local IIS instances (localhost) and deploy to this local instance as part of the development life cycle.
The problem is that after a deployment and once dll's are replaced IIS restarts and the app pool is recycled, this means that Ektron dll's need to reload themselves.
This process takes an extended amount of time.
Is there anyway to improve the loading time of "Ektron"
To some extent, this is the nature of a large app running as a website rather than a web application. Removing the workarea from your local environment is one way to get this compile time down, though this will naturally not work depending on your workflow, for example if you are not using a separate dev DB or if you are storing the workarea in source control.
I have seen some attempts to pre-complile the workarea and keep the working code in a separate project (http://dev.ektron.com/forum.aspx?g=posts&t=10996) but this approach will only speed up your builds, not the recompilation of individual pages that will occur after a build as a result of running as a web site.
The last (and least best-practice) solution is to simply avoid making code changes that cause a recompile, like modifying app_code. Apps running as websites are perfectly happy to recompile a single page's codebehind without regenerating DLLs, which is advantageous for productivity but ultimately discourages good practices like reusing code in libraries. Keep in mind that this is terrible advice, but if you have a deadline and are staring at an ektron page loading every 30 minutes it can be useful to know.
Same problem here. I found this: http://brianpereras.blogspot.com/2013/06/ektron-85-86-workarea-is-slow-compared.html
That says that the help documentation was moved to be retrieved from an online source (documentation.ektron.com). We're running Ektron 9, and I just made this change and it seems much faster on first load (after iisreset).
The solution is to set documentation.ektron.com to 127.0.0.1 in your hosts file.
There is not, this is just how IIS works. Instead of running a local instance of Ektron it's a good idea just to point your web.config file to the database of your test database and copy the /workarea folder to your local PC. You can't edit ektron locally but you can change the data on your test server and it will show up locally.
Recently I added a mobile version of the site using MVC4 .mobile views. I structured the site in a very similar way to the desktop version by starting from _Layout.mobile.cshtml which pointed to the correct scripts and css designed specifically for the mobile site.
After publishing the site I checked that everything worked correctly which it did just as how it was designed. But shortly I was told that the site was broken. When checking the mobile site I noticed that the _Layout.mobile.cshtml was loaded but instead of the Index.mobile.cshtml which is sent from the Home controller, what was returned instead was the standard Index.cshtml designed for desktop. The desktop Index file was also rendered using the mobile css which caused the whole mobile site to look very messed up. On a side note, no changes occurred to the desktop version of the site.
Republishing fixed the issue, but I also noticed that sometimes it reverts back to displaying the correct views without republishing even after it broke.
I began to research the issue and what I stumbled across discussions about Display Modes not working such as this:
ASP.NET MVC 4 Mobile Display Modes Stop Working
With a NuGet solution that read as deprecated: http://www.nuget.org/packages/Microsoft.AspNet.Mvc.FixedDisplayModes
I assumed that since this discussion was from a year ago talking about early releases it should be fixed by more recent MVC4 updates. My current version was 4.0.20710.0 so I updated to 4.0.30506 using NuGet before doing anything else.
This did not solve the issue but not only that, upon inspecting I noticed the reference System.Web.MVC was still pointing towards the 4.0.20710.0 version dll file.
I am worried about adding an unnecessary fix that is labeled deprecated and was hoping that the MVC update would resolve this issue. Any suggestions?
the package in your link is the package for the pre-release Asp.Net MVC 5. Indeed, they did solve the issue you are having in the Asp.Net MVC 5 package, but it is still pre-release with Visual Studio 2013. In the additional links on the page, there is a link for the non-beta, non-RC release that still applies to Asp.Net MVC 4 (FixedDisplayModes)
I have an ASP.net web app and on my test (database) server I have enabled sqlserver to store the viewstate and when I run the app from visual studio this works fine.
However when I try to host the app on the production machine (IIS 6) the viewstate is still present in each page request.
If I use the exact same connection settings against the production machine and run the web app from within visual studio the viewstate is not present.
This leads me to believe that theres either
1) Something I need to enable/disable in IIS
2) Something in my production web.config thats interfering.
If anyone can help me solve this problem it would be much appreciated.
Note Should add that I'm using Ironspeed to generate the pages. So there might be a configuration issue that ironspeed requires.
SOLVED It was an issue with Ironspeed which is a third party application for generating asp.net pages - a key was required in the web.config which was on my local machine but not in the production machine. Guess when you inherit another framework you also need to make sure you follow the framework requirements.
The first problem I see is with your question itself because 'session' and 'viewstate' are two entirely different things.
Viewstate will be there regardless what your session persistence mechanism is...
POST EDIT:
Good that you changed your question but there is not a native or built in method for persisting viewstate outside of the default behavior - which begs the question what method are you using?
Do you have <pages enableViewState="false" /> inside the system.web section of your web.config...? This should disable viewstate for all pages.
Make sure you understand the difference between Session and View State. They are similar, but separate concepts. You are storing your Session in SQLServer, but you still have View State enabled.
SOLVED It was an issue with Ironspeed which is a third party application for generating asp.net pages - a key was required in the web.config which was on my local machine but not in the production machine. Guess when you inherit another framework you also need to make sure you follow the framework requirements.