Every now and then when I am running/debugging an ASP.NET MVC website through Visual Studio and if I am changing some CSS or HTML in a View while the project is still running, the Session will drop intermittently.
I have confirmed this in the Global.asax adding a Session_End method and setting a break point inside it. As soon as I click Save All through Visual Studio after about 10 or so minutes Session_End is called. I don't even have to refresh the actual page which I think is a little bizarre...
I realize that recompiling the app would cause the session to be lost, but I would not think modifying a View while the application is running would cause this.
Any thoughts on why this could possibly be happening?
Since you are clicking Save All, is it possible that you've also modified a code file or the web.config as well. Any sort of change -- even if you removed it -- would make the file dirty and cause it to be saved as well. This may cause the behavior you are talking about.
You might want to think about using SQL for session state in your development environment. I recently switched to this (because I needed to for our production environment) and no longer see that sort of behavior even when I stop debugging and recompile the application. As long as the session cookie is still valid, it is able to pull my session information from the database.
Related
I'm working on a fairly large ASP.NET web application and I'm taking a big productivity hit when I do work in the interface. I can zip through adding features to the database and API, then I hit the interface and having to recompile and run eats up a lot of my day.
For example if i'm working on a tricky bit that isn't behaving quite right and requires a number of tweaks I'll have to go through multiple [stop/tweak/build/run/log in/navigate back to page] cycles, which really kills my flow and has me staring at the screen with my finger hovering over the hackernews bookmark each time.
I've been fiddling with ways to get around this problem but I haven't improved my situation much. Here's what I've found so far:
visual studio will restart the app frequently when you change static files (js/css/etc), which shouldn't require a restart. If you run VS with IIS express instead this problem goes away.
If I know I have a bunch of messing around to do i'll cut/paste my code into a server script tag on the markup page, run the product, and tweak until it's good, then cut/paste it back. This is annoying because it often requires setting up a number of Imports page declarations and code editing features in ASP.NET files, while better than ever in VS2010, is not as good as in C# files. Plus, it still restarts the app occasionally once enough changes are made.
I can exclude the codebehind file from the web application project, change the "codebehind" attribute in the aspx page declaration to an "src" attribute, then edit the code from there while the app runs (until i make enough changes to trigger a restart.) However now intellisense doesn't work in the codebehind, among other things.
Am I missing something blindingly obvious here, or is development in ASP.NET web applications really supposed to be this slow? Thanks for any solutions you can offer.
I never run my applications through Visual Studio. Set yourself up with IIS and then configure a site to point to the location of your application along with a faux domain. Edit your hosts file to point the domain to localhost.
Then when you want to view your site, just visit the domain that you chose. If you need to modify CSS or script, just make your changes and refresh the page. If you make a code change, compile your app and then refresh the page.
If you need to actually use the Visual Studio debugger, then just attach to the IIS process (application pool name) and your breakpoints will get hit.
I've found a combination of techniques that brings my productivity up a fair bit.
Use an alternative browser like Chrome. When you stop the VS debugger and you're using IE, VS will shut down the browser, but it won't do it with Chrome (or Firefox, or anything else.)
Switched web.config to run in Windows Authentication mode and wrote a quick transparent login routine enclosed in conditional compilation tags (debug only, this feature is not perfect for our production product.)
Now when I'm getting into it I can stop the debugger (which no longer closes the browser,) make code changes, build, optionally start the debugger again, and just hit F5 in Chrome to load the latest. The refresh obviously takes longer since the app has to start up but there's no "run browser/log in/navigate back to the page" task anymore.
Hopefully this will help somebody else in a similar situation.
I recently ran into some strange problems. Changes to files that are not code-behind (and not gets compiled to a DLL) should not require you to recompile the whole website, and this has never been I problem for me. These should actually get compiled dynamically when you first access the resource, e.g. the first time when browsing an updated aspx-page in the browser.
But yesterday, during development of a website, I noticed that even the smallest changes in html, javascript or anything in the .aspx-files doesn't get reflected when I save and reload the page in my browser. Rebuilding doesn't help either, actually I'll have to do a "Rebuild All" (in Visual Studio 2008) in order to see the changes. This applies to all aspx-files in my project.
I tried with minor changes on files in another web application project on the same server, and there it works as it should. Something must has happened to this particular application, but I cannot figure out what.
Do you have any ideas on how to solve this?
Best regards
Not sure if this was the solution, but I noticed that I was running out of disk space. After some cleanup it started working again...
What is the best way to add into the build/compile script of an Asp.net project to initiate a IIS to restart the website on DLL rebuild instead of the first request to the site.
Current Process
Compile Project
Wait
Hit APSX Page
IIS starts reload
Wait
Page loads
Ideal process:
Compile Project & Reload IIS
Wait
Hit APSX Page
Page loads
The first way I though of was add a request to just hit one of the pages in the "Post-Build events". Just wondering best practices. This would be similar to "Start" which opens a page immediately on build.
Update:
The reason I would like to accomplish this is for just for efficiency. I would the to encapsulate the compile time and the restart time into one batch to save on time on step 4 below
VS: ctrl+shift+b
Wait for visual que "Build succeeded".
Broswer: F5.
Wait for IIS reload. (as well as Hit kbd>F5 in unanswered questions in SO)
Test page
Add ‘iisreset /stop’ into the Pre-Build event and ‘iisreset /restart’ at the end of the Post-Build event.
As David mentioned, you should try to find out what the underlying issue is here. If you are experiencing performance issues when first loading a website, this is quite normal. The initial compilation often takes some time to occur. Resetting IIS is only going to make it take longer. If there is another issue, please post your reason for doing this here, and we can see if we can help you.
A naive way would be to write a shell vb script or PowerShell script to use XmlHttpRequest to request a page from the site, and include that as a post-build task.
Is there any particular reason you feel the need to do this? If you're experiencing performance issues at the first JIT then you may need to consider breaking up your application into smaller projects/DLLs (assuming that size is the issue), or start looking at bottlenecks that occur when your app starts.
Another question: why the IIS reset? That won't cause the DLL to be recompiled until the first page request. Unlike classic ASP, it isn't necessary to restart IIS for DLL changes to be allowed/take effect.
The "wait" you are hoping to remove from the process is most likely the aspx markup pages compiling. When you build in VS by default it will compile all your code, but it will not compile your markup aspx pages. You can get round this by adding a Web Deployment Project to your solution, which allows you to precompile the markup pages. This way the initial load time after deployment should not be very much different to any other load time.
I have three Silverlight 3 applications in the same solution. In my asp.net hosting project I have a seperate page for all three projects. When I navigate between the pages, the only Silverlight breakpoints that get hit are the ones the initial page I load.
This problem has only started recently. I used to be able to debug between all silverlight projects at the same time. Any ideas? I have deleted the ClientBin folder, I have deleted all files and re-retrieved from source control. Nothing seems to be working.
"The problem has only started recently". What changed? Here are some guesses:-
You upgraded to Windows 7
You installed some more memory
Some other memory guzzling app is no longer running when you are testing.
By default IE8 will run multiple processes at least 2. One for the browser frame and one for the content of the intial tab. As you open more windows and tabs IE may add new processes to the set it is currently using.
When you debug VS will launch an new IE8 session and will attach to the process handling the content of the single tab that is open, (it doesn't bother attaching to the parent frame process). However as you navigate about your application IE8 will start new process that VS won't be attached to. This forces you to open the Attach to Process dialog and do it manually.
You can control this IE8 feature (called BTW LCIE, Loosely Coupled IE) from the Registry.
In the Key HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main add a new DWORD value TabProcGrowth. Set its value to 1. Now IE8 will only ever create 2 processes per session one for the frame and one for all the tab and window contents which is the one the VS will attach to.
This perhaps is a bit draconian if you also use IE8 as your general browser. One option is to leave IE8 for test purposes and use another browser for general browsing. Another option is a variation of the above. Instead of creating TabProcGrowth as a DWORD create it as a string type instead and set is value to "small". In this mode IE8 is much less aggressive in the number of processes it will open. Of course you could create a couple of scripts to create and delete the registry entry.
Note without the registry entry IE8 uses its own hueristics that depends on available memory etc to determine if a new process is warrented or not. This might explain why in the past your debugging worked and that for apparently no reason it stopped working.
Here was the issue:
One of my child windows had a Silverlight that calling a .Net Ria Service. The service call ended in an error.
The next time several I debugged, the debugger did not attach to the child windows. I had to attach to the child windows manually.
I fixed the Ria Service call so that it did not end in an error. And had to manually attach to the child windows in that debugging session. However in subsequent debugging sessions, the debugger automatically attached.
I tried breaking the Ria Service call and I had to manually attache again. What is a little weird is that closing Visual Studio and even rebooting the machine does not make Visual Studio automatically attach again. You have to have a debugging session where the child window make a sucessful call to a Ria Service to fix it.
NOTE:
The RIA error that was breaking my debugger was caused by a misspelled include in the domain query (ie...
return Context.SOME_ENTITY.Include("Misspelled_Association_Property");
) not all RIA exceptions cause this problem.
My scenario has a number of specific cases that I will go over. I don't have all the things handy to test a more general scenario, but I will when I finish my project unless someone does this first.
Here is what I have:
I am using the a LinqToEntitiesDomainService from the July 2009 Preview release of .Net RIA Services.
To complicate things a little more, since my application is using an Oracle backend, I am using DevArt's dotConnect Entities provider as the EntityFramework model for my domain service.
When I get time, I will try this on the Nov 2009 RIA and a standard SQL backend and EF to see if I still have the same issue. If this is the case I will report it to Microsoft as a visual studio bug.
Trying to print an ASP.NET Charting control behind the scenes in my web app. I think it is a permissions issue with the printer as everything is ok up until the point where my code calls:
chart.Printing.Print(false);
bool finished = false;
while (!finished)
{
finished = File.Exists(settings.GetValue("statusfile")); // file which indicates document was printed
System.Threading.Thread.Sleep(1000);
}
At this point the page just freezes (or continues to load endlessly - infinite loop!) Understandably this is happening because I am 100% relying on the document being printed. I do intend to add a timeout, however, at the moment I am just trying to figure out why exactly the document is never being set to the printer!
I have given the account (which the AppPool is running under) permissions to all the relevant folders and even the pdf printer itself...Still nothing.
Am I missing something? Is there any issues with printing on the server side via ASP.NET? I have encountered some issues doing this via WindowsServices in the past not sure if it is a similar problem with ASP.NET websites.
Update
As suggested I updated the AppPool to give myself (admin) permissions and it is the same issue. So by the looks of things the job is never being sent to the printer. I can't seem to figure out why though...
Probably should have mentioned this in my original post....but I am invoking the printer through a referenced DLL, this code is not being called directly from my application (incase it matters). Also this runs fine on my Development machine which is running Windows 7 IIS7.0 where as the server is running Windows 2003 server with IIS6.0.
Update 2
I removed the while loop and just left in the chart.Printing.Print(false) line and turns out the document IS being sent to the printer. So the issue must be with the settings file not getting written which is why the loop never breaks out!
To isolate if this is indeed a permissions issue, you could try running the application using the Visual Studio web development server, which will run under your credentials. Or if that's not an option, temporarily change the IIS app pool so it uses your credentials. If things still do not work, you may have another issue. I'm not sure which charting library you're using (is it the newish Microsoft one?), but maybe Print wants to show a printer dialog.