i have an asp.net 2.0 site which is compiled and has been put in the IIS virtual directory
however the new changes cant be seen by some users, and some other users can see the new changes on the web site, i have tried deleting cache and cleaning internet settings and trying with mozilla and chrome and still cant see the new changes.
we also tried cleaning the connection pool on iis.
is there anything more i can possibly do?
Have you confirmed that the machines are hitting the right server? Ping the URL from the "bad" machines and see what it resolves to.
The javascript changes may need browsers to download newer script which was published. (Cached javascript might be older)
For session based changes, if users retained older session, the changes may not reflect until they restart the session.
I found the answer, the server was being split in two machines, and when the server admin updated files only did in one of the servers, not both, now both are updated and running ok, thanks every one for the suggestions.
Two things to try (if Bill Gregg's suggestion doesn't work):
1) Bounce the web server services.
2) Download a freeware app called CCLEANER (formerly called Crap Cleaner....it was seriously called that). This app (when configured correctly) will clean all the junk web files off client machines.
Related
After moving all my solutions over to a newly installed machine (which makes me think this is a config issue), I am now having this problem with my MVC 5 web application(s).
When I build my web application (VS 2013), this of course regenerates all the web code and IIS will restart the application on next page load. However now it seems, when I go to my start/login page, the Application_Start() fires as expected, but when the page is submitted, before the HttpPost method is reached, the entire application seems to start again (Application_Start runs again). This second start seems to occur before the first Application_End() is called...but regardless of the sequence I have no idea why this is now an issue.
Checking the application shutdown reason in Application_End() I get the notorious vague (and apparently completely undocumented) "BuildManagerChange"...which MSDN gives some ridiculously vague description of.
Does anybody have idea why this would start after loading my development environment onto a new machine. Both machines are Win7 Pro running IIS7.5, and I believe the IIS config is identical to the old one (though, apparently not??). The source code/web.config/etc has not changed between machines.
The only documentation I could find on this issue was in regards to using IISExpress, however I am using the standard IIS7.5 installed with Win7 pro.
Edit: After removing all custom code from the entire startup of the site, and reverting my LoginController back to it's original simple form (no custom code), this still occurs.
Well, wasting 2 days on this was fun! But, this was resolved. Running procmon showed that hash.web was being accessed by mcshield.exe (McAfee AV). Apparently the live "on access scanner" checks the asp.net cache, and somehow IIS is aware of this and thinks it needs to rebuild the site again. For some reason McAfee does not check it after this first time so it functions normally after a second build/restart. I added a scanner exclusion to the c:\Windows\Microsoft.NET folder, and that seems to have solved the issue. –
A bit late to the party, but maybe it'll help someone. For me it was because I accidentally mapped two IIS sites to one directory. This resulted in two IIS background worker tasks and Application Application_Start() being called twice even though the second site was marked as "Stopped" in IIS.
We have built a WebDav Service with your Engine and have a one problem when we create a new Folder or File:
The new folder / file is created successfully, but not showing in the Windows Explorer. Only if you press F5, the new folder / file is showing (and the name is already selected to be edited).
This behavior is reproducible even with a blank WebDav Solution.
We can reproduce this on Windows 7 and Windows 8 (8.1) using WebDav .NET Server 3.8 and the latest 3.9.
Is there a way to get around this “refresh-problem”?
I solved this issue but clicking in the folder explorer at view > options > then i restored to default and everything is back to normal.
I assume this issue is in Windows Explorer on a single computer. Most likely the WebDAV server-side code is failing with with some exception. Here are some ideas how to detect what is wrong:
Unmount network connections executing 'net use * /DELETE' in a command prompt, this will unmount WebDAV connections too and simulate 'clean' environment.
Retry reproducing the issue and examine your WebDAV logfile. By default it is located in /App_Data/WebDAV/Logs/ folder. Are there any exceptions in it?
Use Fiddler tool or any other debugging proxy to capture and examine HTTP requests. Are there any failed requests?
In case you are creating a folder/file on one computer using Windows Explorer (Microsoft Mini-redirector driver) or IT Hit Ajax File Browser and expect the files list to refresh automatically on another computer this would not work. Mini-redirector does not support any notifications from server and WebDAV does not submit any notifications, you need to refresh the files list manually to see the new items created.
I found this video on Youtube that explains in very much detail how to fix this problem: https://www.youtube.com/watch?v=UUiCPsQquqc
It is a bit lengthy, so I'll just quickly sum it up here:
The reason for these problems are one or more (broken) Shell Extensions that prevent the refresh of the Windows Explorer
To fix it, open up regedit.exe (requires admin privileges), do a search for the Registry Key "DontRefresh". If it is "1", set it to "0". There might be multiple matches for that Key, so repeat until all Keys have the value "0".
This might not work immediately, you may have to kill and restart your explorer.exe process (easiest to do with the Task Manager). Or you can simply reboot your computer. In my case, it worked immediately.
According to the video, the Keys should only be located under HKEY_CLASSES_ROOT/CLSID, but in my case I could only find such Keys in HKEY_LOCAL_MACHINE/Classes/Wow6432Node/CLSID.
I figured it makes most sense to simply search the complete Registry, it does not take very long.
I tred a lot of hacks, from scanning the system, to recreating the profile to hacking Registry keys and hives.
Finally what worked for me -
Right click on desktop
Select Personalize
Click Themes
Click Change desktop icons
Click Restore default & OK
And instantly it began to auto refresh with a new folder, rename, delete, copy, etc.
It may be a silly question but why one would like to attach debugger to IIS instance?
These SOs
Attach Debugger to IIS instance
How do I attach the debugger to IIS instead of ASP.NET Development Server?
show you how to do it but could you let me know what are the benefits of doing this?
One time, in my entire career, we had a web app that started getting strange errors that had us baffled. We tried a dozen things to try and figure out what was wrong, but we were panicking and needed an answer immediately. So, we attached a debugger to the production instance and set up a few watch/break points. It helped us track down the errors and fix the problem.
Naturally, it hung the server during our debugging session, and made people mad, but no more mad than they already were, because of the problem we had.
It would not have been necessary if the code had been written better, with error logging and diagnostic points. I don't expect to ever do it again.
Apart from TimG's post a couple of reasons I can think of are:
To debug the application in a closer representation of its
production environment
To debug on a remote machine
Example, like #TonE #1 -- in order to test a deployed website (with web.config transformations) locally, like if you can't remote debug a live website or just need to test config transforms (since you can't run them in-place):
Open site project from C:\Dev\AwesomeWebSite\AwesomeWebSite.sln
Publish the site to a local folder C:\Webs in Release mode (or Whatever mode)
Set up a local IIS website pointing at the published project
Do stuff on the locally-deployed version (e.g. browse pages, make webservice calls, etc)
Attach VS to w3p.exe (appropriate instance) in order to debug the deployed version
You might be able to effectively do the same thing by instead pointing the Project at your IIS website per this answer.
Bit of a weird one. For some reason one of my DNN modules keeps being converted into an Application in IIS7 in my development environment. Meaning when I try to view a page that contains that module it can't find the module correctly. It's ok if I go into IIS and delete the application, then restart the site but is a bit of a pain and am little worried it might do this when uploaded to the live server and disable the whole site.
Anyone encountered anything like this before? Any thoughts?
This is a common problem with my VS templates, though not for everyone, and it doesn't happen all the time. It stems from Visual Studio, so it shouldn't ever be a problem on your production servers, unless you upload source and try to compile there, than it might be an issue.
HuwD,
A good resource might be my module template installation video which gives good information on setting up your development environment and debugging issues (regardless of the template you use). Check out between 1:30 and 5:00 minutes for the environment setup, and after 19 minutes some of the troubleshooting.
A couple common problems I see Visual Studio doing is creating an unwanted virtual directory on the DesktopModules folder and/or creating an unwanted web.config in the module's root.
Another good resource is Dnnhero.com. In the development section there is a series on DNN7 environment and template setup.
You may want to give a try a free module called Users Importer - A bit old but worth a try.
Here is a paid alternative: Bulk User Manager
We recently migrated from VS 2008 to VS 2010. The migration went fine, except for our web project. Before, in VS 2008, the site showed up as http://localhost/Website. Now, it appears as C:...\Website. It appears that when we did the migration, VS started to treat it as a file system website.
I've tried removing the existing site and re-adding it as an existing website, but it still displays it as C:...\Website. Is there any way to convert it back to show it as a http://localhost/website, and run through IIS, as opposed to the default ASP.NET Development Server?
Special thanks to John Dundon at Microsoft for helping me resolve the issue. Here's what he said:
Thanks for all the details. This actually sounds like a quirky behavior
in VS that I think I can help you work
around.
I believe the reason it’s remembering
to use the local development server is
because it got stored in the SUO file.
So there are two possible ways to fix
this:
Re-open your solution from source control as an administrator on the
machine with IIS installed and
everything should get downloaded to
its right place
If you close VS, delete the SUO file (note – this will erase some
settings about the state of your
solution but shouldn’t cause any real
data loss), and then re-open the
solution, it should ask you to
re-download that particular web site
and will try to make it an IIS web
site again.
Note however though that since your
virtual directory already exists on
your machine, it’s going to ask you if
you want to use it – I’m assuming you
do, but it will overwrite any files
when it does.
Let me know if this works for you (and
while you technically shouldn’t need
to, it may be a good idea to back up
any work you’ve done in this
enlistment that hasn’t been checked in
prior to trying this).
I followed his advice and removed my SUO file and re-opened the solution. The website was automatically fixed as http://localhost/Website and it also checked out the .SLN file as well, and when I checked it in, it fixed the issue for other developers as well. Hope this solution helps out others as well with this quirky issue.
Look in the project properties, on the Web tab. You'll be able to select whether to use IIS or the development server, and which virtual directory to use.