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.)
Related
When learning about .NET Core, I heard that it would be possible to edit .CS code while debugging (e.g. controllers). Now that we're at .NET Core 2, I still can't find a way to get this to work.
This all stems from working with PHP/JavaScript developers who absolutely hate, with reason, the lack of editing while debugging. You have to stop the app, edit the code, run, wait for build, and then see it. I get it's because of the compilation, but I thought they were changing something in .NET Core and VS 2017. This even goes down to stupid things like adding images to your project.
Any ideas on how to enable some of this?
The answer is yes and no.
There are "watchers" in .NET Core that means your code is constantly recompiled as you make changes. To do this you just add this nuget package :
Install-Package Microsoft.DotNet.Watcher.Tools
And then run the watch command from your command line tool :
dotnet watch run
But again, this is simply recompiling your code as fast as possible so that when you refresh in your browser, the live changes are there. It's similar to other watches in things like Gulp etc.
It's possible to "attach" the debugger to your running instance, but as soon as your code is recompiled you need to reattach the debugger. If you are looking to be able to use breakpoints while using watchers for example, I don't think it's possible.
More info :
https://dotnetcoretutorials.com/2017/01/31/live-coding-net-core-using-dotnet-watch/
https://learn.microsoft.com/en-us/aspnet/core/tutorials/dotnet-watch
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 build my app, I just get a single bin folder, with all files in it, versus the usual bin\debug and bin\release folders. Why is this?
Because the website can be run by IIS ( and the various flavours of... ) in the location you built.
IIS expects the assemblies in the bin folder ( it's hard wired in the AppDomain setup ) so the web project type compile to this location.
For an interview, i was put across with this question. One of the link could be this which answers in brief .
The above link will give you the statement as below:-
Release Mode
When an assembly is built in release mode, the compiler performs all
available optimisations to ensure that the outputted executables and
libraries execute as efficiently as possible. This mode should be used
for completed and tested software that is to be released to end-users.
The drawback of release mode is that whilst the generated code is
usually faster and smaller, it is not accessible to debugging tools.
Debug Mode
Debug mode is used whilst developing software. When an assembly is
compiled in debug mode, additional symbolic information is embedded
and the code is not optimised. This means that the output of the
compiler is generally larger, slower and less efficient. However, a
debugger can be attached to the running program to allow the code to
be stepped through whilst monitoring the values of internal variables.
[Update] After little google i came across similar question- "Confused about Release/Debug folders in Visual Studio 2010" with same answer which i have quoted above.
Also, please look into why-have-separate-debug-and-release-folders-in-visual-studio. #riko and other members of Stackoverflow have answered quiet well..
This behavior is not specific to MVC4. In fact it is consistent with so-called "classic" ASP.Net, both Web Site projects and Web Applications.
The distinction between release and debug modes in ASP.Net is that Release builds need to be Published.
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'm developing an ASP.NET MVC (still v2) Azure web application. I've run into a problem that seems to require me to step through the MVC code itself. I can do this but also need to be able to inspect the code as I step, so I need to be an unoptimized version (so as to not get the "Cannot obtain value of local or argument ...") message in the debugger.
The standard way of circumventing the optimizations (http://blogs.msdn.com/b/sburke/archive/2008/01/29/how-to-disable-optimizations-when-debugging-reference-source.aspx) doesn't seem applicable to running in the Compute Emulator.
I also tried this by creating a local debug build of the System.Web.Mvc project but my web role hangs when I try to start it in the Compute Emulator.
So ... Any help with either of the following would be much appreciated:
Running an Azure web app in Visual Studio (2010) so that it will ignore code optimizations in system dlls.
OR
Creating a local system debug build so that it can be referenced by an Azure web app being debugged in the Compute Emulator.
If the Azure Compute Emulator is giving you issues you could run your MVC project using IIS Express. Just right click and and Select Debug/Start New Instance.
I was finally able to get unoptimized ASP.NET code while debugging in the compute emulator. The basic approach described on MSDN (http://msdn.microsoft.com/en-us/library/9dd8z24x%28v=vs.100%29.aspx) and elsewhere (http://martin.bz/blog/asp-net-mvc-source-debugging-the-easy-way among others) is to put an .ini file that tells the JIT compiler not to optimize in the same directory as the DLL.
The first challenge was to determine just where that was; it finally dawned on me to watch the logs in the Compute Emulator UI and see where they loaded the DLL (in this case System.Web.Mvc) from.
The second challenge was getting the .ini file there. Windows Explorer didn't work because it uses a different way of viewing assembly caches that doesn't give you direct access to the files. One of the posts I read reminded me that using the Command Prompt might give me that access and it did. The last step was realizing, when the Command Prompt wouldn't permit me to move the .ini file into the assembly directory, that I needed to run Command Prompt as admin.
Once I could view variables while debugging, I pretty quickly realized where my bug was.