When developing WebForms web site, I start my project once, Cassini loads and stays loaded until I kill it. Therefore, when I change something (it recompiles in background), and refresh in browser is all it takes to see the changes.
But with MVC, I have to start debugging every time because Cassini is not responding to requests if debugging is not running.
Is it possible to get the same Cassini behavior in MVC as in WebForms?
It isn't usual for this behaviour, even when developing MVC websites. I am able to make changes to non-compiled stuff (aspx,ascx) etc and it'll take effect immediately on refresh. Changing classes will require you to stop debugging so that you can re-compile, and allow breakpoints to work correctly.
Also, whilst isn't strictly an answer to your question, you should strongly consider moving away from the baked-in Cassini web server used when debugging.
For more information on my general hatred of Cassini, please read this previous question.
If you're unable to either install IIS on your machine (because it might be XP Home or whatever), then you should consider either upgrading to XP Professional (where you are limited to running one website only), or Windows Vista, or Windows 7 RC where you can use IIS7 and all the greatness that it provides.
If you can't do any of those, you should consider trying an alternative, such as Ultidev.
I think I found the solution - the trick is to Run project wihout debugging. There is no item for it in Build menu, but keyboard shortcut works (Ctrl+F5 in Visual Basic keyboard scheme).
Cassini starts and remains responsive regardless of debug mode.
Related
I have a simple MVC Web application in the .NET Framework. To run it, I can click the green arrow ("play" button) in Visual Studio, which does a "build" and starts a Web browser pointing to the application.
Or, I can just start up IIS Express with the proper command line options, and navigate to localhost:8080 in a browser and run the application without a "build".
What is the purpose of "building" the application in Visual Studio if it runs fine without it?
The simple answer is that it doesn't run without the build step; your assumptions are wrong.
However, Visual Studio continuously monitors your source files and compiles them, e.g. to be able to show intellisense suggestions and compiler errors while you type. This means that there are in fact compiled binaries based on your source somewhere, maybe just not in the bin folder under your project root (that somewhere might be in memory, or in some cache location on disk, depending on circumstances out of scope for this question).
It's also very likely that you've previously built your application, resulting in binaries in your bin folder, even if you didn't do it with the purpose of running the application right after. In either case, if you get it working with IIS Express it's because it can find compiled binaries somewhere, and run those.
The main reason to have Visual Studio explicitly rebuild your app when you hit play, is to make sure that you're running the latest version of your code. Sure, it takes a few extra seconds every time you start the debugger, but it's nothing compared to the time you'd lose trying to track down a bug that you've already fixed in your code, but which still manifests in the running application, because the running application is an outdated version. (It also makes things like stepping through the code much less confusing, since, again, the source code on file will always be in sync with the running application.)
Short version:
When I debug ASP.NET MVC apps in VS2013 and try to edit razor views or css files, the CPU usage of devenv.exe skyrockets to the point where VS becomes unresponsive. Browser link is turned off, yet this still happens. Restarting debugging doesn't help, restarting VS doesn't help, restarting windows helps only for a short while, before the problem shows up again. How do I fix this?
Long version:
I'm having some trouble with Visual Studio 2013. Namely, after I start debugging an ASP.NET MVC app devenv.exe starts hogging CPU (to the point where Visual Studio becomes unresponsive). Some time ago this was happening only from time to time, but now it happens nearly always.
At first I thought that it was a problem with Browser Link, but the problem didn't go away after I turned it off and closing the browser while debugging doesn't have any effect.
Stopping debugging makes it stop hogging CPU, but it doesn't make the problem go away when I debug the app next time. Restarting VS doesn't help either and restarting Windows only helps for a little while.
The main clue here is that devenv.exe shows low CPU usage while VS window is not active. Switching to VS window makes devenv.exe use more CPU, but trying to do anything in VS (especially editing a razor view or css file) makes the CPU usage skyrocket.
Anyone got an idea what could be causing this problem and how to solve it?
Being unable to edit css and views while debugging is seriously lowering my productivity (the app takes good minute or two to start).
P.S. The app I'm working on right now is a nopcommerce based shop, but I had this problem before while debugging MVC apps that had nothing to do with nopcommerce.
I didn't manage to find the source of the problem, but closing all editor windows in VS seems to make it go away. If there are further lag spikes, restarting debugging might be also a good idea.
Since I didn't see this problem in a new project, it might be related to the sheer size of the solution, the number of files being opened in the editor at one time (though the problem remained even when I left one view open), the time those files where opened in the VS (I'm not entirely sure why this would be a problem, maybe it has something to do with the file history).
In order to add an asset to my ASP.NET MVC project in Visual Studio, I have to stop my debug server, add the file, and then restart the server. However, once Visual Studio is aware of the file (an image, say), I can change its content using an external app and the debug server will serve up the changes just fine. The same thing applies to renaming files (i.e., you can't while the server is running). When working on a large content-driven site, this gets rather tedious and unproductive.
I presume this has to do with the way that files are packaged up into an assembly in MVC for deployment (by contrast to Rails or local static site generators, where the files are just served off of the file system), so it's understandable. But I'm wondering if there any way around this limitation that would make local site development less cumbersome.
You can start it without debugging using ctrl + F5
This will run the code without the debugger attached, which is how code will run in production. This will also have performance benefits. If you never need the debugger you can even put your project in release mode (instead of debug mode) for even better performance.
When I run my mvc application using Visual Studio 2012 on Chrome, my page takes 36s to render - saw this using mini-profiler. When I host the project on a remote server and hit the server for the page, then it takes 36s on the first hit. But on subsequent hits, it dramatically reduces to 1s or less. Any thoughts on why this might be? On the remote server, when we restart the application pool, we are seeing it take 36s.
So question is, is it taking that long because of IIS allocating resources to the site or is there something else wrong with our setup? Our development time is really taking a hit with the amount of time that it takes each time we have to debug our project. Build and then takes 36s each time to render the page we are debugging.
When you say "run", I'm assuming you meaning debug. Debug rebuilds the project and then once it loads the browser, all the standard initialization for a first time load must be done each time. The fact that it takes the same amount of time (36s) as the application pool spin-up on your server seems to bear this out.
FWIW, you only need to debug your project once per Visual Studio session to have IIS Express fire up. Afterwards, you can simply rebuild your project and refresh the browser directly after (without using debug in Visual Studio) to test your changes. And, you only need to rebuild if you made changes to any *.cs files. Razor views, web.config, etc. will reflect their changes on next page load without a rebuild. The only thing you lose doing it this way is the debug ability, obviously enough. You'll just get a standard yellow page of death instead of automatically jumping to the offending bit of code in Visual Studio. But, I've found that unless I actually need to debug, this method is much quicker to develop with.
A few possibilities come to mind:
View Compilation
By default when you work on your project in Visual Studio, the views are compiled on-demand. While 36 sec seems like a very long time to compile the view for the first page, this could be a contributing factor. If your page changes, it has to be re-compiled. To eliminate this as a factor when performing measurements, you can edit your .csproj file with a text editor and change the line
<MvcBuildViews>false</MvcBuildViews>
to
<MvcBuildViews>true</MvcBuildViews>
(this can also be a useful setting in general).
Other Initialization Overhead
If you are doing much initialization when your app starts (perhaps pre-loading some data from a file or database), that initialization must happen every time the web server starts or the app domain recycles. In Visual Studio, I find that the web server can restart at surprising (to me) times. Add some logging to see if you're running startup code during a particular benchmark run, and see how much overhead that is.
Entity Framework
For some reason, Entity Framework runs much slower when debugging. If you're doing a lot of data access through EF, that could account for some of the difference.
I have been working with Watin for about 1 week. I really wanted to make firefox work but had to give up after a day or so when seeing there was no way i could get jSSH working with Firefox 8 etc. Really wish there was a way of using Chrome or firefox i have to say
So returning reluctantly to IE I developed some automation software using Watin, however I have a persistent problem with Goto(href) where it seems as though the page never actually gets marked as complete. And although the browser navigates to the page and I can see the page fine, the call to Goto() just times out. After that point anything I try fails and it cant find the elements in the dom and I cant click anything programmatically. So I have to solve this timeout issue
I have read various articles suggesting fixes and have tried them all as far as I can see i.e. making sure I run as administrator, making sure that internet explorer enhanced security is switched off, etc.. I would really, really like to make Watin work - but right now I am about ready to give up and create a much, much simpler class with an embedded browser in my app. So stackoverflow is my last port of call. How can I stop Watin from timing out.
I am on Windows 7 Ultimate Version 6.1.7601 Service pack 1 build 7601
Visual Studio 2010
compiling as a .net 4.0 app
IE 9.0.8112.16421 with update KB2586448
I have a console app, no threads, [STAThread] on my Main entry point
This is my Visual Studio info:-
Microsoft Visual Studio 2010 Version 10.0.40219.1 SP1Rel
Microsoft .NET Framework Version 4.0.30319 SP1Rel
Microsoft Visual C# 2010 01021-532-2002102-70185
Any help will be very greatfully received.
Regards Julian
ok, so after many months of playing and fiddling the answer to my question has several parts.
Firstly. I needed to get Watin working properly as an embedded browser in a win32 application rather than as a console app. This required me to spend a huge amount of effort getting Watin embedded the way I wanted, I had problems with STATHREAD (of course), and the pop up dialog watcher, and getting the HWND of my browser into Watin to create its browser object (I used another sample on stack overflow to do this) and then I had to ensure ScriptErrorsSuppressed=true and I finally got it working. Hoorah
However, the problem I originally had all that time ago still seems to remain with Watin.2.1.0.1196 in dealing with frame sets on asda.com.
So I have just now done a svn checkout of the watin project and I am finally hoping that the latest updates I have seen will fix this problem once and for all... and Yes I am still really looking forward to Jeroen getting IE9 or indeed any other browser working with Watin. Working with IE (any flavour) sucks
WaTiN does not support IE9 fully yet as far as I know. Jeroen (the creator) is working on getting it fully compatible with IE9, but IE9 relies on new WPF components in regards to previous versions of IE, so i'm guessing this will take some work.
We suffered from several problems as well when we upgraded our WatiN tests to IE9. In the end we force our website to render everything to IE8 standards and set IE9 to IE8 rendering mode untill there is an update from watin to fully support IE9 with all its quirkcs and features.