I have a big application which I develop (ASP.NET MVC), it wasn't initially mine and I received it from my client. When I run it via Visual Studio, it takes about 2-3 minutes to launch.
I'm wondering what is going on after pressing F5 button in VS (except copiling and copying dll's, views, content to output folder).
If I had to guess I'd say that you're compiling the cshtml code and that can be very slow in older versions of visual studio.
Check to see if you have
<MvcBuildViews>true</MvcBuildViews>
in your .csproj file.
see this answer
MVC Application is extremely slow to build
I believe every time you launch it from Visual Studio it creates new dll files, hence the waiting. But I could be wrong.
Related
I have an ASP.Net Core MVC simple project. When I start it without debugging (Ctrl + F5) and change any .cs File (Controller, for example), save it, and update the page in browser nothing happens. But it should automatically recompile and show changes, that was said in the book that I read.
Why can this happen?
I use Visual Studio 2019, .Net core 2.1.
If I manually close the page, and press start without debugging again it recompile and show changes in browser.
If I change .cshtml files (View) it takes effect as soon as I update the browser Page. So it is problem only with C# classes.
UPD dotnet watch works just fine for that purpose, but author of the book (A.Freeman, Pro ASP.Net core MVC 2 7th edition, chapter 6) did not use it:
Visual Studio supports detecting changes as soon as an HTTP request is received from the browser and recompiling classes automatically. To
see how this works, select Start Without Debugging. Once the browser
displays the application data, make the changes to the Home
controller. Save the changes to the controller class file and reload
the browser window without stopping or restarting the application in
Visual Studio. The HTTP request from the browser will trigger the
compilation process, and the application will be restarted using the
modified controller class
Why does this not work for me?
The book was written for Visual Studio 2017. It works as the book describes in VS 2017.
However, according to this, the auto-rebuild feature has not yet been added to Visual Studio 2019.
Original answer: (which applies when that feature is not available):
The difference is that .cs files are compiled into your project's DLL at compile time. For any new code to take effect, the DLL needs to be updated, which will only happen if you specifically tell it to recompile. This is why, when you deploy your project, you copy over the .dll file and not the .cs files.
However, views (.cshtml files) stay as plain text files and are compiled when you use them. If you edit a .cshtml, it's recompiled the next time the view is used. This is why, when you deploy your project, you do need to copy the .cshtml files.
Visual Studio does have a feature to let you modify .cs files while debugging and have it take effect immediately, but it doesn't support ASP.NET projects. It's called Edit and Continue.
However, you can setup dotnet watch to detect file changes and restart your application. There are instructions on how to do that here: Develop ASP.NET Core apps using a file watcher
Recently, Visual Studio 2013 started hanging again when trying to debug/trace an ASP.NET web site. The site was created with WebMatrix 3 but I don't think that is relevant.
VS2013 opens the web site Solution. It takes a really long time to load up. Once it does load up and I run the project, it hits my first breakpoint and then the IDE Window quickly shows "(not responding)" in the title bar and the IDE is now hung.
This happened to me a long time ago and the root cause was needing to set the "use 64-bit IIS" option as indicated by this SO post:
Visual Studio 2013 crashes and restarts every time I run my test solution
But I triple-checked and I do have the 64-bit option checked. What can I do to fix this?
What worked for me was resetting visual studio. I got the suggestion from http://www.vosseburcht.com/?p=69
See this blog in the issue. It basiclly says to make sure "show all files" is selected in the solution and check for any folders that don't belong that are not part of your project/solution.
The problem resurfaced again a few days later and I finally figured out the problem with my uncooperative debugger. I have a folder containing approximately 20,000 images that are not included in the Visual Studio web project but are sitting in a directory in the web site. I had turned on "Show All Files" in Solution Explorer to add some script files into the project. When "Show All Files" is off, F5 (Start Debugging) works like champ. When "Show All Files" is on, Visual Studio becomes unresponsive. In reality it is not "frozen" but simply taking a very long time to process those 20,000 image files.
For me, it was a folder created called backup, which was a backup of the site (created by VS). I deleted the folder in question and the site loaded for debugging.
It might be caused be some extensions in Visual Studio, I was facing a similar problem when degbugging asp.net websites. Try running VS in Safemode: devenv.exe /Safemode. In my case it was caused by Multilingual App Toolkit extension, after uninstalling it, debugging ASP.NET websites works once again.
In my case, I was able to solve it by running it as an Administrator!
Don't know why, couple of days back it was working fine, suddenly it started to freeze when trying to debub web app!
Hope it helps someone!
BTW: I am running VS2013 Ultimate, with Update 4
In my case it's the IntelliTrace that causes problem. I need to disable it https://msdn.microsoft.com/en-us/library/dd264948(v=vs.100).aspx
I have the same situation and "solved it" in a very particular way: Rebuild the solution and run it without debugging (Control + F5), then go back and debug it the normal way.
I was having a similar issue, and I found the following error in Windows Application Event Log that corresponded to the problem:
Application: PowerShellToolsProcessHost.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.Runtime.Serialization.InvalidDataContractException
...
So I removed PowerShell Tools for Visual Studio extension, and the issue went away. I am using Visual Studio Ultimate 2013 Update 5.
I had this problem while writing an Excel add-in.
Not being a web app I was pretty sure that checking the 64 bit IIS Express option would make no difference, but it did!
I have no idea why, but it runs in debug ok now :)
I had to install Windows Management Framework 4.0
My solution was to remove all the .bak backup files generated by DevExpress ProjectConverter when I had upgraded to the new DevExpress version.
I have been using WebMatrix 3 and Visual Studio 2012 without trouble for a long time. Starting today, every time I open a WebMatrix 3 project in VS2012 and I launch it, VS2012 hangs and shows as "Not Responding" in the Task Manager. I can launch the project from within WebMatrix 3 and it does open the web browser and can successfully run the site's code. But when I try to run the program in VS2012 it hangs and I have to use the Task Manager to close the VS2012 IDE.
I tried creating a new starter project and the same thing happens with it. Note, I am able to run and debug non-WebMatrix 3 projects just fine, including MVC Web Roles. I tried restarting my computer and that did not help.
I found this article on how a "blocked" file can cause this kind of behavior in strange places:
http://digioz.blogspot.com/2013/06/visual-studio-2012-freezes-or-crashes.html
But I don't know how to determine which file(s) may be blocked. Also, I'm wondering if it's a weird problem with IIS Express. Has anyone seen this and knows how to fix it?
UPDATE: I've noticed that it takes nearly 40 seconds to open WebMatrix 3 projects VS 2012 and it never took that long before. After seeing a status line saying "Open Access Controls registers" in the status line, there appears to be a 30 second wait before project loading continues, a delay time curious close to the typical time-out setting for sockets.
Also, I tried switching from my default browser for IIS Express sessions from Chrome to Internet Explorer. The project ran find. However, the next time I ran it IE displayed the same "hanging" behavior as Chrome and after multiple attempts, never came back (still hangs)
I have a web project in Visual Studio.
When at work i can start the project in debug mode (F5), and set break points. Edit the Code Behind or asp controls. When pressing F5, this will refresh and my new code will be represented.
At my home computer i can edit, i can press F5, but my changes will not be shown. And the debugger will step through the code like it does not realize that it has come some new code.
Has anyone experienced this before? This is not the first time I have seen this, but i cant for the life of me figure out how to make it refresh....
Any pointers will be welcome :)
Edit:
Could this by any chance have something to do about the project type? Or the compilation of the web project?
I figured out why this worked as it did.
The project type i had chosen for my project was ASP.NET WEb Forms Application. This implies that the project will compile and be run from an DLL file.
To rebuild this everytime there is made a change is not possible, so it doesn't.
I changed the project type and buildt a Web Site instead. This kind of project does not compile into a DLL, but is rather run on the fly from the files that i code. Because of this i can make changes to my files, hit f5 and it will automatically reload with the new content.
I am building an application which is based on a sample application,
written in C# on .NET 2, and is built on VS2008. This application is mostly a wrapper for a COM application.
However I compile it in .NET 3.5.
The sample application came with the following files in it's bin\debug:
appName.vshost.exe
appName.vshost.exe.manifest
I noticed that I can delete the files and VS re-builds vshost.exe, and the vshost.manifest file appears with modification date the same as the deleted file as if VS has copied in from somewhere.
My question is, should I put this files in my SVN code repository?
Those two files you list implement the Visual Studio "hosting process". It is a hosted version of the CLR, designed to improve the debugging experience. It takes care of some security issues, the most visible side-effect is that it redirects output written with Console.WriteLine() in a GUI app to the Output window.
These files are not part of your project and do not get deleted when you use Build + Clean. In fact, you cannot delete the .exe file, it is always running while you've got the project opened in Visual Studio. You can disable the hosting process feature with Project + Properties, Debug, scroll down, "Enable the Visual Studio Hosting process" tick. There's no compelling reason to do so.
There's no need to check these in, Visual Studio re-generates them when you check-in a project and load it in VS. In general, you never need to check anything in from the bin subdirectory, its content is always re-created by building your project.
Everything in the debug (or release) folder is generated. Everything that's generated shouldn't be checked in.
When in doubt, just make a fresh checkout to some other folder (or even machine), and try to build from that. If something is missing, this will find it.
I do not think you should. They are for VS use only.
Here are the files I ignore when creating C# projects. You really only want to store the source code in the repository and not the outputs. Similarly you probably do not want to store the user based information that goes along with VS solutions.
*.csproj.user
*.suo
bin (folder)
obj (folder)